By: Matthew Giesa, Product Manager
You want to implement a design system at your company, but as you look across your products you feel lost. You think to yourself, “They all look different. How am I supposed to do this?”
Not too long ago, we worked with a client to build a design system based on an existing suite of apps whose styles and functionality had diverged over time. The goal was to bring some consistency to these apps and allow the product teams to focus on feature development without causing delays in their planned work. Today, that design system provides dozens of elements and patterns shared by five product teams (and counting) and has saved the client hundreds of days of development effort.
How did we do it?
We started by gathering information about the current state of the products and organizing our findings in a way that allowed us to think in terms of a system. Next, we made decisions about what that system could look like and what our priorities would be. Then we started collaborating and building. This was not a strictly linear process, as we would move back and forth between steps as necessary.
Step 1: Audit
It’s important to first understand the landscape. We asked questions like:
- What do our products look like now?
- What styling recurs across the products?
- Which elements or patterns are already built or used more than once?
- What kinds of layouts are repeated?
The answers to these questions will inform the foundations of the design system and the first elements you choose to build. We found answers by capturing examples of styles and patterns, then organizing them into groups to reveal commonalities. These steps are outlined below.
Capture
We explored each product to capture as many different types of screens and patterns as we could. We started with the most critical user flows and worked through less critical areas when we had time, trying to get a representative cross section of the many products. We took screenshots of individual elements and patterns, and took notes so that this documentation would provide enough context for us to carry out the next steps.
We also captured styles, including the color palette, typography, borders and shadow, examples of spacing and layout, animations, and so on. These details make up the foundation of any design system and pervade every pattern. They are important to standardize on in order to create a consistent feel across the entire system.
Organize
We started to organize the screenshots by grouping similar elements and patterns together so that we could later discuss each group. We tried to group by the element’s purpose rather than purely by its appearance. For example, each product may have implemented its own Date Picker with its own behaviors and styling. One version may use a calendar drop down and another may use a Select each for year, month, and day. They all serve the same greater purpose of helping the user select a date even though they each may have a different specific use case. Grouping these together at the beginning helped us review their shared purpose alongside what makes them unique, and later design base elements and their variants as part of a system.
Review
Once we had our initial groupings we reviewed them as a team. We discussed the purpose of the pattern in each screenshot and refined the groupings as needed. We also discussed which patterns belonged as part of the design system.
Patterns that can be reused across products and contexts directly serve the goal of creating a consistent experience. They also become multipliers of effort, as a pattern that would have been built repeatedly by multiple teams would now only be built once as part of the design system. The more teams that use a component, the greater the savings for that component. At this early stage it gives the design system some momentum. Highly-reusable elements were an easy ‘yes’ for us.
After the review we had a pretty good idea of which patterns had the most support across teams and which we didn’t want to spend any more time on. Our next step was to prioritize this list of patterns and decide which to work on first.
Step 2: Prioritize
To prove the design system’s feasibility early and build momentum, we looked for patterns that would likely be useful short-term and that didn’t have too many open design questions from the review stage. We also wanted to prove our approach to foundational styles, such as typography, spacing, and a color palette, so we prioritized these early as well.
After this initial proof-of-concept stage, we knew we wanted early adoption and that some quick wins would help us prove the value of the design system to keep stakeholders’ buy-in. We also knew that one team in particular was a vocal supporter and was willing to spend the time to integrate the design system into their product. We worked closely with this team and chose to build patterns that would be useful for their upcoming feature work.
We prioritized patterns based on the following criteria: reusability, complexity, and likelihood of delivery. The more reusable a pattern is, the higher its value in a shared resource like a design system or component library. The more complex a reusable pattern is (while still within the scope of a design system), the more effort we save each team that uses it. And finally, if there are too many challenges in turning a product-specific design into something that is reusable, it may be worth deferring that discussion for a time when the design system and its processes are more established, rather than blocking a product team at this stage.
Step 3: Deliver
With the work prioritized, we were ready to start creating. We began standardizing the styling of each component and breaking out variants where necessary. Design and development worked closely together to ensure designs were feasible and covered the majority of use cases.
We collaborated with product teams to ensure we met their expectations, both in terms of end user experience and the developer experience of using the patterns in code. This also ensured product teams were well aware of the capabilities and limitations of the design system and could plan accordingly.
Once code was ready to integrate, we made ourselves available to pair with the consuming teams. This made integration easier on the other teams and gave us useful insight on any challenges they had.
Summary
Our path to a design system began with established products that each had their own styling. We gathered information, made it accessible, and reviewed it together to make sure everyone involved had enough context to think in terms of a system. We prioritized based on our team and business goals to make sure that we gave product teams every reason to use the design system. And we got to work delivering and removing obstacles, working with product teams to integrate the design system. Ultimately, this focus on delivering value led to higher adoption rates than we would have seen otherwise.
There are more questions to answer when planning a design system build and launch. Who should be involved at each stage? At what point do you establish principles for the system? What would a style audit look like? How do you decide on variants? How do you document the system? We’ll answer these questions in-depth in future articles.
