We’re building another enterprise design system, and we’re super-excited to make it boring.
Brad Frost, Dan Mall, and I have just begun helping a big company express and communicate a design system to govern their many web products. The company has two decades of digital products and a slew of production teams. Over time, the UX, UI, and technical underpinnings of the company’s interfaces have drifted out of sync. The goal is to give production teams a consistent design language and pattern library to solve common visual, UX, and technical challenges.
With projects like this, there’s often a strong temptation to throw out the old and start fresh with fancy new design components. “If we’re going to establish standards,” whispers the devil on your shoulder, “then let’s get rid of all the old stuff. Let’s blow it out with a new look, fancy interactions, and a shiny tech framework.” (Or my favorite: “Let’s make our own Material Design.”)
Design-system builders should resist the lure of the new. Don’t confuse design-system work with a rebrand or a tech-stack overhaul. The system’s design patterns should be familiar, even boring.
The job is not to invent, but to curate.
Solved problems and settled science
Design systems are containers for institutional knowledge. They provide tested and proven solutions to design problems. When these solutions are held together by a consistent visual language and UX guidelines, they represent what good design looks like for the organization or platform.
For projects like this one, we work with our client partners to identify the design problems their teams confront over and over again. And then we identify and extract the best solutions to those problems.
The more common the problem, the better. Design systems should prioritize the mundane.
This time around, we’re putting top priority on data entry, form validation, and messaging. Those aren’t exactly glamorous design experiences, but they’re where the company does its heavy lifting and where customers spend the most time. This is where boring gets exciting: how do you scale good, consistent, everyday design?
The work starts with lots of user research, just like any other product. We’re talking to the company’s developers, designers, and product managers to identify repetitive tasks and unearth reinvented wheels. We’re doing a deep inventory of the company’s web apps to find the best-practice solutions to these problems. We’re doing a similar inventory of the company’s inconsistent visual styles to begin to reinforce a common visual language.
At the end of the process, we’ll have a cookbook of design recipes for the company’s most nutritious business solutions. There will be lots more spinach here than design candy. That’s a good thing.
“Boring” design systems enable inventive designs
When the design system is boring, it frees designers and developers to do the new stuff, to solve new problems. The design system carries the burden of the boring, so that designers and developers don’t have to.
Instead of designing a card pattern for the 15th time, it’s already done. Product teams can instead put their time and energy into creating new experiences, new algorithms, new business logic.
This also means that a wonderfully boring design system does more than provide collections of buttons, color swatches, and code samples. Components are commodities. The magic happens in the guidelines that come with them. A great design system suggests which design patterns to use (along with the why and how) for specific circumstances. This elevates a collection of UI components into full-blown design patterns. Designers have readymade solutions for the company’s everyday problems.
“Every moment spent saying, ‘should this be a popup or lightbox?’ is waste,” one design manager told us during our research for this latest project.
Faster, faster
All of this leads to big speed increases. Big Medium helped a major retailer get their design systems group up and running, and the results have been, well, crazy. “We have a 10x increase in speed compared to how we worked before,” the group’s manager reports. “That is, we can do higher quality work 10x faster with a fourth the number of people.”
Worth re-emphasizing: this speed and consistency does not have to mean cookie-cutter products. Instead, getting the boring stuff out of the way in the design system means product teams have running room to invent the new. In fact, the products are the laboratory for the system’s future patterns.
Invention happens in the products
Designers and developers sometimes approach design systems or pattern libraries warily. While most appreciate the need for consistency, they worry that a design system will be too prescriptive and constraining, that there will be no room for new science. “A design system is like public transportation: it’s a good idea, for other people,” one designer told us in describing these mixed feelings.
Done right, though, design systems actually encourage and reward innovation by product teams. Designers and developers can build upon, improve, and occasionally replace the design system’s recommendations.
It should be a virtuous cycle. New ideas should be tried and tested in products. When good ideas prove out, they should be plucked out and included in the design system, so that future products can benefit. The latest solutions awesomely become the new boring.
Design systems should always extract their patterns from working code. In our design system work, we do this in two ways:
- Extract proven patterns from legacy applications.
- Build pilot apps alongside the design system that prove out new and necessary design patterns.
This is likewise how sturdy code frameworks emerge in the development world. Ruby on Rails was extracted from the first version of Basecamp, only after its core concepts had been proven in production. Design patterns and UX guidelines emerge from production projects, too.
Design systems, like code frameworks, are no place for untested ideas. Extract proven ideas from production interfaces.
This is the canon
Dan likes to use Star Wars (of course) as a metaphor for this process. The Star Wars universe is thick with unofficial tales—the novels, comic books, and fan fiction that build upon the films’ original backstory. That official story is the Star Wars canon, which is carefully managed and groomed by Lucasfilm. The rest is known as “the expanded universe,” and all of its characters, species, galaxies, alliances, and so on are considered off script—until they’re not.
Every so often, the minders of the Star Wars canon accept elements of the “expanded universe” into the official story. They, too, become canon.
In Dan’s metaphor, your company’s design system is your design canon. Others go out and build apps and new design patterns on top of it (the “expanded universe”). Some of those design patterns will be so useful and so in tune with good design at your company that they too will become canon.
That’s the virtuous cycle between design system and product. If you’re the manager of the design system, you get to be the George Lucas of this story. Only you’ll need a lot more humility.
The humility of the work
Successful design systems are in constant service to many audiences—designers, developers, product managers, and of course the end user.
That spirit of service means that keepers of design systems have to keep ego at bay. A design system is not a place to push new frontiers but to gather settled solutions.
Crafting a design system is about clearing the way for others to invent and imagine. And that means boring has never been so exciting.
Is your organization wrestling with inconsistent interfaces and duplicative design work? Big Medium helps big companies scale great design through design systems. Get in touch for a workshop, executive session, or design engagement.
