Lucy Carpenter

Lucy CarpenterLucy CarpenterLucy Carpenter
More

Lucy Carpenter

Lucy CarpenterLucy CarpenterLucy Carpenter
AWS

Design System

Role - vision, strategy, communication, scope, design lead


Targeted User - Internal development teams and cloud computing engineers 


Goal - As an end user user, I want to quickly and intuitively build my cloud computing solutions without needing to be an expert

GETTING PEOPLE TO CARE

I started at AWS doing the most basic pattern library design: what should buttons look like, text input fields, etc. But just having UI styling continued to allow every service team to keep making different experiences overall. I did a deep dive on every service across the product and documented the common user flows (create a resource, configure that resource, delete, etc.).    


But a simple pattern library continued to result in 200+ different user experiences across all our consoles. Not only did it also mean each team spent a lot of time developing their console from scratch, but it also created a lack of trust in our product suite and introduced so much complexity that we had a large drop off rate for beginner and even intermediate users. As the leading Cloud company, it also gave us an unprofessional feel for our products.


Since no one was pushing for a design system which would unify the major customer flows and look and feel, I needed to find a way to push this idea up the chain and get resourcing and support. I started by printing out all the screens a user went through to create a simple web app and taping them up to a common wall in the kitchen area of the AWS building. This generated a lot of interest among senior executives who in many cases had no idea how disjointed and long-winded the experience was going between the different services to complete simple tasks. I took this momentum and along with my manager, put together a vision for what it could be like to have a vastly simplified experience. 

early vision work

I started my design thinking by questioning the basic premise of AWS where we separate every cloud resource into its own service app. I took the basic actions I identified and designed modules for each one that would work for most service teams. (Ex. Create module - most basic actions, buttons, advanced features, common UI components last). 

V1 of the new system

Every service resource became a widget card with basic configuration steps in the main card and advanced configuration in an expandable section. This allowed for the inter-weaving of services towards a solution without a user needing to create a mental model for all 200+ services.

This shows an example of a quickstart guide to creating a web app within 5 minutes using the new design system.


Before the redesign, there was no design system so every service team designed their own interface and user flows. This was a problem for end users, because to complete simple cloud tasks such as making a web app, requires the user to use multiple services. In this case, a user would go to EC2 to create an instance (a virtual server), S3 to create storage for images and code, RDS or another database service to create the data storage, CloudFront to create a CDN for your content across the world, and potentially a host of other services depending on the type of web app. For a basic web app, it required a user to go through 90 clicks to complete all the actions and encounter 4-5 disjointed user experiences. 

For example, with the web app, each team built a modular component for creating the needed resource and a user then could stack those modules into a single flow. Going from 90 clicks, to 4 clicks to create a web app. A novice user didn’t need to navigate or even know that the different resources were coming from different engineering teams. A power user could dive into the advanced configuration options inside the flow or even opening the service and going into the details there.

testing out our conceptual work

The first console we used as a test case was AWS Autoscaling. This provided us with a create flow, beginner and advanced user configuration options, using resources from other consoles in a user's flow, and the ability to update and manage your autoscaled instances.  We were able to test out our widget experience with real users. https://aws.amazon.com/blogs/aws/aws-auto-scaling-unified-scaling-for-your-cloud-applications/

Some of the early user research feedback we got was that there were too many widgets on a single page for the create flow. This feedback prompted me to design a wizard flow broken up into more traditional steps on the left, but still utilizing the widget model.

Results

Now all 200+ service consoles are using the design system to build and deploy their interfaces. This not only greatly speeds up the development cycle for internal teams, but it creates a unified and intuitive interface for our end customers.


The new console home was also rolled out as part of this initiative.


You can see how many quickstarts are available for the common cloud computing solutions (such as Launch a virtual machine).

customer reactions

Copyright © 2024 Lucy Carpenter