Brand guidelines vs design system: what to build, and when

Two artefacts, two different questions

A set of brand guidelines answers: what does this organisation look and sound like, and how do we keep that recognisable wherever it appears? Its audience is anyone producing something on the organisation’s behalf — an agency, a printer, a sponsor, a new hire in marketing.

A design system answers a narrower and more operational question: what exactly should we build, and what does each piece do in every state it can be in? Its audience is people making interfaces, mostly designers and developers, mostly internal.

Nielsen Norman Group defines a design system as a complete set of standards intended to manage design at scale using reusable components and patterns, and separates that from a style guide, which contains implementation guidelines, visual references and design principles. The distinction that matters commercially is not the vocabulary. It is that a style guide tells a person what to do, while a design system hands them something to use. One is a document. The other is a product with internal users, and it has running costs to match.

	Brand guidelines	Design system
Question answered	What do we look and sound like?	What do we build, and how does it behave?
Primary audience	Anyone producing work for the brand	Designers and engineers building interfaces
Typical form	A document, plus asset files	Tokens, components, code, documentation
Changes when	The brand changes — rarely	The product changes — constantly
Fails by	Being ignored	Being out of date
Evidence it works	Output looks like the brand	Teams reuse it instead of rebuilding

Most requests we receive for “a design system” describe a coherence problem — the site has four button styles, the app looks like three products — and coherence problems are often governance problems wearing a tooling costume. That does not mean a system is the wrong answer. It means the answer is not only an artefact.

What belongs in brand guidelines, and what does not

Good guidelines are shorter than most organisations expect and more specific. The core is: the logo and its lockups with clear space and minimum sizes; the colour palette with values in every colour space you actually use; typography including licences and the fallback stack when the licensed face is unavailable; photographic and illustrative direction with examples of what is wrong as well as what is right; and voice, which is the part most often omitted and most often needed.

What does not belong is a decision that only makes sense in an interface. Guidelines should not attempt to specify how a form validates or what a disabled control looks like, because those decisions depend on context the brand document cannot see.

But there is a gap that catches organisations repeatedly. Guidelines produced for print are not a digital foundation, and the shortfalls are consistent enough to list:

• No type scale at interface sizes. A headline specification designed for a poster says nothing useful about a 13-pixel table label.
• Colour pairings that fail contrast. WCAG 2.2 requires a contrast ratio of at least 4.5:1 for text, 3:1 for large-scale text — defined as at least 18 point, or 14 point bold — and 3:1 for user interface components and meaningful graphics. Brand palettes are chosen for feel, and a mid-tone accent that looks confident on a billboard is frequently illegible as body copy.
• No focus state. Nothing in a print document has to describe what happens when a keyboard user tabs onto something.
• No behaviour under motion, loading or error.
• No dark mode.

Filling those gaps is part of what a brand and graphic design engagement should cover if the brand is going to live anywhere digital, and it is far cheaper to resolve while the palette is still negotiable than after the palette has been printed on a building.

What a design system adds: tokens, components and code

Three layers sit on top of the brand.

Design tokens are the named values — colour, spacing, type size, radius, elevation, motion duration — held in one place and referenced everywhere instead of being retyped. This is no longer a proprietary idea: the W3C Design Tokens Community Group exists to provide technology that products and design tools can rely on for sharing stylistic pieces of a design system at scale, and published a stable specification in October 2025 covering the token format, colour and resolution, with the major design tools implementing it. The practical consequence is that a change to a token propagates, and that tokens can be exported to web, iOS and Android from one source rather than maintained three times — which is the argument for tokens in any organisation shipping a mobile app alongside a website.

Components are the reusable interface pieces with their states resolved. The organising vocabulary most teams borrow is Brad Frost’s atomic design, which builds from atoms — the foundational building blocks — through molecules, relatively simple groups of elements functioning together, to organisms, templates and pages. You do not have to adopt the terminology. You do have to decide where a thing lives and stop inventing a fourth card treatment.

Code and documentation are what turn the first two into something a developer uses instead of approximates. Storybook describes itself as a frontend workshop for building UI components and pages in isolation, and the reason teams reach for it is not the documentation site: it is that isolation forces you to build the states nobody remembers otherwise — empty, loading, error, long content, no permission. If the coded component library is out of scope, be clear that what you are commissioning is design intent, and that the engineering team still has to build and maintain the real thing.

The maintenance cost nobody puts in the quote

Here is the part that gets left out of proposals, including some of ours until we learned better.

NN/g frames design-system maturity across six dimensions: organisational alignment, team effectiveness, infrastructure robustness, governance, support and adoption. Read that list again and notice that exactly one of the six — infrastructure — is about the artefacts. The other five are about people and operating models. A delivered system is one dimension of six, which is why so many of them are abandoned within a couple of years by organisations who paid for something excellent.

NN/g is equally direct about the ongoing obligation: design systems require continuous maintenance and oversight to avoid becoming outdated, obsolete or overcrowded with redundant entries. Left alone, a system does not stay still. It goes stale, teams route around it, and you now have inconsistency plus a maintenance liability.

So the honest question at commissioning time is not “what will it cost to build”. It is “who, by name, will spend part of each week on this in eighteen months, and does their manager know”. If there is no answer, buy something smaller.

Signals that you are ready for a design system

You are probably ready when several of these are true:

