Context
CloudFormation
AWS provides various services that customers use together to build their own infrastructure. These services share elements, so updating one element means that you have to manually update the others as well. This becomes very tedious to maintain.
CloudFormation is a cloud management platform that automates infrastructure management so that it can scale efficiently.
CloudFormation registry
My project is focused around the CloudFormation registry. The registry is a store that houses extensions, which enhance the functionality of CloudFormation just like plug-ins for Figma or extensions for Google Chrome.
Current private registry flow
In the registry, you can browse for extensions and activate the ones that are helpful to you.
There are three different types of extensions: resource types, modules, and hooks. Each extension type has a common structure, but they have unique customizations and different use cases. This adds lots of complexity behind designing one experience for three different extensions.
Registry users
CloudFormation has two main groups of users:
- Customers use extensions to enhance CloudFormation functionality.
- Publishers create extensions and list them on the registry. Publishers are CloudFormation partners that could be AWS, a 3rd party, or individual contributors. They want to expand their brand visibility.
Problem statement
The registry is only accessible to people who have signed into their AWS account
This presents a roadblock for CloudFormation to gain new customers because they can’t see what CloudFormation has to offer. This also puts a ceiling on publisher visibility.
To increase accessibility to the registry, I can bring the registry out of the console and into the public.
Now, customers can browse through the registry to get insights on all extensions and publishers. Publishers can expand their brand visibility. In addition, extensions are now discoverable through search engines.
My role is to explore what this public registry would look like without the sign-in wall.
Customer Goal
Make a new public registry that is more intuitive and consumer-facing for potential users who are not as familiar with CloudFormation.
Publisher goal
Gain more visibility
Formative research
The current interface
Right now, searching and filtering lends itself to experienced users who already know what they are looking for and are familiar with CloudFormation conventions. In addition, there is a lot of opportunity to bring more visibility to publishers by adding individual publisher pages, branding options, and logos.
Comparative analysis
I looked for overarching patterns in 12 other existing registries and took note of the components that would apply well to my users. Through this, I found that there are three basic pages to each registry:
Early Designs
User flows
I broke these higher level flows down into user flows. I identified possible entrance points to the registry now that it is in the public, and I fleshed out the page-by-page design requirements and the interaction between pages.
Wireframes & sketches
I began to put together the structure of each page and explore design iterations for high priority areas, such as filtering, searching, and card designs. Here, I also played around with information hierarchy by making hypotheses about what information customers would prioritize that I could test in user research.
Design Explorations
Landing page filtering
No participants found value in filtering or searching by publisher. So, I designed a simple, two-part filter that acted as a means for people to enter the registry results page. Here, they can filter on a more granular level.
Explorations
Final Design
This design supports all three extension types and adheres to customers' mental model.
Results page cards
When evaluating an extension result, participants placed the most value on the following information from high to low:
- Publisher tier badges (official vs verified vs community contributor)
- Number of activations
- Publisher name
- Peer ratings and reviews
People struggled to understand the difference between "official” and “verified” badges, so I explored different ways to display them. In the end, I decided to remove the “verified” status altogether because all publishers must be verified to have their extensions on the registry.
Explorations
Final Design
Final designs
All of the following screens are new and original designs that I created.
Landing page
Customers want to understand what and who the registry houses as well as how to use it.
Results page
Customers can quickly filter down and determine if they trust the results shown.
Extensions details page
Customers are able to easily find all of the information that they need to understand if they want to activate an extension.
Publishers details page
Customers can see the full list of offerings from a publisher.
Next steps
Measuring success
On the customer side, I would measure the number of activations, sign-ins, and account creations. I would also keep track of how people are entering into the registry. For publishers, I would measure the amount of landings on publisher pages, and I would look to more subjective measures, such as surveying publisher satisfaction.
Feature prioritization
I used my user research to create a write-up with suggestions on which features to prioritize, weighing both the impact and effort of development. I would see these changes through, making sure that I am continuing the conversation with those who are developing the product.
Lessons learned
Systems thinking and scalability
Working with a giant like AWS, I was pushed to consider how my design decisions would scale as CloudFormation grew and across other AWS platforms. I ensured my designs could apply to various use cases. As one of my final exercises, I explored how my registry could serve as a component to standardize other AWS registries.
Thrive in an unfamiliar environment
As a developer tool, CloudFormation is a technically challenging space to understand. I learned how to quickly familiarize myself with the engineering-facing problem space and distilled it down to a comprehensive exercise. I explored ideas with the customer, publisher, and AWS business goals in mind.
