Design System

011 min

Design System at a glance

• What it is: the maintained system a style guide, a component library and a pattern library all live inside, not one of them alone.
• Where it comes from: architecture's pattern languages in the 1970s, formalised for interfaces by Yahoo in 2006 and named a design language by Google in 2014.
• Apply it by: staffing it. Nielsen Norman Group's floor is one interaction designer, one visual designer and one developer, not zero.
• It backfires when: nobody enforces or funds it. An unmaintained system degrades faster than having no system at all.

021 min

The problem a design system solves

Two teams in the same company can build the same dropdown menu twice, each slightly different, because neither team knew the other one had already solved it. Multiply that across every button, date picker and error message, across dozens of teams and hundreds of screens, and the product ends up with visibly inconsistent UI, even though it is sold to users as one product.

Nielsen Norman Group has documented exactly this failure: without a shared system, large organisations end up designing and coding multiple versions of the same design element, which produces internal inconsistency, wasted engineering time, and code nobody wants to maintain.

A design system exists to stop that duplication before it starts, by giving every team the same starting point: the same button, the same spacing rule, the same error pattern, instead of one invented separately by each team.

033 min

What a design system actually is

A design system is the parent of three smaller things, not a fourth thing sitting next to them. Nielsen Norman Group states the relationship directly: the design system is the parent, and style guides, pattern libraries, and component libraries are the children that collectively make up the larger system. Confusing any one of the three for the whole system is the most common mistake in how people use these terms.

A style guide documents the rules, not the reusable pieces. It covers colour, typography, logo usage, tone of voice and grammar, plus rules for visual hierarchy such as heading scale and spacing, and it usually has no code and no interactive components. The 1976 NASA Graphics Standards Manual, still circulated today for its clarity, is a style guide in this sense. It specifies exact colour pairings and typographic rules for signage, decades before software existed to turn any of it into a component.

A component library is a catalogue of individual, reusable interface elements: a button, a text input, a date picker, each with its states such as default, hover, disabled and error, its code, and the settings a team can change. NN/g calls the component library what many people associate with design systems, and it is usually the first thing a team builds, because a button is concrete and a governance model is not.

A pattern library sits one level up. It is not a single element but a recurring group of elements assembled to do one job, applying modularity to an interface the way software already applies it to code. Atlassian, for instance, documents a page-header pattern that names the exact breadcrumb, title and button components it is built from, and explains when to use it. A pattern library shows how components combine; a component library only shows what each one looks like on its own.

A design system is the thing that holds all three of these together, plus the code that ships them, the documentation that explains them, and the team and process that keep them from drifting apart as the product changes and grows at scale.

Losing this distinction has a real cost. A team that calls its component library a design system has the pieces but not the process, and the pieces drift apart within a year because nobody owns keeping them together.

041 min

Where the term design system comes from

The idea is older than the interfaces it is now used to build. In the 1970s the architect Christopher Alexander, working with Sara Ishikawa and Murray Silverstein, described recurring solutions to recurring building problems as a pattern language: a catalogue of patterns that could be combined to design a structure. Software teams adapted the idea for user interfaces starting in the 1980s, and it stayed a niche technical interest through the 1990s and 2000s.

The idea went mainstream in 2006, when Yahoo published its Design Pattern Library alongside its Yahoo User Interface Library, giving interface patterns a public home instead of leaving them buried inside one company's internal wiki. Google's Material Design followed in 2014, and Google called it a design language rather than a pattern library or style guide, the first time a major company used that specific term for its own system.

Most of the systems a reader will recognise today, including Google's Material Design, IBM's Carbon, Salesforce's Lightning Design System, Shopify's Polaris and the UK government's GOV.UK Design System, trace back to that same idea: patterns worth reusing, catalogued once and shared.

052 min

Five real design systems

Five systems make the differences concrete, because each one is real, currently maintained, and has documentation anyone can read.

Carbon is the clearest case of what a maintained system actually looks like in practice. IBM states plainly that Carbon is funded and built by IBM, which means it is built for the company's business needs, but IBM has made it open source for anyone to use and contribute back to. Its component frameworks list a named maintainer for each one, IBM's own team for some, the community for others, so it is always clear who is responsible for fixing what breaks.

GOV.UK runs a comparable model in public. The team states plainly that when it publishes new styles, components or patterns it includes details of how and when they have been tested in user research. It also opens the conversation to anyone: GitHub discussions about a pattern are open to everyone, including members of the public.

062 min

Centralised, federated, and hybrid governance

Every design system needs a governance model: a decision about who gets to change it. There are three common answers.

A centralised model puts one team in charge of building and approving everything. A research study that interviewed nine design-system project leaders found centralisation's clearest benefit is efficiency: one participant described it as a reduction in effort since there is a centralized point of reference that everyone can follow. The cost shows up later: the central team becomes the only path a new component can take, and every product team ends up waiting on it.

