Web Design
Design systems that keep you consistent
A design system is a library of reusable components, colours, type styles and rules, so every new page looks like it belongs and ships in hours instead of days. We build systems your team can actually use.
Who it is for: Teams whose site has drifted into five button styles and three shades of the brand colour, or who ship new pages slowly because everything starts from scratch.
Everything in this service
- Audit of existing UI and inconsistencies
- Design tokens: colour, type, spacing, defined once
- Component library in Figma, matched in code
- Usage rules and documented examples
- Governance guidance, so the system stays maintained
What to expect
- Every page consistent without a designer checking each one
- New pages shipped in a fraction of the time
- Design and code that stay in sync
How design systems actually works
Tokens: the layer everything else depends on
Tokens are named design decisions. Instead of a hex code scattered through fifty files, you have a name that means something, and the value lives in one place. Change the value and every component using that name updates together. That single property is what stops a growing site drifting into five blues and four button heights.
The useful distinction is between raw values and their purpose. A raw token names the value itself, something like blue 600. A semantic token names the job, something like the primary action colour or the border colour for a form error. Components should reference the semantic name. That way a rebrand or a dark theme changes the mapping underneath, and no component needs editing at all.
Spacing deserves particular attention because it is where inconsistency is least visible and most damaging. A defined scale, where each step is a deliberate multiple rather than whatever looked right that afternoon, produces layouts that feel calm even when different people built them. The same applies to type sizes, corner radii, shadow levels and animation durations. Keep the scales short. A spacing scale with twenty values is not a system, it is a suggestion.
- Separate raw value tokens from semantic purpose tokens
- Let components reference purpose, never a raw hex code
- Keep scales short, a small set of choices is what creates consistency
- Cover spacing, type, radius, shadow and motion, not just colour
- Define the tokens once and generate both the design tool and the code from them
Components and patterns: two different things
A component is a reusable piece of interface: a button, an input, a card, a modal. A pattern is an agreed way of solving a recurring problem using those pieces: how a form handles errors, how a destructive action is confirmed, how an empty state is presented. Systems that only ship components leave the harder question unanswered, and teams then solve the same problems differently every time.
A component is finished when its states are finished. Default, hover, focus, active, disabled, loading, error, and the long-content case where a label runs to three lines. Most systems ship the default and let each team improvise the rest, which is exactly where visual drift restarts. Variants need discipline too. Every variant is a decision someone has to make correctly, so a button with three variants and three sizes is usually more useful than one with nine variants nobody can choose between.
Build the components that appear everywhere first. Buttons, inputs, links, cards, typography, layout containers. Resist building an elaborate component for something that appears on one page. A one-off is cheaper to build as a one-off than to generalise, and a system full of rarely used components is expensive to maintain and hard to search.
- Ship every state: hover, focus, active, disabled, loading, error, empty
- Document patterns as well as components, patterns are the harder part
- Fewer variants, chosen deliberately, beat a large permutation grid
- Build the pieces used on every page before anything specialised
- Leave genuine one-offs outside the system
When a design system is worth building, and when it is overkill
A design system is an investment that pays back over time. If there is not enough time ahead of it, or not enough people using it, it never returns the cost. Being honest about that is more useful than selling one to everybody.
It is usually worth it when several people build interfaces, when new pages or features ship regularly, when the same product runs across a site and an app, or when inconsistency is already causing visible problems. It is usually overkill for a small site that changes twice a year, for a single designer and single developer who talk daily, or for a product still changing shape weekly. In that last case the system would be rebuilt as fast as it was written.
There is a middle option people skip. Define tokens and a small handful of core components, and stop there. That captures most of the consistency benefit for a fraction of the cost, and it can grow later if the team does. The failure mode to avoid is starting with an ambitious system, running out of enthusiasm at forty percent, and leaving a half-built library that people work around. A small complete system is far more valuable than a large abandoned one.
- Worth it when multiple people build and pages ship regularly
- Overkill for a small static site or a product still changing shape weekly
- Start with tokens plus a few core components and grow from there
- A small finished system beats a large abandoned one every time
- If nobody has time to maintain it, do not start it
Documentation people will actually read
Most design system documentation goes unread because it describes what a component looks like, which anyone can see, instead of when to use it, which is the thing they cannot work out alone.
The questions a designer or developer arrives with are narrow. Which component do I use here. What are the rules for the text inside it. What do I do when the content is longer than the example. What should I use instead when this one does not fit. Answer those directly at the top of each entry. Guidance framed as a short list of what to do and what not to do, with a picture of each, gets read and remembered. A paragraph of design philosophy does not.
Keep documentation next to the thing it documents, so it is updated when the component is. Documentation in a separate wiki drifts out of date within months and then actively misleads people, which is worse than having none. Include the code snippet, the accessibility notes, and the reason behind any rule that looks arbitrary, because an unexplained rule gets broken by the first person in a hurry.
- Lead with when to use it and what to use instead
- Show do and do not examples side by side
- Keep docs in the same place as the component so they stay current
- Include accessibility notes and the code snippet in the same entry
- Explain the reasoning behind rules, unexplained rules get ignored
Governance and contribution: who decides and how things get in
Every design system faces the same question within a few months. Someone needs a component that does not exist, or needs an existing one to behave slightly differently. What happens next determines whether the system survives.
Two failure modes sit either side. Total openness, where anyone adds anything, produces a library with four similar cards and no authority. Total lockdown, where a small group approves everything and takes weeks, means people stop asking and build outside the system, which is the same drift you were trying to prevent, only now with an expensive library nobody uses.
What works is a light, published process. A named owner or small group, a simple way to propose a change, an agreed response time, and a clear rule that a genuine one-off can be built locally without permission. Set a review point where local one-offs are looked at, because the same one-off appearing three times is the strongest possible signal that it should be promoted into the system. Version the system and communicate breaking changes, so teams can adopt on their own schedule rather than being surprised.
- Name an owner, an unowned system decays quietly
- Publish how to propose a change and how fast you will respond
- Allow local one-offs, then review them for promotion
- Version the system and announce breaking changes clearly
- Track adoption, low adoption is feedback about the system, not the team
How a system lowers cost over time
The saving from a design system is not mainly in drawing screens faster, although that happens. It is in the decisions that no longer need making and the work that no longer needs repeating.
A new page built from existing components skips the whole cycle of designing, reviewing, building and testing each element. Accessibility work is done once inside the component rather than rechecked on every page. A brand colour change becomes a token update instead of a hunt through the codebase. Cross-browser and device testing concentrates on a known set of pieces. New team members become productive faster, because the answer to what should this look like is already written down.
The compounding effect is why the case strengthens with time. The first few pages after building a system may be no faster than before, because you are paying off the setup. From there the cost per page falls, and it keeps falling as long as the system is maintained. The corollary is that an unmaintained system reverses the effect, since people work around a library they no longer trust, and you end up carrying both the workarounds and the library.
- Accessibility solved once per component, not once per page
- Brand and theme changes become token edits rather than sweeps
- Testing concentrates on a known set of pieces
- New team members ship sooner because decisions are documented
- Savings compound only while the system is actively maintained
A clear path, step by step
- 01
Inventory
We catalogue every component and style in use today, and where they disagree.
- 02
Define the foundations
Tokens for colour, type and spacing, agreed once and named clearly.
- 03
Build the library
Components designed in Figma and built in code, with states and variants covered.
- 04
Document and hand over
Usage rules and examples, plus a session with your team so adoption actually happens.
Why choose us for this
We build the Figma library and the coded components together
Sized to your team: a useful system, not an enterprise monument
Documentation written for the people who will use it
Common questions
Is a design system worth it for a small business?
If you publish pages regularly or more than one person touches the site, yes. A small, well-kept system pays for itself in shipping speed and consistency. A five-page site that rarely changes does not need one.
What is a design token?
A named value used everywhere: your primary colour, your heading sizes, your spacing scale. Change the token once and every component using it updates, which is what keeps a growing site consistent.
Explore related work
Want this for your business?
Book a free visibility call and I will tell you honestly whether I can help.
How this is delivered
One person leads every project. Where a job genuinely needs a specialist, I bring in people I have worked with before and manage them, so you get one point of contact and one invoice rather than three suppliers blaming each other.
- You talk to the person responsible for the work, not an account manager
- Specialists are briefed and managed by me, and their work is checked before it reaches you
- One contract, one invoice, one place to chase