Saying you need a design system is like saying you need a vehicle. You know it will get you somewhere, but without a destination, you risk leaving people disoriented, somewhere other than where they need to be.

In this post we’ll look at why the term design system isn’t all that useful, and how to arrive at the outcomes your organisation actually needs.

Where design systems come from

First: some historical context. Design systems originated when graphic design and typography thinking began to crystallise in the corporate identity manuals and style guides of the later 20th Century.

A notable example is the NASA Graphics Standards Manual of 1976. It prescribes NASA’s approach in exacting detail, from letterheads to spacecraft insignia.

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

Salesforce’s Lightning Design System is one of the first digital design system to popularise the term. Released in 2015, it’s a comprehensive tool to help teams design and build digital products and services in the large.

Other, more detailed accounts on 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. And that’s without considering even broader systems that cover content strategy, voice and tone guidance, internal processes, dishwasher policy…

As a more practical alternative, individual disciplines have carved out the bits that works for them, while still calling them a design system. Hence, design system can mean different things to different teams. For example:

Brand identity systems: The current NASA Brand Guidelines, say.

Component libraries: Whether well-considered, like the GOV.UK Design System, or more ad hoc.

Design components and standards for a thing: For example, Volkswagen’s system for VW and sub-brands, discussed in this Into Design Systems talk from Matthias Fritsch and Thorsten Jankowski. Although the thing could equally a be product or single brand identity.

Design assets: Whether organised or otherwise. The distinction is that there’s no accompanying technology implementation. For example, Uber’s Base is Figma-heavy (which is usual) and geared towards designer needs.

Fully-integrated design systems: Including guidelines, components and technology. Again, see the Salesforce Lightning Design System as well as Google’s Material Design, IBM’s Carbon and Microsoft’s Fluent.

When a term means different things to different people, it’s a challenge to use safely in a general setting. Even the word design can be tricky as it implies ownership by design teams. That sometimes makes sense, but it’s controversial as a universal rule.

For a design system to be successful, it must meet cross-functional needs. Designers don’t want to be burdened by whether their design system works for brand or engineering teams. Conversely, design systems owned by engineering teams can overlook the needs of designers².

Build the right thing

Rather than assume you need a design system, it’s better to identify the problems you want to solve, and take a cross-discipline approach to solving them. Here are four things that can help:

1. Set goals

It’s vital to set goals for your project. Make sure:

They’re outcome-oriented
They map to the aims of your organisation
They map to the needs of your teams
Everyone buys into them (to the extent possible)

Identify non-goals too. Localisation is a great example. If you’re an international brand with audiences that don’t speak English as their first language, localisation is a priority. If your audience is confined to the UK, you might exclude it from your initial scope. It’s good to have that recorded as a deliberate decision.

To reach consensus about your goals, ask questions to identify:

What your business does
What problem you want to solve
The needs of users in your organisation
The needs of your customers
The results you want to see
A successful end state
Accessibility implications
Countries you operate in
Your technology stack
The brand implications (and how much you care about them)

When your goals are correct, it doesn’t matter if you call the thing you’re building a design system. Call it what you like.

2. Define terms

Regardless of what we call it, we always clearly define what it means, what it includes, and what it’s designed to do. For example, when we helped BT implement Arc³, we called it a UI system. But we went further, defining 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.

On its front page, you can easily access everything the UI system includes, namely:

React components
Figma library
Design tokens, available in different formats.

3. Communicate in the open

Internal communication should be on your radar from the start. This goes beyond project buy-in and defining terms: it helps you build something that helps everyone.

Share progress in the open. Everyone with a stake in the UI system needs to know where to go to see the work so far, and where to ask questions.

Consider week notes, frequent demos, and retrospectives at least once a quarter. These create opportunities to communicate changes to what you’re building from micro-refinements up to changes to macro-scale goals.

Doing this protects the project from change. As new people join, having the project history in the open will help get them up to speed. And it gives everyone the best chance of flagging issues at the earliest opportunity.

4. Expect change

The thing you’re building should have the potential for change built in, whether it’s a design system or anything else. The project can adapt as your understanding of the problem changes. This is especially important for projects that cut across many disciplines and teams (design systems, for example).

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

We sometimes hear concerns that upfront discovery work and goal-setting slows progress on the work already being done. Make it a goal of your project to support the progress of the teams you’re working with. Design your process to be iterative, and avoid blocking other teams.

The most important thing

Ultimately, muddled 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 the thing your organisation actually needs.

There are fuller accounts of the origins of design systems. Brad Frost explores this in the opening of his talk, A Global Design System. Jay Hoffman’s From designing interfaces to designing systems is well worth a read. ↩
Tools like Figma and Storybook have proven to be powerful collaborative tools for designers and developers respectively, particularly in enabling feedback. But they can calcify the design system into something solely for those disciplines 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. ↩
If the industry had called them 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. ↩

Don’t build a design system—build what you actually need