Project

Build a Design System for an Amazon department to help in the design of new and updated pages. The goal was to document web design choices from the past, guide design on future projects, and provide a tool to more quickly create page mockups and research best practices.

Challenges

Which tools are the best to reach our goals?
What part should documenting existing designs play vs providing information vs proscribing what should be done in different scenarios?
What organization method will work best for the users of this content?
What other types of documentation will be necessary, and where will that information live?
Is one person a large enough team to build out a design system for a large set of pages?
A wide variety of stakeholders: internal designers, project managers, developers, page builders, and outside agencies.

Role

During my tenure with this department at Amazon, my primary responsibility was to lead the UX design efforts for a high-priority project. I collaborated with a team of 2-6 designers, meeting twice a week to present my progress, share relevant research findings, and provide guidance on the direction we should take. I valued the feedback I received from my colleagues, and we made decisions collaboratively, leveraging each other's expertise as needed. To ensure that our designs aligned with the capabilities and constraints of the content management system, I developed the design system from scratch. As we transitioned from Sketch to Figma, I meticulously rebuilt the system to ensure accuracy and leveraged Figma's Auto Layout feature to create consistent and scalable design components and fragments.

Process

Heuristic Analysis: My first task was to run an in-depth analysis of the preexisting pages for the department. I noted instances of use of fonts, colors, buttons, and also patterns like 3 columns of text with images at the top and documented all the variations of these along with the oddities I found in Sketch. At the same time I researched publicly available design systems and the tools being used to implement the systems. Sketch was the predominant design tool at the company, and this was the deciding factor. We also decided on the addition of InVision’s Design System Manager as a location for documentation resources, as well as to make the information accessible to those without a Sketch license.

Accessibility: While researching patterns and styles in use within published pages, I ran across pages with text that was not a large enough difference in contrast between the background, or using a background image that resulted in the same as well as some other simple to fix accessibility issues. I ran accessibility testing on the pages with the most traffic and documented what should be changed in a ticket to the developers so that these would get updated to modern accessibility specs. As I was working on building the components and patterns for the design system, I also tested contrast and font size readability on these objects. This lead to increasing our recommendations for standard and title font sizes for aws.amazon.com pages, my inclusion of these larger sizes in the design system, and updates to a large number of the design system components.

New User Feedback: As new people joined our team I received useful feedback and usability information on the system as it was. For users looking to find information quickly in order to start a new page design, the original page layout, as well as the inclusion of duplicate or similar objects came into question. It became apparent that the original page organization caused confusion, so the number of pages and the page organization was simplified further. We had some visibly similar objects in the system, for example, some which were effectively variations on a three or four column layout. I removed the duplicates and rebuilt them from one standard component. There sometimes was a reason to keep subtly different variations in a template, but I built the components using Figma’s Auto Layout so that they were able to be modified to match each use case.

Documentation: Some of the user of the system, like developers, would be looking for specific information around sizing and color, and new project managers, designers, and outside agencies hired to build pages would also be in need of usage guidelines. It was decided that this information should be attached to the relevant objects in Sketch, as well as to be located in InVision. This allowed outside agencies and those without a Sketch license to access the information. I also created a wiki page enumerating all of the resources and how to gain access to them which was viewable by anyone in the company.

Figma: Part of the way through working on this project, we were realizing just how quickly Figma was replacing Sketch at Amazon. Once our team received access to Figma, it was quickly decided to move everything over to Figma, while keeping InVision as a secondary source of documentation. This required importing everything from Sketch but then rebuilding each component and element in order to have it work properly with Figma’s Auto Layout feature, as well as to add fonts, colors, and other types of information that have built in Figma features.

On The Fly Prototyping: A great deal of the changes to organization, layout, and where different components or pieces of documentation should live were decided by prototyping those changes within Sketch and then in Figma, as well as some in FigJam. With Figma and FigJam, since these tools allow multiple people to be editing one file at the same time we were able to illustrate different ideas to each other quickly.

Learnings & Future

Mobile Variations: During my time at Amazon, we found that the percentage of of pages being viewed by mobile was far higher than previously understood. While tablet and mobile breakpoints have been thought about and pages are viewed on mobile while designing, it has been a secondary design target. That will need to change. Likewise, the templates and a large number of the “fragments” in this system will need to be updated to make mobile variations and to document more rigorously which types of components make reading and absorbing different types of information as easy and understandable as possible.

Simplicity: The process of building the design system involved a lot of back and forth with me as a new team member searching and researching what was already in use across aws.amazon.com, as well as what should or shouldn’t be guidelines through my conversations with team members with historical knowledge of why some choices were made. If I were to continue on with this project, I would break more of the “documentation” out of the “design system” in order to make each be a little bit more pure and hopefully make each more easily accessible.

Outcome

The final products for this project were a comprehensive design system and documentation in Figma, a wiki page documenting where to find and how to access the different pieces, as well as a PDF version. I would be glad to do a walkthrough of this project. It was a large project so it can benefit from an in-depth look as well as further explanation of why specific choices were made.

Now when someone new to designing pages or deciding what content should be where for an aws.amazon.com page, there are in-depth resources to use. This design system will reduce the time needed to gather information and find how existing pages display different types of information. This design system can also be used by designers to drag and drop or copy and paste full templates into their current design and to then remove or add page fragments as needed to get close to a full page design without having to build anything from scratch. The time saved can then be spent on the parts of the new page that truly require thought and organization, as well as to fine tune design ideas. Using this system will save hours every time a new set of pages is being designed for a new product.

Comprehensive Design System