Design System: What It Is and How to Build One

A designer changes a button colour in Figma on Monday. By Friday the website has the new blue, the email footer still has the old one, a landing page has a third shade someone sampled from a screenshot, and print has gone to press with a colour matched by eye. Nobody made a big mistake. Everybody made a small, local decision because there was no shared place to check.

That's the gap a design system closes. It's not a prettier folder of assets. It's the craft of making one decision once, testing it properly, and letting every screen, email and printed piece inherit it without a conversation each time.

The Parts a Design System Holds Together

A design system is a shared set of decisions, parts and rules that every screen, email and printed piece draws from, so the same button isn't rebuilt five times by five people. Think of a kitchen. The pantry holds staples measured the same way each time, recipes reuse those staples, and a head chef decides what reaches the menu. Nobody invents a new stock for every dish.

The layers run from smallest to largest. Design tokens are named values for colour, type, spacing and motion. Components combine tokens into buttons, inputs and cards with every state defined. Patterns join components into a task, such as sign-up or returns. Guidelines say when to use each piece and when not to, and the code library is the built, versioned version engineers ship.

Where a System Differs From a Style Guide

A style guide shows how things should look. A design system ships working code and gets maintained like a product, with owners, versions and fixes. That distinction matters most where platforms impose their own constraints, which is why practical guidance on Shopify component governance with Presidio is useful reading for teams connecting a library to a live store.

The same discipline protects premium positioning, where a loose token can cheapen a detail that took months to refine. Teams exploring that end of the market can see how luxury branding decisions hold together when typography, spacing and colour are treated as shared rules rather than page-by-page taste.

A library nobody maintains is just a snapshot of what the interface looked like on launch day.

Linking Brand Identity to Every Channel

Say a skincare brand picks one primary colour, one heading typeface, a clear-space rule around its logo and a plain, confident tone of voice. Those are brand identity decisions, and they have to appear on a website, an email, a carton and a campaign page. Each channel needs the decision in a form it can read, and that's where tokens earn their keep.

A token gives the colour one name. The Shopify product button, the HubSpot landing page call to action, the Klaviyo email footer and the carton stripe all reference color.brand.primary. Change the value once and every surface referencing it updates, instead of sending a designer back through dozens of files hunting hex codes. We map those links early in brand identity work, before channel files multiply.

Where Drift Usually Starts

Drift rarely starts with carelessness. It starts when an email client strips a custom font and nobody specified a fallback stack, or when a print supplier matches a colour by eye instead of working to a specified value. Both gaps get fixed in the token and guideline layers, not in last-minute file edits.

Motion and moving image need the same treatment, with lower thirds, title cards and caption styles defined once. Teams formalising that layer can look at how corporate video production packages repeatable on-screen standards for consistent output.

Check this week: Pick one token and list every place it's used. If the list is short or missing, the links between brand and product aren't in place yet.

How to Build a Design System Step by Step

The build sequence is unglamorous, and that's the point. Craft here means boring groundwork done in the right order, so later work gets faster and cleaner. In Wecomeet's Concept & Design phase, that groundwork covers brand identity and visual language, UX/UI design and user journeys, campaign concepts and key visuals, and design systems and reusable assets, because a system built apart from brand and journey decisions never quite fits either.

Steps One to Three

1. Inventory what exists. Capture every live template across site, email and print, count the button and input variants, and mark duplicates. The common slip is skipping old campaign pages and hidden states, which then resurface after launch.

2. Agree the foundations. Define colour, type scale, spacing and corner radius as tokens named for role, such as color.action.primary, not appearance, such as blue-500. Role names survive a rebrand because the value changes while the name and every reference to it stay put.

3. Build the smallest components first. Start with button, input, link and card in Figma, with default, hover, focus, disabled and error states drawn before anything ships. Skipping focus and error states is the classic slip, and keyboard and screen reader users meet those states first.

Trendy tooling doesn't change this order. Variables, slots and AI agents in Figma speed up production, but they amplify whatever structure already exists. Feed an agent a tidy library and it produces tidy screens. Feed it chaos and it produces chaos faster.

Steps Four to Six

1. Compose patterns from real tasks. Build two or three, such as sign-up, a product filter and a checkout summary, then test them with people who didn't design them. Fresh eyes catch the label that makes sense only to the person who wrote it.

2. Document each piece where it lives. State when to use it, when not to, the content rules and a code example beside the visual. Documentation written as a separate afterthought drifts from the component within weeks.

3. Ship code that matches the Figma file. Review the two together at each release and pull tokens from a single source so values can't diverge. When Figma and code drift, designers stop trusting the file and engineers stop trusting the library.

First milestone: Get one product area running fully on the system before adding anything new. Depth in one area proves the model. Breadth too early just spreads unfinished parts.

That milestone also gives research a real surface to test, rather than polished mock-ups nobody has tapped, tabbed through or read on a phone in bright light. The UX/UI design process behind the build matters as much as the components themselves, because iteration with real users is what separates tested patterns from tidy guesses. Human interaction stays the judge. Tools draft, people decide.

Governing Contributions and Scaling Across Teams

Scale looks impressive in the GOV.UK case, but the interesting part is the rule underneath it. According to the GDS blog marking the GOV.UK Design System going live, the system was publicly introduced in June 2018 and reached a major milestone in 2022 after four years of development. Contributions from service teams get reviewed and incorporated, so an improvement made by one team benefits the rest.

