Design

Design Systems

One component library instead of eleven versions of a button

How this is usually engaged

A design system is a product with a lifespan, not a project with an end date. We build the first version and the practices around it, but it needs an owner on your side with time allocated — without that, it becomes another library that drifts out of date. Where you have one product and one team, we will usually advise against building one at all.

Start a project brief

Practice: Product & Interface Design
Sectors: 4 served
Process: 5 stages
Standard: Built and tested to WCAG 2.2 AA

A shared set of tokens, components and rules, implemented in code as well as drawn, with the documentation, versioning and adoption plan that decide whether it survives.

01What this solves

The problem this addresses

Interfaces drift. Two teams, three years and a couple of urgent launches produce four button styles, five spacing scales and a date format that changes depending on which screen you are on. Every new feature costs more than the last because the basics are rebuilt each time, an accessibility fix has to be applied in nine places, and each redesign starts from scratch because there was nothing to change centrally. The cost is invisible until someone counts it.

02Capabilities

What is included

Interface inventory and audit

A documented count of every variant currently in use across your products — buttons, inputs, cards, date formats, spacing values — with the maintenance cost of each duplication made visible.

Design tokens

Colour, type, spacing, radius, elevation and motion defined once and consumed everywhere, including theme variants such as dark mode or a sub-brand, so a change is made in one file rather than in nine repositories.

Coded component library

Components implemented in code with typed properties, sensible defaults and deliberate constraints. Design files and code are kept in step, because a system that exists only in a design tool is a suggestion, not a system.

Accessible component behaviour

Keyboard interaction, focus management, roles and labelling built into each component and tested against WCAG 2.2 AA, so consuming teams inherit correct behaviour rather than reimplementing it and getting it slightly wrong.

Documentation and usage rules

A browsable site with live examples, the properties available, when to use each component, and when not to. The "when not to" section is what keeps a system from being bent into shapes it was not designed for.

Versioning and adoption

Semantic versioning, a changelog, a deprecation policy with notice periods, and a migration path per product so teams can adopt incrementally rather than pausing feature work.

03Use cases

Where this work usually starts

Several products that no longer look related

A main product, an admin area and a customer portal built at different times by different teams, now costing three times over for every change to the basics.

Finance

Rebranding without rebuilding

A brand change that currently means editing colour values across every repository, where tokens would reduce it to one release.

Retail

Making accessibility fixes stick

An audit that produced the same finding in several products. Fixing it in shared components resolves it once and prevents it recurring in the next feature.

Professional Services

04Approach

How we approach it

We inventory what already exists across your products and show you the duplication before proposing anything, because the audit is usually what secures the budget. Tokens for colour, type, spacing and motion are defined first and become the single place those values live. Components are then built in code with a deliberate interface — the properties a consumer may set, and the ones they may not — documented alongside working examples and accessibility notes. Adoption is planned as part of the work: which product migrates first, what runs in parallel, and who owns the system afterwards.

05Process

How the work runs

The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.

01
Audit
Everything currently in use, counted and photographed. This is what makes the case for the work.
02
Define tokens
The values that everything else depends on, agreed before any component is drawn or written.
03
Build the core set
The twenty or so components that cover most screens, built in code with tests and accessibility behaviour included.
04
Document and pilot
One real product adopts the system first, which finds the gaps that a documentation site alone never will.
05
Hand over governance
Contribution process, release cadence, deprecation policy and training for the team who will own it.

06Deliverables

What you receive

Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.

Interface audit and duplication report
Token set and theme definitions
Coded component libraryPublished to a registry you control, with tests and typed interfaces.
Documentation site with live examples and usage rules
Accessibility test results per component
Adoption and governance planMigration order, contribution process, deprecation policy and named owner.

07Technologies

What we use on this work

These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.

Languages & Runtimes

TypeScript

Frontend

React
Next.js
Tailwind CSS

Testing & Quality

Playwright
Vitest
axe-core

The full technology directory

Highlighted entries are used routinely on delivery work

08Security

How this is kept secure

Components escape user-supplied content by default and expose no route to inject raw markup without an explicit, reviewed opt-in, which removes a common class of cross-site scripting from every consuming product at once. Form components set correct autocomplete behaviour and keep sensitive fields out of browser autofill and out of error messages. The library is published to a registry you control, with dependencies pinned, reviewed and monitored, so a compromised package cannot reach every product through the shared layer.

Our full security and quality approach

09Questions

Asked before we start

Do we actually need a design system?

If you have one product, one team and no plans to change either, probably not — the maintenance cost will exceed the saving, and a shared component folder in the repository is enough. It starts to pay when several teams or products are rebuilding the same elements, when brand changes are expensive, or when accessibility findings keep recurring across products.

How long until it pays for itself?

We would rather not quote you a figure, because it depends on how many products adopt it and how quickly, and any number we invented would be marketing. What we can do at audit stage is count the duplicated components and the hours currently spent rebuilding them, so you can make the judgement on your own figures.

What stops teams from ignoring it?

Mostly quality and effort: teams use a system when it is faster and better than writing their own, which means the components have to be genuinely good and the documentation has to answer real questions. Beyond that, a contribution route matters — if a team needs something the system lacks, there must be a way to add it, or they will fork it quietly.

Can you build this on top of an existing component library?

Often that is the sensible route, and cheaper than starting from nothing. An established headless or accessible base library handles the difficult interaction and focus behaviour, and we apply your tokens and constraints on top of it. Building every primitive from scratch is justified only when your requirements genuinely differ from what those libraries provide.

START HERE

Talk to us about Design Systems

The project brief takes about five minutes and gives us enough to have a useful first conversation about Design Systems rather than a generic one. If you would rather just ask a question, the short form is there for that.

Start a project Send a short message

We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.