The secret to creating design systems with joint, multidisciplinary ownership that drastically reduce QA time.
By now, we are all aware of the benefits of having a design system for a digital product. Digital, component-based design systems help teams implement new features faster and with fewer bugs. But building a design system the team wants to use can be tricky. The designers, engineers, and product owners all have different needs for a design system. We’ve found that when a system is only design-led, it often doesn’t work as well for the rest of the team. So we developed a way to make sure design systems were created together and work for everyone on the team. Enter the Atomic Categorization Exercise, or ACE.
ACE in the Hole
ACE is a collaborative workshop we use to define the design system for a product. We run these workshops as soon as we have a picture of what the product will look like, usually relying on high-fidelity wireframes or visual design. They’re attended by the whole delivery team: design, engineering, and management—the more, the merrier.
The workshop is broken down into two sessions:
- Identify & Consolidate
- Group & Name
In the first session, we identify and consolidate the components in the designs. We break everyone into groups of two and assign each group a screen from the product. They then work together and take ten minutes to circle all the atoms, molecules, and organisms they find on the screen. We don’t focus on finding every instance but on finding at least one unique instance for each component.
After the ten minutes are up, everyone comes back together, and each group presents the components they found. As they share their decisions, the rest of the team gives feedback on whether they agree with the breakdown and classification of each component. This feedback is one of the critical aspects of the exercise and something we learned from our past design systems: not everybody on the team would break down a component in the same way. Having everyone share their thoughts challenges the team’s assumptions and helps them create a shared view of the system.
The time saved as we got closer to launch surpassed the extra time spent up-front.
In the second session, we group and name the components we identified in the first session. Everyone works together, taking turns to pull a component into one of the three atomic groups and propose a name. Some are easy—everyone always agrees on Button. But others are more nuanced—is it Hero with Tabs or Banner with Tabs? Or Hero Banner with Tabs? Or just Tab Banner? The nuance can seem trivial, but this gets at one of the core problems we’ve seen with design systems: naming things is hard. Everyone on the team may have a different mental label for these components. Through discussion, the team can often agree on an appropriate label, making the system representative of the team’s shared mental model.
In the end, we have a list of components, collaboratively defined, categorized, and labeled by the team. It wasn’t architected by a lone product designer but instead defined by all the users of the system. From here, the designers document the components, and the engineers build off of the documentation, working in parallel sprints. Everything developed is shared and reviewed inside of Storybook, a platform for viewing and testing individual components.
Is All This Work Worth It?
This process had been an idea we kicked around for a while, waiting for a chance to test it. The verdict? It’s been well worth the investment. In our first iteration, the team delivered a whole month earlier than expected. The process of reviewing components in Storybook caught issues earlier, resulting in fewer bugs cropping up during our QA phase. The time saved as we got closer to launch surpassed the extra time spent up-front. We’ve been taking this process across the agency to other projects, making adjustments, and improving the ACE with each iteration.
