Saying you need a design system is like saying you need a vehicle. It might take you somewhere, but without a clear destination, you risk ending up lost.

This post looks at why the term design system isn’t that useful, and how to arrive at the outcomes your organisation needs.

Where design systems come from

Design systems evolved from the corporate identity manuals and style guides of the later 20th Century.

The NASA Graphics Standards Manual from 1976 is a notable example, prescribing everything from letterheads to spacecraft insignia in exacting detail.

Later, these guides became digital and began to include pattern and component libraries. In some cases, they merged into a comprehensive library and were given the name design system.

The Salesforce Lightning Design System, released in 2015, helped popularise the term. It’s a comprehensive tool to help teams design and build digital products and services as a whole.

More detailed accounts of the origins of design systems are available¹.

Siloed definitions

Holistic design systems are powerful, but not well-suited to the siloed disciplines we see in big organisations today. (That’s without considering broader systems that cover content strategy, voice and tone guides, internal processes, dishwasher policy…)

To be useful in their day to day work, individual disciplines have carved out their own versions. So design system has come to mean different things:

Brand identity systems. E.g. NASA’s Brand Guidelines.

Component libraries. E.g. The GOV.UK Design System is a well-considered case, but they can be more ad hoc.

Design components and standards. E.g. Volkswagen’s system for VW and sub-brands, discussed in Into Design Systems, presented by Matthias Fritsch and Thorsten Jankowski. It could also be for a product or single brand identity.

Design assets. E.g. Uber’s Base is Figma-heavy (which is usual) and geared towards designer needs. These may be organised to in varying degrees. The distinction is that there’s no accompanying technology implementation.

Fully-integrated design systems. E.g. Salesforce Lightning Design System, Google’s Material Design, IBM’s Carbon and Microsoft’s Fluent. These include guidelines, components and technology.

When a term means different things to different people, it’s risky to use in a general setting. Even the word design can imply ownership by one team. That sometimes makes sense, but it’s controversial as a universal rule.

Designers don’t want to worry about brand or engineering needs, just as engineering teams might overlook the needs of designers². For a design system to succeed, it must meet cross-functional needs.

Build the right thing

Instead of saying you need a design system, identify the problems you want to solve. Here’s how.

1. Set goals

Set clear, outcome-oriented goals that align with your organisation’s objectives and teams’ needs. Make sure everyone buys into them to the extent possible.

Identify non-goals too, like deprioritising internationalisation if you only serve UK users.

Ask questions to agree goals:

• What does the business do?
• What problem do you want to solve?
• What are the user needs, internally and externally?
• What results you want to see?
• What are the accessibility implications?
• What countries do you operate in?
• What is your technology stack?
• What are the brand implications?

When you set the right goals, it doesn’t matter if you call it a design system. Call it what you like.

2. Define terms

Clearly define what your solution does, and what it includes.

When we helped BT implement Arc, we called it a UI system³. And we defined this as:

… a collection of tools and practices that help teams working on BT Enterprise digital products build high quality web user interfaces at scale.

Adding a definition beyond the term helped everyone understand what Arc was supposed to achieve.

3. Communicate openly

Internal communication is vital. Everyone with a stake needs to know where they can see progress, and ask questions.

Consider week notes and frequent demos. These help communicate changes, from small refinements to what you’re building up to revisiting the main goals.

Having the project history in the open helps new joiners get up to speed. Sharing progress gives everyone the chance to flag issues at the first opportunity.

4. Expect change

Design your system with change in mind. The project should adapt as your understanding develops. This is especially important for projects that cut across many disciplines and teams.

Involve relevant people as early as possible, but understand that waiting for everyone can halt progress. Create processes that incorporate new information and perspectives as they emerge.

We sometimes hear that discovery work and goal-setting slows down work being done. Make it a goal to support the progress of the teams you’re working with. Design iterative processes, and avoid blocking other teams.

The most important thing

Unclear terminology shouldn’t stop you from doing good things. If you set goals, define terms and get the right people in the room, you stand every chance of building what your organisation actually needs.

1. Brad Frost explores the origins of design systems in the opening of his talk, A Global Design System. Jay Hoffman’s From designing interfaces to designing systems is worth a read. ↩

2. Tools like Figma and Storybook are powerful collaborative tools for designers and developers respectively, particularly in enabling feedback. But they can calcify design systems into something that solves the needs of one discipline while disenfranchising others. This isn’t an inherent weakness of these tools. They’re tailored to the needs of the relevant discipline, and not intended to house design systems for organisations. Yet, this is the reality of what happens in large organisations where siloed working is the norm. ↩

3. If they’d been called UI systems to begin with, we might have avoided this confusion. We’re not the only ones saying this: See this X thread with Nathan A. Curtis and Brad Frost. We tend to say UI system rather than design system. It’s a more accurate description of building systems to create web UI, and it helps set expectations. But if a client wants to call it a design system, we won’t argue. ↩