Here’s my partner Josh Clark with an absolute barn-burner of an article: Ship Faster by Building Design Systems Slower. In our work at Big Medium, we’ve guided dozens of design system teams who have felt the stress of being perceived as a bottleneck that can’t keep up with product demands.
In this article, Josh details many nuggets of wisdom for getting out of that nasty position. The big lightbulb is that a design system lives at a slower pace layer than the products it serves:
Successful design systems move more slowly than the products they support. That’s a feature, not a bug. The slower pace doesn’t mean that design systems have to be a bottleneck to shipping product.
Design systems should prioritize quality over speed because they serve as critical infrastructure:
The design system is critical front-end infrastructure. When it’s successful, its components and patterns drive the UI, UX, and front-end code of the entire organization. You inject the design system into the very bloodstream of the whole product portfolio—as a general rule, it’s a bad idea to inject crap into the bloodstream.
Josh invokes Stewart Brand’s concept of pace layers and applies it to the world of design systems:
The fast and slow serve each other: Fast layers innovate, and slow layers stabilize. Out at the edge is where experimentation and discovery and innovation happens. At the center is where institutional memory and stability happens.
Recipes are an amazing addition to a design system ecosystem, and they serve as a critical layer that helps product teams address their needs without having to abandoning the design system. Josh explains further:
Recipes are UI patterns that are cooked up in whole or in part from design system ingredients (components, design tokens, icons and/or styles). Recipes are their own layer of the design system ecosystem. These recipes are not part of the core system itself, but are examples of how the system can be used—or even first-draft proposals for new features for the system. Product teams often have entire cookbooks of pattern recipes built out of design system goodies. These cookbooks are often represented by their own Figma libraries, code repos, and style guides.
Recipes are amazing for all sorts of reasons. They help product teams create and maintain their own compositions and components at their own pace in order to meet their product timelines and needs. When done in coordination with the design system team, the recipe layer can serve as an incubator for potential future design system components:
In other words: The job of the design system team is not to innovate, but to curate. The system should provide answers only for settled solutions: the components and patterns that don’t require innovation because they’ve been solved and now standardized. Answers go into the design system when the questions are no longer interesting—proven out in product. The most exciting design systems are boring.
And Josh closes the article with the thing that can’t be underscored enough: it all comes back to people and their relationships to one another.
This has to happen in good faith. This tends to fall apart when there’s not trust, clear communication, and healthy dialogue among the teams and layers. As usual, the biggest challenge is not the technical implementation but the coordination of humans.
I’m so pleased Josh put pen-to-paper on one of our most frequently-encountered design system challenges. If your organization could use some help establishing/evolving your design system ecosystem and pace layers, feel free to get in touch!