Catherine Hicks
User Experience and Product Design Professional

Scytale

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: Workloads

  • Creation and manipulation of Workloads is the fundamental pieces of how the product works
  • Workloads map the identities to a set of properties called selectors in order to communicate. We need to build a way to create, edit and remove selectors
  • User will not have to do this without entering a command line
  • The workloads have always been a fairly straight forward process. We had a set of parameters that needed to be set for each type of workload and they needed to be input by the user for their specific instance. This has always been a form based interface and has not varied from our original concept except in layout from one column to two

Project Constraints

  • 1. We must be able to visually show dependency
  • 2. Must be able to manipulate a single workflow and see how it cascades across all other pieces of data
  • We believe that users can easily add, remove or modify workloads within the dashboard when we separate out each type of node and build out a framework that is purpose built for each type in order to gather the information needed
  • Working with our documentation and the help of our open source team I was able to get a table of these specific data sets in order to design a framework that would not only work for the ones we currently were building to but would be future proof enough that we would be able to use that platform for any additional changes down the road 

Scytale Enterprise: Workloads

Wireframes

Example

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?

Scytale Enterprise: Workloads

Wireframes

Example

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?

Scytale Enterprise: Workloads

Wireframes

Example

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?

Scytale Enterprise: Workloads

Wireframes

Example

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?

Summary

  • 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

  • The challenge of building this part of the product was the complexity of data that needed to be represented in a cohesive way. Each set of data had different parameters to work with, which had different requirements, however the general task to complete was the same, therefore the User experience had to be similar
  • We started out with the idea of allowing a user to set their parameters one at a time themselves with no guidance, giving them the flexibility to do what they needed to go but allow the UX to be similar.
  • However that proved to be very cumbersome, and introduced a high likelihood of errors that could break entire systems, so we came up with the approach we show here, still was cohesive and adaptable enough but put more of the data up front for the user, thereby streamlining the usability
  • This entire project is in an industry I had know subject matter knowledge of before starting. its been an amazing learning curve that I have thoroughly enjoyed (and was a huge part of the reason I came on to the project in the first place).
  • This full product was launched 19 June 2019