Catherine Hicks
User Experience and Product Design Professional


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

  • 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

Project Constraints

  • 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

Scytale Enterprise: Mapping Identities



At the beginning of my design process I created wireframes for testing purposes.

Guiding Questions

  • 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.