After six years of research and hard work, we’re excited to announce the open source launch of the AWS Cloudscape Design System! Read on to learn about how we approached the creation process...
Cloudscape offers a solid base of 60+ components, 30+ pattern guidelines, and 20+ demos, all meant to make your design work easier. Whether you are building a product that extends the AWS Management Console, designing a user interface for a hybrid cloud management system, or thinking of setting up an on-premises solution that uses AWS, you can use Cloudscape to speed up your development time and make it easier for your team to create meaningful experiences.
How do we know that Cloudscape works?
Because the team behind Cloudscape has gone through the journey of creating a design system from scratch, learning along the way, and now want to pass on the learnings to the wider design community. In fact, you’ve probably seen Cloudscape in action and didn’t realize it (Cloudscape was used to build the AWS Management Console user experience).
Cloudscape was born in 2016. Back then, design systems hadn’t really become industry standard yet, so there were a variety of challenges along the way. Component libraries with style guides were the law of the land, rather than proper systems. When the team started to build its “two-pizza” team, they wanted to do so much more than that. They conducted research to figure out a different approach.
As AWS had a large and pre-existing collection of experiences, a clear starting point was to inventory current offerings to help us understand what our products are built from. Creating a design inventory meant going through each page of our products, taking screenshots, and identifying all of the individual components. With over 90 services back in 2016 under the AWS umbrella, this was going to be a burdensome task.
Many design systems support 1-2 products. When creating a system to support 90+ services, our team faced some incredible challenges that required solutions never invented before. Innovating in the space was such an incredibly rewarding experience!
Clearly, a different strategy was needed to build out the inventory.
A hero flow was defined as the most important flow in a product and the team launched a “divide and conquer” strategy, where they focused on hero flows across our 20 most used services. They then followed-up with the remaining 70 services, to identify any missing patterns.
Through this inventory, over 100 components were identified and exactly where each of them existed. With priorities now set, initial set of 30 components were built for the new design system.
The key to a design system is consistency, taking the guesswork out of design so that teams can focus their energy on building consistent experiences. As you can imagine, when working with 90+ products, each led by their own “two-pizza” team, there are many small inconsistencies that accrue over time. The component library gave teams what they needed to build quickly and focus their energy on contributing new ideas back to the system, but the team still lacked any guidance around implementation.
To address this, a set of principles were developed regarding the use of core pillars of the system. This began with a very comprehensive set of guidelines for the visual foundation, which encompassed key elements like color, typography, and icons. Next, more complex topics were added like layout and motion, and now have a comprehensive set of principles around responsive behaviors and accessibility. The resulting guidance is a great starting place for any designer. These principles are referred to as our system’s foundation.
Next, guidelines were created explaining how to build common design solutions used at AWS. These are what are now known as our patterns. How loading states should look like, how errors should be presented, and other behaviors that span across all components across the system are defined through patterns.
As a finishing step, the team created a set of demos as examples of the most common hero flows used at AWS. Now any team needing to build, for example, a new dashboard for their service can first look at the Cloudscape service dashboard demo to see how Cloudscape recommends using our components to do so. Then, they can head over to the service dashboard pattern to learn about the guidelines for implementing the pattern. The same holds true for our create resource and edit resource demos and patterns.
Cloudscape has grown from a library of just 30 components in 2016, to a design system that supports over 220 AWS products and services. There is a solid base of 60+ components, 30+ pattern guidelines, and 20+ demos, all meant to simplify the way we work.
Cloudscape also has customization options! It offers theming, dark mode, and content density modes.
The source code is published on GitHub under the cloudscape-design organization. In the main components repository on GitHub you can find information about our support and contribution model, versioning strategy, and change logs. You can also open issues and ask a question directly to the Cloudscape team.
As you’ve read from our story, you can trust that Cloudscape will scale with you, whether you’re a “two-pizza” team building your first web app, or a 200+ product organization. So, head on over to the Cloudscape website to see for yourself all that Cloudscape has to offer!
