Build a design system: from brand rules to a usable website

The first page looks good. On the second, the form needs more explanation. On the third, another team rebuilds the button. Everyone has the same brand guide, yet the same task ends up with different solutions.

A design system can reduce this repetition. A tidy design file is not enough. The team needs to know which solution to use, how it behaves and who changes it when it no longer fits.

Our recommendation: build your design system around one real user journey first. Then check whether a second team can adopt the solution. That second use tells you more than the number of finished components.

What a design system needs to do

A design system connects shared design rules with reusable components and a process for maintaining them. It describes not just how an interface looks, but how people design, implement and develop it. NN/g includes both the design repository and the people responsible for it. Design Systems 101

A component library is part of this: it contains elements such as inputs, buttons and navigation. It may already include rules and examples. A style guide defines foundations such as colour, typography and language. The design system connects these foundations with everyday use. It clarifies when an input needs help text, how to write an error message and which tested implementation to use.

One question makes the difference clear: can someone build a new page without having to ask again about the basic decisions behind every component?

When to invest, and when to keep it smaller

Invest where a shared solution actually replaces recurring work. Multiple teams, similar user journeys or regular new pages can justify it. A large page count alone cannot: many pages may rely on a handful of unchanged templates. Conversely, a small product can involve complex states and frequent changes.

Look at the pages or features you implemented most recently. Where were similar elements designed again? Which errors had to be corrected more than once? Where did questions bounce between design, content and development? This gives you a useful initial scope.

For a one-off campaign page, a shared template with a few reusable components may be enough. An extensively maintained cross-product system could create more work than it saves. If the offer itself is still unclear, first establish what people need. A system makes the wrong solution easier to repeat, not more useful.

Plan for maintenance, testing and support for the teams using the system, not just its creation. If nobody can take on that work, reduce the scope. A small, maintained solution is a better starting point than a large collection without an owner.

Which parts belong together?

A digital design system needs rules at several levels. The following breakdown is a working model, not a prescribed architecture. A consultation request shows which decision belongs where.

Design tokens store small design decisions under a name. The Design Tokens Community Group specifies a format for exchanging them between tools. That format alone does not synchronise a website: export, processing, integration and updates still need to be configured. Design Tokens Format Module

Atlassian shows why a token's meaning matters. A token such as color.icon.success specifies the colour of a success icon, not an arbitrary shade of green. Its documentation recommends choosing tokens by purpose. Two colours that look identical today are not necessarily interchangeable. A different theme can expose the mistake. Atlassian: Design tokens explained

What to inspect: under “What are themes?”, Atlassian shows the same Jira interface in light and dark appearances. Compare backgrounds, text and controls. The image demonstrates a change of colour scheme, not a measured improvement in usability. Atlassian: comparing themes

For your team, the lesson is straightforward: define what a value means first. Then decide what to call it and which tools will use it. Otherwise, the old confusion simply gets new variable names.

How brand rules shape an interface

A design system should not reduce brand identity to the correct typeface and colour. How the brand guides people through a task matters too.

Consider a fictional brand that promises clear advice. Its enquiry form should explain which information is required and why. The button might say “Request a consultation”. After submission, the page confirms that the enquiry has arrived and describes the actual next step. Only state a response time if the team can meet it.

Document these decisions. Which information appears before the form? What may editors change? Which explanations must remain? This turns a brand promise into a rule you can test in content and functionality.

Not every page needs to look the same. A campaign can tell its story differently from a support page. What remains shared are the rules that help people find their way and recognise the brand. Allow creative flexibility where the task justifies it, not where someone has overlooked an existing solution.

Content tasks need more than individual buttons

In our fictional consultation example, each service page needs a clear explanation of the offer, credible evidence and an appropriate route to an enquiry. Shared sections might include a service overview, a project example and the enquiry form. The content varies by offer. The team defines together what information each section needs and which states it must support.

