Scytale Enterprise: Mapping Identities
- Mapping identities to workloads
- We need to have a cohesive way to give cloud based workflows access to on-premise identity providers (i.e Active directory)
- Users will have the ability to map multiple identities without going into the command line
- User will not have to do this without entering a command line
Scytale was started in 2017 by seasoned engineers from Amazon Web Services, Google, Okta, PagerDuty, Splunk, and Duo Security who want to help enterprise engineers securely and easily build identity-driven, large-scale distributed software systems
Role & Project Summary
- We worked at first with the idea of mapping single identities at a time, so the user would have to input each one individually and in a 1:1 capacity
- In talking through the feature more we realized we may need a a one to many association, and at scale what we had originally designed wouldn't work very well, so we moved to what you see here
- 1. Must be cohesive with other features
- 2.Must be able to map multiple identities from one screen
At the beginning of my design process I created wireframes for testing purposes.
- Why was it useful to do this?
- What kind of wireframes did you make?
- Low fidelity or high fidelity?
- What tool did you use for this?
- Did you use them for testing?
- How many iterations did you have?
We believe Scytale Enterprise users will be able to intuitively map cloud workloads to on premises providers by utilizing an extensible mapping framework that spells out the mapping consistently
While assumed that was necessary to know, we went with a general 1 to 1 mapping scheme where this could be fleshed out more on the back end and was not as relevant to the UI design
There is no specific goals for this feature. More so we built goals for the entire product launch. This includes how many active customers we would get within a certain timeline (which is not disclosable information)
While initial basic informal user research was completed utilizing information gathered from sales calls (specifically lost sales) and demo feedback, we have not yet confirmed our product design assumptions fully via more formal user research, so we're making assumptions based on educated assumptions in this initial product launch
We felt that post-launch was the best time to formalize our research and test our assumptions since we'd have a concrete data to work with
This is on the roadmap in the near future, however we felt that in the initial concept phase, the feedback we got in less formal conversation, and a basic alpha of a platform that was used as a basis for enhancement, we felt we were not designing this platform completely blind without understanding the users in some capacity so we felt we could hold off on introducing formal research into the mix until we had something more concrete to get get feedback on
Scalability, as often talked about while developing this project, was the key challenge. We need to think about how this feature would work with thousands upon thousands of pieces of data - and this was always front of mind in designing the entire product - what was easy to do now that would also be scalable.