Brad Frost nailed down a pair of mighty useful metaphors for pattern libraries (“workshops”) and design-system style guides (“storefronts”). These are useful because they help delineate what kind of work happens where, which is a recurring source of confusion we’ve seen in companies struggling to maintain jumbo design-system projects.
Brad created the first version of Pattern Lab when we designed the Techcrunch website back in 2013. That pattern-library software was the first glimpse of his Atomic Design methodology, building design pattern “organisms” out of smaller “atoms” and “molecules.” Pattern Lab has since been open-sourced and remains our go-to tool for developing and sharing websites and full-blown design systems.
Pattern Lab is where all our work comes together. It’s a collaborative environment where information architecture gets stubbed out in the browser, where visual design comes together, where the code gets wrangled, and where content is edited. We share ongoing work inside Pattern Lab with stakeholders and clients. And it’s the final deliverable for web projects, complete with page templates and detailed pattern library. Our projects happen almost entirely inside Pattern Lab.
Our pattern libraries are always a wonderful mess, full of experiments and spare parts and tools.
While Pattern Lab shares some qualities with style guides (for instance, it shows code snippets and you can add pattern documentation), the environment is really designed for teams to effectively build and work with UI components: the navigation across the top is small and unobtrusive, there are viewport resizing tools to stress-test UI components and pages, we’re able to organize components in a way that makes sense to us as creators (such as using the atomic design methodology), and we can design with dynamic data to ensure patterns are robust, resilient, and serve the needs of the organization’s applications. Like my wife’s jewelry workshop, the environment is designed for the design system team to be productive and creative.
This is not, however, an especially friendly place for people outside the working production team. Its organization around atoms, molecules, and organisms isn’t relevant to others; it contains building-block patterns that don’t have much useful meaning on their own; and it contains work-in-progress experiments that aren’t ready for prime time.
So when you’re sharing polished patterns and design systems with a group beyond the production team, you need something more refined. You need…
If the pattern library is the workshop, then the design-system style guide is the storefront, as Brad explains:
A style guide is the storefront where all the ingredients of the design system are put out on the shelves. The style guide storefront is designed for a different context than the design/dev environment workshop. Rather than being a tool for only the design systems team to make use of, the style guide communicates the design system to the whole organization. That means the style guide audience should be cross-disciplinary, since a design system can help create a shared vocabulary between all the people who are responsible for the success of the products at the organization. The style guide should provide information helpful for both makers and users of the design system, and should be used as a vehicle to continuously sell the value of the design system to the organization.
This isn’t just a difference in presentation. There’s a difference in core content, too. In our recent projects building out gigantic enterprise design systems, we’ve found that the style guide always presents only a subset of the pattern library. We cherrypick the polished patterns that are ready to share, while excluding most of the experiments and building-block “atoms.”
Behind the scenes, we use Brad’s Style Guide Guide to import selected patterns and templates from Pattern Lab, and then display them in a polished website. (In practice, a simple Grunt task exports the HTML for all patterns, and then copies ‘em into the style guide directory. Style Guide Guide includes them automagically in pages when it builds its website.)
From there, we add lots of guidelines and documentation to help newcomers make sense of the UX, the visual design, and the underlying markup. The end result is a set of settled solutions for common problems, clearly understandable and ready for production.
Distinct places for distinct jobs
We build patterns in the workshop, and we display the best of them in the storefront, showcasing them in the best possible light.
Too often, though, we see organizations try to force everything into one place. We see workshop pattern libraries trying to do double duty as a canonical design-system reference. Or on the other side, we see pattern libraries set up as static storefront references that live outside a useful working development environment. When these resources set up outside the workflow of designers and developers, they don’t get used, they get stale, they become irrelevant.
Following the workshop/storefront model—and stitching the two together so that one feeds the other—has ensured that the design systems we create continue to be used, vital, dynamic.