Our recommendation: a website system should manage more than individual buttons. It must support recurring content tasks too. If several service pages explain a problem, solution, evidence and next step, the team needs suitable sections for those tasks. A grid alone does not decide which content makes a page understandable.

How to build an initial working system

Start with a clearly bounded pilot that covers one real user task from beginning to end. The following process is our recommendation for a team spanning brand, content, design and development.

1. Choose a journey and identify its bottleneck

Choose a task that occurs in several places. It might be requesting a consultation, choosing a product or registering for an event. Record what currently causes unnecessary work or confusion. “Our buttons look different” is an observation. “Every new enquiry page requires a separate discussion about required fields and confirmation” identifies a specific work problem.

Define what is out of scope for now. A form pilot does not require a new navigation system or every campaign layout to be rebuilt.

2. Review what exists and record your decisions

Collect the existing versions of your chosen journey. Review the implemented pages and their content, not just design files. Sometimes the right solution already exists but is difficult to find. Sometimes two versions look similar but serve different purposes.

Decide together which solution to adopt, adapt or replace. Check whether existing technical components can provide a foundation. Building your own design system does not mean coding every input from scratch. The chosen foundation must suit your requirements, customisation needs, accessibility and future maintenance.

3. Bring design, content and implementation together

Define the purpose, permitted variants, content and relevant states for each required component. An input needs more than its empty default state: it also needs focus, invalid input and useful feedback. The full form needs to handle submission in progress and a possible transmission failure. Decide how people will know their enquiry arrived and what they can do if something goes wrong.

Developers can display these states in isolation using Storybook, for example. Variants are recorded as “stories” and used for development, documentation and tests. The tool supports work on a component; it does not decide when that component is appropriate. Storybook documentation

When the system is used in website implementation, editors need to be involved too. A CMS field for button text does not automatically produce a clear call to action. Document which content may be edited freely and which functional requirements must remain intact.

4. Test the complete journey

Test components individually first, then together on the actual page. Does the form work on narrow screens? Is longer content understandable? Can someone use it with a keyboard? Does each error message explain how to resolve the problem? Check successful delivery and confirmation as well as submission.

GitHub's Primer documents a complementary approach centred on complete user tasks. Its Scenarios Framework describes activities such as creating an issue or adding an organisation member as complete tasks and connects them with accessibility checks. GitHub Primer: Scenarios Framework

What to inspect: GitHub's illustrated guide shows how repository selection, title, description and the create action form one task. The screenshot illustrates the form's structure, not the outcome of an accessibility test. GitHub: Creating an issue

For your pilot, this means “the input works” and “someone can request a consultation” are different tests. Good individual components are necessary, but they do not prove that the full process works. These questions are initial test tasks, not a complete accessibility assessment. Combine technical checks with observations involving people from your actual audience.

5. Plan the second use deliberately

Ask another team or someone previously uninvolved to use the solution on another page. Provide an easy-to-find handover package: usage rules, design templates, implemented components and their states, the approved version and a contact for questions. Do not explain every special case in advance. Observe where questions arise and information is missing. If adoption requires constant personal guidance, the solution is too complex or not documented well enough.

An initial pilot brief might look like this. The example is fictional, not a project measurement:

Maintenance determines whether the system stays useful

Before a wider rollout, decide how changes enter the system. A proposal should identify the specific need and affected applications. Design, content and development review the aspects they own. Then document what changes, who needs to update and whether existing variants remain compatible.

Adding a required field, for example, means more than updating the Figma component. Implementation, content and the affected forms must agree. A shared source helps, but it does not remove the work of reviewing and distributing the change.

Measure the benefit against the work you wanted to improve at the start. For comparable new pages, record which components were reused, which questions remained and which errors recurred. Include maintenance and onboarding when comparing effort. A page designed faster is not a net improvement if it creates more rework elsewhere.

A design system can help your team implement recurring decisions reliably. It does not create demand or guarantee growth. Its value becomes tangible when the team can build another application without reopening the same basic questions, and people can actually use that application.