The Validation Rule

The UK government live assessment of the GOV.UK Design System describes a model where each new component or pattern passes a validation process before entering the shared system, cutting duplicated research and design effort across departments. Continuous user research, community feedback and accessibility audits feed iteration. That's governance as craft, not paperwork.

A cross-channel studio can run the same gate with lighter machinery. A component enters the shared library only after three checks:

• Test in flow: The component works inside the task it serves, not just on an artboard.

• Accessibility check: It meets the agreed criteria before merge, not after complaint.

• Implementation review: Code matches the Figma component state for state.

Every token group and component needs one named owner and criteria written on one page. Versioning then becomes routine: a changelog for every release, a deprecation notice with a date, and old versions kept running while sites migrate. Without that discipline, a consistent-looking system can spread the same usability defect across websites, email templates, landing pages and packaging in one release.

Exceptions need daylight too. A third-party checkout, a legacy platform or a campaign deadline gets recorded with its reason, a review date and the person accountable for the fix. Handover closes the loop. Wecomeet's Production & Implementation phase delivers digital and print assets, websites and interfaces, brand guidelines and toolkits, and handover to development or internal teams, and that handover must name who maintains the system after launch. Unowned systems drift fast.

Accessibility Beyond the Component Library

Accessible defaults can live in a design system. Compliance can't. Teams often treat component adoption as the finish line when it's only the starting grid, and an audit is a bad place to learn the difference.

A component can guarantee a visible focus ring, an error message linked to its field, and a target size of at least 24 by 24 CSS pixels. Checked once in the library, those behaviours get inherited everywhere a product ships. A component can't guarantee the content written into it, the field order on a checkout page, a third-party widget, or a campaign image shipped without alternative text.

The GOV.UK Design System accessibility strategy sets a target of WCAG 2.2 Level AA for styles, components and patterns, yet UK government guidance still requires service-specific user research, testing with disabled people, assistive technology testing and an accessibility audit before public beta. Central defaults reduce inconsistent keyboard behaviour, semantics, focus states and contrast rules across teams. They don't remove service-level testing.

A Testing Sequence That Catches Real Failures

Run a keyboard-only pass on every journey first. Follow with a screen reader pass on forms and errors, then a zoom check. The 200 per cent pass is a minimum check, since reflow is judged at 400 per cent zoom, so pages need testing at both before an audit.

Whatever the stack, the working specification stays the same: define accessible tokens and components in Figma and code, document WCAG 2.2 AA acceptance criteria, and test the assembled Shopify, HubSpot, Framer or campaign experience as a whole. Wecomeet works in Figma for UX/UI and design systems and builds on Shopify, Framer or HubSpot, so the check spans both the source file and the production build. Teams managing several client properties will find useful structure in guidance on managing accessibility risks across client sites, particularly around ownership and remediation.

A failing check goes into the exception log with a fix date. It never gets silently inherited by the next template.

Measuring Whether the System Works

A design system has to answer a plain question each quarter. Is it saving work and catching defects, or is it just a tidy file? Four measures give an honest answer.

• Variant count: Repeat the inventory and count button, input and card variants. The number should fall, not climb.

• Detached instances: Count screens overriding a token or component locally, and record the reason for each one.

• Open exceptions: Check each exception against its review date. One past its date has become a permanent fork.

• Template speed: Time a new template from brief to first review. The second and third should be faster than the first.

Add one accessibility line to every review. Note which failing checks came from a component and which came from content or a third-party widget, because the fixes have different owners.

AI belongs in this review too. The Design Week report on the University of Exeter DIGIT Lab survey of 500 UK-based creatives found more than 90% were using AI tools, while 81% of UK designers said AI dulls creativity. Both things can be true. Generators produce variants in minutes, but a person still has to judge them. Keep a generated variant only when someone can name the decision it serves and the component it extends. Volume isn't progress. Better decisions, reached faster, are progress.

Decide Whether Your Team Needs One Now

Three tests settle the timing better than opinion does. Build a system when the same component appears on more than one page or channel, when more than one person edits the interface, and when changing one element already causes errors somewhere else. If only one holds true, a shared style guide with a token file covers a single-editor team for now.

When two or more hold, open with the inventory and scope one product area as the first milestone, such as checkout or onboarding. Plan the calendar. UX/UI or digital redesign projects typically take 4 to 10 weeks, and a rollout covering email and print runs longer because each channel needs its own check against the same tokens. Email templates get checked inside the sending platform, whether that is Klaviyo or Mailchimp, and print artwork gets checked against physical colour and type values.

The model holds at full scale. Wecomeet built an internal design system for Depop with its brand team, with sixteen chapters of brand, product and partner guidelines in one searchable place. Searchable is the operative word. A guideline nobody can find at the moment of need is a guideline that gets ignored.

The first action is a single list. Write down every template and every button variant in use today, including email and print pieces, mark the duplicates, and review it with the person who owns each channel. That list sets the scope before anybody opens Figma.

Wecomeet builds design systems that connect brand identity to websites, e-commerce, email and print, and hands them over to internal teams after launch. Bring the template and variant list, and the first conversation can start from evidence. Visit Wecomeet to talk through scope, owners and a first milestone.