Google Store Design System
In a place as big as Google, every design team is responsible for adhering to the Google Material guidelines to keep quality, brand and accessibility consistent across the org. They are also responsible for creating and organizing new design patterns specific to the needs of the team. At Google Store, my role was to define and create a system, starting off with a stickersheet and Sketch library, that incorporated GM guidelines as well as turning our own GStore patterns into reusable components. The system had to work for us, but also fit into the larger GM world. The task turned into a team effort, with Chris advising the project and Fiona helping with defining the foundational elements. I worked on auditing the site, fine-tuning our processes and producing the stickersheet.
As with all design systems, this project is ongoing.
Team - Nickki Nguyen, Chris Vilchez, Fiona Foster
PgM - Uyen Vitti
Lead - Allen Tsai
Year - 2019
There were a few problems we were trying to tackle with this project.
The team didn’t have a stickersheet or library.
We lacked a centralized location where a new designer can open and find all the components that are currently live on the site. We relied on tribal knowledge from fellow designers to point to certain files that lived on our drive. Worst case scenario, we wouldn’t be able to find the file, or worse, it never existed, and would have to recreate the components from scratch.
The site was inconsistent.
Two teams work on the site - and it shows. Different patterns were used for similar functions across the site and we needed a whole audit of the differences before we could start a conversation on how to make them consistent.
The site was not as accessible as it could be.
Certain button colors and text colors did not meet AAA accessibility standards. It was our goal to meet those standards and fixing those problems within the designer’s own toolbox was the first step.
Screenshots from the buy flow of the gstore site show inconsistencies such as button styles, card elevation, body text, text colors, and an accessibility problem when looking at grey text on grey background. This was all audited and accounted for while making the stickersheet.
The team met to discuss goals and what we wanted to accomplish by the end of this project.
Get alignment between marketing and engineering.
In order to make the design system a success, we had to get key stakeholders from other teams on the Google Store on board. Marketing had their own style guide and engineering was coding for both the UX team as well as marketing. This meant double the work. If we could align on a consistent design system, engineering can focus on building just one set of components.
Create a stickersheet and library for our internal UX team.
This is what started it all, a need for a stickersheet for our own team.
Create a style guide.
The style guide would map out foundational elements and be used to explain how to use the stickersheet and map out specific guidelines for specific components. We wanted a working style guide to send out to external design agencies to better onboard them to our design language.
Have a library of coded components.
Once we standardize our design language of reusable parts, we can then work with engineering to create a library of coded components and patterns that they can reference to efficiently create new pages on the site.
As we audit the site and create design components, we can start from the atomic level to ensure that each element is up to AAA accessibility standards. That means checking if the colors past the correct contrast ratios, if the error states are readable, if the fonts are the correct size, etc. And finally, bringing our findings back to the larger Material Design team.
The team got together and brainstormed what we needed for the stickersheet. We each wrote down everything from atomic parts to whole pages on post-its to organize our thoughts. Then we tried to define and categorize all the words. Below is a recreation of some of the brainstorming work we did:
Our PgM, Uyen Vitti, helped us get organized by creating a project timeline for us to follow. We broke down the project into sprints based on the categories we defined above. The design system team met once a week to review my progress and by the end of week 5, I presented the first draft to the larger UX team.
A lot of time and care was taken into getting the foundation right. We made sure to align on a naming convention that matched GM’s stickersheet but also met our own needs. We created and named our own text styles, making sure to comply with accessibility guidelines. We narrowed down the Google colors to what is only used on the live site and defined what they should be used for. Using anima, an amazing sketch plugin, we made sure all of our symbols were responsive and stacked/padded correctly. We discussed what should be an override and what needed to be locked in. Our philosophy was to make sure everything was done right the first time, and for symbols to be built in a way where designers did not have to worry about formatting or breaking out of the symbol to adjust.
We spent a lot of time on just the folder structure alone, making sure that the organization made sense and designers were able to quickly locate the component they’re looking for. Even within each folder, we wanted to include the full component as well as the atoms that made up the components in case a designer needed to customize a component to fit another specific need. Other considerations were screen sizes and how to break up components that spanned from desktop to mobile.
The general symbol naming convention we agreed on became Component/Style/Screen size/State in sentence case. For example, Navigation/Promo/Desktop/Blue for a nav component of the header.
If we had more time, I would have loved to test this on other designers to see if the folder organization made sense.
Unfortunately, my time with the team ended after I completed only the first draft of the stickersheet but I was grateful to play a part in kickstarting this project. Next steps would have been to create a library out of the stickersheet in order to have a master file to push updates to, and start distributing to the larger team to use. The end goal would be to use this stickersheet to create a style guide and submit it to the marketing, engineering and GM team to start a conversation around alignment, standardizing these updates and start creating a better, more consistent Google Store.
To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. All information in this case study is my own and does not necessarily reflect the views of Google.