New workflows for Serverless Security

PROBLEM STATEMENT

Contrast's customers were increasingly adopting serverless technology despite a lack of security tools available. Contrast needed to quickly adapt its core security product to the new serverless development workflows and processes. 

ROLE

As the UX lead, I collaborated with the lead engineer and product manager throughout the project. To kick things off, I created a design plan that described the UX work in each phase of the double diamond process.  

The Double Diamond Design Process
https://interactiondesign17.wordpress.com/2017/02/09/week-4-double-diamond-framework/

DISCOVERY

The first step in discovery was to interview stakeholders about potential use cases and target users. It was clear that there were many different ideas about the problem and how we should solve it. This called for intense collaboration to get aligned. 

I facilitated frequent design work sessions with the core team to work out the different data models, users, use cases and workflows. Since we were all remote, we used digital whiteboards in Google Jamboard so that everyone would have easy access to edit and view progress.  

Snapshots from Google Jamboard showing group discussion on data models, users and use cases.

The collaboration paid off with alignment on target user and use case priorities. We also sketched out a high level workflow that I documented in Sketch and shared outside our core team via InVision.

Workflows collaboratively made in Google Jamboard (left) transferred to Sketch for clarity (right). 

Next I arranged discovery interviews with current customers who had previously expressed a need in serverless security.  I decided to use a hybrid of open-ended questions and concept evaluation to make the most of our time with hard-to-get participants.  


CONCEPTS

I created wireframes to prompt discussions about the parts of the workflow we had questions about - and to validate the assumptions we'd made up to this point. These wireframes represented onboarding a new account all the way to viewing security insights about their serverless functions. 

Wireframes, or wireflows, used for discussion in discovery interviews. 
Configuring rules to search for functions in AWS. 
Serverless-specific details about a vulnerability. 
Filtering vulnerabilities by additional risk factors unique to serverless environments.

USER INTERVIEWS

I interviewed 5 people who were in charge of serverless applications at organizations that were already using Contrast's products. Our hypothesis was that these users would be the first to use the product, even though the application security team was typically first to bring in Contrast. 

Org chart showing the various user roles.

Key Research Insight

Focus on the App Owner first.

Research confirmed that most participants want or need to take a team-by-team approach via the App Owner, at least initially. I created an org chart with role descriptions to help others understand the distinction and how it might change our decisions going forward. 

Research summary of changes to the workflow.

We also learned some things that helped us to drastically simplify the workflow. 

Though we were providing two options to onboard an AWS account, everyone chose the same option (to download CloudFormation template directly to add to their own stack). They didn’t want to use the pre-configured AWS stack to deploy so we opted to remove it completely. 

DEFINITION

Finally, after revisions to the workflow and wireframes, I facilitated multiple workshops to build a storymap.  We used Trello because, again, it was accessible for everyone to view and edit. 

As a starting point, I created the backbone for the storymap based on the workflows. Then when the team met, we were able to quickly review the outline, and move on to writing stories for each step. The most important part was prioritizing the stories and deciding what was necessary for our first deliverable (labeled "Prototype" in the storymap). The result of this was a clear plan for the first version of the tool that our design partner customers would try out. 

We completed discovery and definition (the first diamond in the double diamond process) right as I was starting my exit from the company. After I left, another designer was able to pick up the  project where I left off and continue building out prototypes for evaluation.