A federated model, sometimes called bottom-up, does the opposite. Individual product teams build what they need, and the components that turn out to be useful elsewhere get pulled into the shared system afterward. The same research found practitioners explicitly preferred this direction, with components emerged and elevated from existing digital products, rather than handed down from a central team with no contact with real product work. The cost here is consistency: with nobody centrally approving changes, the system can end up with three different versions of the same button before anyone notices.

Most systems mature into a hybrid of the two. Carbon is a working example. Separately maintained frameworks, Angular, Vue and Svelte among them, are community maintained, while Carbon's own team maintains Elements, React and Web Components directly. IBM's team triages anything contributed without a maintainer. Centralised where consistency matters most, and federated everywhere else, is the pattern that shows up across the systems that last.

Whichever model a system picks, Nielsen Norman Group is blunt about what happens with no model at all: without structure, a shared system can quickly become everyone's concern but no one's responsibility.

072 min

When a design system fails

A design system dies in two different ways, and both are common enough to have names.

The first is under-enforcement. Nielsen Norman Group's Laura Klein describes working with a team that let anyone build anything, as long as it used the approved colours and fonts. Teams kept redesigning components that already existed rather than reusing them, and the result was, in her words, almost as bad as if they had no system at all. A component library with no guidance on when to reuse a piece and when not to invites exactly this: every team quietly forks the button rather than asking whether a shared one already exists.

The second is under-maintenance. A design system takes ongoing work, not a one-off build, and when nobody keeps doing that work the system stops matching what teams actually need, so teams start working around it instead of through it. Klein's account of a single carousel component is the clearest illustration: product managers kept requesting small adjustments until the team had, in her account, dozens of carousel variations, each with its own logic, none of which engineers could maintain together.

The lesson generalises past one company. Without enforcement, the initial investment in a shared system gets diluted by a thousand small compromises until every team is back to doing its own thing, which is the exact state the system was built to prevent. A design system that nobody funds or enforces is not neutral: it is worse than no system, because teams still spend real time on a process that no longer produces consistency.

081 min

How teams decide whether to invest

The decision to build, adopt or skip a design system shows up differently for each role that has to live with it.

A founder at a small team is usually choosing between spending real weeks on a system nobody has asked for yet, or adopting one wholesale. Nielsen Norman Group's own guidance is direct: using an existing design system is the lowest-cost approach and requires the least time to implement. Investment in a custom design system is worth it only when an organisation has needs that cannot be met by an existing, open-source design system.

A product manager runs into the system at the moment a feature needs a component that does not exist yet: build it once for this feature, or file it as a contribution the whole system can use next time. Filing it is slower this sprint and faster every sprint after.

A designer meets it as the difference between exploring a new layout and reaching for an existing pattern. Reaching for the pattern is usually the safer choice, because a pattern used a hundred times has already been tested a hundred times.

An engineer meets it as a maintenance decision. Every component built outside the system is one more thing only that engineer understands, and one more thing that breaks quietly once they move to a different team.

092 min

Building or adopting a design system

Start from what already exists, not from a blank file. Audit the interface elements already shipping across the product, and pull the ones repeated in more than a couple of places into the first version of the system, rather than designing new ones from scratch. This is the bottom-up approach the governance research found practitioners preferred, and it means the first version reflects real usage instead of one designer's best guess.

Staff it before you build it. Nielsen Norman Group sets the floor at a minimum of one interaction designer, one visual designer and one developer, because a design system is only as good as the team maintaining it, and a system with no dedicated owner starts degrading the moment its first version ships.

Write the usage rule next to the component, not in a separate document nobody opens. A button with no guidance on when to use the primary version instead of the secondary one gets used inconsistently, regardless of how well it was designed.

Build accessibility into the component itself, not the page around it. A button built once to meet WCAG contrast and target-size rules is accessible everywhere it gets used; a page checked for accessibility after the fact has to be fixed separately, every time, which is the exact duplication of effort a design system exists to remove.

Decide the governance model before the system grows past one team. Retrofitting a review process onto components that three teams already depend on is far harder than setting one up from the start.

101 min

Design System vs. Design Language

The nearest neighbour term is design language, and the two get used interchangeably even though they answer different questions. A design language is the visual and verbal vocabulary itself: which typeface, which colour palette, which tone of voice, which shapes and materials feel like the brand. It is a set of decisions, not a maintained apparatus.

A design system takes that vocabulary and turns it into something usable at scale: code, components, governance and a team. IBM makes the relationship explicit for its own system, describing Carbon as built with the IBM Design Language as its foundation, with the system itself made up of working code, design tools and resources, human interface guidelines, and a vibrant community of contributors.

A useful test separates the two: a design language can exist on a single slide deck. A design system cannot, because it has to exist in the product, kept current by people whose job includes maintaining it.

112 min

Frequently asked questions about design systems

?7 questions

Questions people ask

§11 sources

Sources