1. More than one team ships interface work, and they have started to diverge.
2. Developers are rebuilding the same control repeatedly because finding the last one is slower than writing a new one.
3. The same accessibility defect keeps recurring in different places, which means it is being fixed in instances rather than at source.
4. A brand refresh would require touching hundreds of hard-coded values.
5. You ship to more than one platform and want them to agree.
6. Design review is spent on whether a spacing value is right rather than on whether the flow works.

Point six is the one worth watching. When senior people are arbitrating padding, the cost of not having a system has already exceeded the cost of building one.

Signals that you are not

The counter-list is shorter and less often said aloud.

You are not ready if the product has not settled. Systematising an interface that is still being invented locks in decisions you are about to reverse, and the system becomes a tax on exactly the experimentation you need. Pre-product-market-fit, a shared stylesheet and a weekly design review will serve you better.

You are not ready if one person makes all the interface decisions and ships all the work. A system is a coordination mechanism, and coordination costs are low at that size. The formality will slow you down and produce documentation nobody reads.

And you are not ready if the request is really about consistency on a marketing site with five templates. That is solved by a token set and a rule about who may add a component, both of which fit inside a normal web design engagement without any of the surrounding machinery.

A minimum viable system: one token set and eight components

If you want to do this without an agency — and plenty of teams should — this is a version you can build yourselves.

Start with an inventory. Screenshot every button, input, card and alert currently in production. Put them on one wall. The wall is the business case, and it is usually more persuasive than anything a consultant can say.

Then define one token set: a colour ramp with semantic names (surface, text, border, accent, danger) rather than literal ones, a type scale of six or seven steps, a spacing scale on a consistent base, two or three radii, two elevations, and two motion durations with their easing curves. Semantic naming matters more than it sounds — color-text-muted survives a rebrand and grey-400 does not.

Then build eight components, each with every state drawn and coded:

1. Button, in its variants
2. Link, including within body text
3. Text input, with label, hint, and error message
4. Selection controls — checkbox, radio, select
5. Card
6. Navigation, including the mobile behaviour
7. Dialog
8. Notification or inline alert

Eight is not arbitrary. Those cover the overwhelming majority of interface surface on most sites and small products, and the discipline of finishing them properly teaches the team more than a partial attempt at forty. The states each one needs: default, hover, focus-visible, active, disabled, loading, error, and empty where applicable. Most design debt lives in the states nobody drew.

Stop there until the eight are genuinely being reused. A system that is used and small beats a system that is comprehensive and ignored.

Accessibility belongs in the system, not in a later audit

This is the single strongest argument for building a system at all, and it is an economic one rather than a moral one: a fix applied to a component is applied everywhere at once, and a fix applied to a page is applied once.

Three things to build in rather than retrofit. Colour pairings verified against the WCAG contrast ratios above, recorded as approved token combinations so nobody has to re-derive them. Target sizes meeting WCAG 2.2’s requirement of at least 24 by 24 CSS pixels — with its documented exceptions for spacing, inline targets, equivalent controls, user-agent-controlled sizing and cases where a presentation is essential — enforced in the component’s padding rather than left to whoever assembles the page. And interaction behaviour taken from the ARIA Authoring Practices Guide, which documents reference patterns for around thirty widgets including accordion, combobox, dialog, disclosure and tabs, so your team is not reinventing keyboard handling for a menu that has been solved for a decade.

Doing this at component level is what makes an accessibility commitment sustainable rather than a periodic remediation project, which is the subject of our WCAG 2.2 guide in more detail.

Governance: who owns this after the agency leaves

The most useful public model is the GOV.UK Design System, because its rules are published and it has survived long enough to prove they work. A component is proposed only if there is evidence it would be useful to many teams and does not duplicate something existing. Before publication it must be usable — tested in user research and shown to work with a representative sample of users including disabled users — consistent with existing styles and coding standards, and versatile enough to work across a range of services, browsers, assistive technologies and devices.

You do not need that apparatus at a tenth of the scale. You do need the shape of it: a written route for proposing something new, a stated bar it must clear, someone empowered to say no, and a visible record of decisions. Without the ability to decline a contribution, a system accumulates until it is a catalogue of everything anyone has ever built, which is the failure mode NN/g describes as becoming overcrowded with redundant entries.

Decide the ownership model before the work starts, because it changes the deliverable. A central team owning the core needs excellent documentation. A federated model needs stronger contribution rules and a regular forum. If the answer is that an external partner will maintain it indefinitely, price that as an ongoing service and be honest with yourselves about the dependency you are accepting.

Choosing your next deliverable

The decision usually resolves quickly once framed properly.

If your organisation has no agreed visual identity, or one that predates your current positioning, build brand guidelines. Nothing downstream is stable until that is settled, and systematising an identity you are about to change is wasted work.

If you have an identity that people follow, but every implementation of it looks slightly different and different teams keep solving the same interface problems, build the minimum viable system above — and appoint the owner first.

If you have neither problem and you are here because a competitor published a design system, build nothing. That is a real answer and we have given it.

Where this becomes a conversation rather than a checklist is the middle case: a brand that mostly works, digital gaps that need filling, and a product team that could maintain a system if someone set it up properly. That is genuinely the most common situation, and it usually calls for a brand extension into digital plus a small component set — work that sits across graphic design and UI/UX design rather than neatly inside either. Whether you resource that internally, with a freelancer, or with an agency depends on what happens after handover, which is worth thinking through using the comparison in our guide to that decision.