Struggling to ensure consistency in your experiences? You’re not alone. Here’s how to decide if you’re ready for a design system.
Picture this. You’re a moderately successful designer at a large business with lots of digital products. Your boss comes up to you one day and says, “We have a problem. It’s taking our engineers way too much time to build new features. And our products are all over the place with consistency.” So you say, “I hear designs systems will solve all our problems” and start plugging away at a new Sketch or Figma file to tackle the issue. Or, if you’re part of a very small team trying to triage a deluge of User Experience (UX) requests, you might turn to a canned solution like Material UI or Cabana.
Not so fast. Mature design systems can take years to build and entire teams to maintain. Before committing to such a large endeavor, it’s important to know the difference between a design system and other, equally valid artifacts such as sticker sheets, style guides, and component/pattern libraries:
Sticker sheet: The most rudimentary design library. These pages of reusable symbols are quite easy to generate out of modern design software.
Style guides: Here, designers have started to capture rules around usage and behavior. The tooltip only triggers on click. We only use teal as an accent color.
Component/pattern library: Building in complexity, a pattern library has actual code associated with the majority of its reusable design patterns.
Design system: Principles drive a mature design system, and capture a point of view (POV) that is unique to an organization’s designers and engineers. Much more than best practices, these rules and documentation exist to imbue a consistent experience strategy into the business’s ecosystem.
Image from uxdesign.cc
Design systems have a point of view
Much like guidance for a team of illustrators helps them all keep a consistent style despite each working on different parts of a show, design systems aid in creating consistent experiences across distributed product teams (consider how 18F developed their design system for the U.S. government). They can even capture the full-service design behind the system itself — defining the rules of collaboration between various parts of the organization as well as governance for contribution to the design system.
If you’re seeking mostly to ensure consistency on known UX problems, that is an indicator of low UX maturity. (Known UX problems meaning: “I’m building an eCommerce site and I need a way to display top-level navigation to my users”. It’s a problem we’ve solved many times before in the UX discipline.)
Conversely, an organization’s ability to create and maintain a design system is an indicator of high UX maturity. It requires allocating resources that otherwise used to further more-easily-tracked business goals towards building a foundation for consistent, truly great experiences. It means someone very high up bought into UX as a differentiator for the business, and that there is broad grassroots support for great experience design.
And, of course, it requires having a perspective on building experiences that are repeatable, scaleable, and that your team can articulate.
But can’t I just use Material?
Material Design is designed to solve Google’s problems. Not yours. It’s all well and good to use Material Design, Cabana, etc. if you are a small team starting out without a strong POV. But know that they were not solving the same problems as you. They have a different brand strategy and different experience strategy than you.
This is why it’s so key to start from design principles with a design system. Put them in order of priority, and make clear what the tradeoff is. It’s the hardest, most important part of a true design system.
Principles should show compromise and encourage a consistent voice.
“Simple” is not a good design principle. You haven’t taken a stance on anything. “Clarity over efficiency” is much better. You’ve stated that your team prioritizes understanding over simplifying workflows. If it takes longer, but more people get it, that’s worth it to your team.
Baking those perspectives, those compromises, into your design system is critical to longevity and adoption. Otherwise, all you’ve built is a sticker sheet or component library without much use outside its original intended product. You’ll end up with Frankenstein interfaces that potentially do users a huge disservice because they look similar, but behave in vastly different ways.
So when do I need a design system?
Design systems work best with larger teams inside organizations with higher UX maturity. For smaller design teams that find themselves frequently outsourcing work to other partners (potentially without much oversight), energy would be better spent on developing a sticker sheet or style guide first. Consider how Atlassian started by doing things that don’t scale, and the key role that understanding governance played in their overall strategy.
For larger teams with collaboration-minded engineering partners, but who face low UX maturity, a pattern library is a logical next step towards accelerating work without the challenge of getting buy-in from on high. Such teams can still work on defining their principles, but may encounter challenges with maintaining their burgeoning system, getting buy-in to build consistent experiences, or wrangling external designers into designing in their “voice”.
What we name things matters. Sticker sheets, style guides, pattern libraries, and design systems all have their uses in an organization’s journey towards high UX maturity. It’s important to recognize where you, your team, and your business are at so that you can take the approach that’s right for you.