Design
Design Systems
Genuinely valuable for products and teams. Genuinely wasteful for a brochure site, and sold to both far too often.
A design system is components, tokens and documentation so design survives a growing team. The Nexclick builds one only where more than one person produces work in the brand, or the product keeps growing. For a five-page site it is expensive overhead and we will say so.
Is this you?
What usually prompts the call
- Four people design in your product and it shows across four different button styles.
- Developers rebuild the same component slightly differently on every feature.
- Nobody knows the exact spacing scale, so everything is approximately aligned.
- A designer left and took the only understanding of how the interface works with them.
What we do
The actual deliverables
Things that appear on an invoice, not adjectives.
- Audit what already exists
- Every button, input, card and spacing value currently in use. Teams are routinely surprised by how many variants exist, and the audit alone makes the case.
- Design tokens
- Colour, type, spacing, radius and motion as named values rather than hard-coded hexes. This is what makes a theme change a configuration rather than a project.
- Component library
- Built from what you actually use, with every state — default, hover, focus, disabled, error, loading. Components missing states get reimplemented inconsistently.
- Accessibility built into the components
- Focus states, contrast, keyboard behaviour and labelling correct at component level, so every use inherits it rather than each developer solving it again.
- Documentation with usage rules
- Not just what a component looks like but when to use it and when not to. Systems fail on the second question, not the first.
- Design and code parity
- Figma components matched to coded ones, with a process for keeping them aligned. A system where the two diverge is worse than none.
- Governance
- Who can add a component, how changes are proposed, and how the system is versioned. Without this, systems fragment within a year.
Decision tree
Do you need a design system, or just a component set?
Design systems are sold far more often than they are justified. Work through these — several branches point at something considerably smaller and cheaper that will serve you better.
01You have a five-page marketing site and one designer
No system. A component set inside the design file is sufficient. A full system is overhead you will pay for and never recover.
02One person designs and one person builds, and that will not change
Component set, documented lightly. Systems solve coordination problems, and you do not have one yet.
03Several people produce designs and consistency has already slipped
A system is justified. The audit alone will surface how far apart things have drifted, which usually settles the internal debate.
04Developers keep rebuilding the same components slightly differently
Yes, and start with coded components rather than Figma. The engineering side is where the waste is.
05You have multiple products or brands sharing a foundation
A system with themeable tokens. This is the case where the return is clearest and largest.
06Nobody will own it after we hand it over
Do not build one. An unmaintained system diverges from the product within months and becomes actively misleading. A component set is the honest answer.
07You want one because competitors publish theirs
That is a marketing artefact, not a system. Published design systems are a recruitment signal for large companies and rarely a reason for you to build one.
How it works
Step by step, with timeframes
Timeframes are typical rather than guaranteed, and they assume we get account access and approvals when we ask.
- 01Week 1–2
Audit and decide scope
What exists, what is genuinely needed, and whether a full system is justified at all. Sometimes the honest answer is a component set rather than a system.
- 02Week 2–4
Tokens and foundations
Colour, type, spacing and motion defined as tokens, with accessibility verified at this level so everything above inherits it.
- 03Week 4–9
Build components
In priority order — the ones used most, first. Each with every state, in both design and code.
- 04Week 9–11
Document and govern
Usage documentation, contribution process and versioning, plus a session with the team who will maintain it.
What you get
Reporting and ownership
- An audit showing every variant currently in use, which usually makes the case on its own.
- Tokens in a format both design and code consume, so they cannot drift apart.
- Components with every state built and tested, not just the default.
- Documentation covering when not to use a component, not only how it looks.
- A written governance process, without which systems fragment within a year.
Tools and platforms
- Figma (components, variables, variants)
- Storybook
- Design tokens (JSON / CSS custom properties)
- React or your framework of choice
- axe-core (component-level accessibility testing)
Timeline
How long this actually takes
Ten to twelve weeks for a substantial system, though it is better delivered incrementally — tokens and the most-used components first, so the team gets value from week four rather than week twelve. The honest caveat that matters most here: a design system is only worth building if it will be maintained. An unmaintained system diverges from the product within months and becomes actively misleading, which is worse than having none. If nobody will own it, we will recommend a simpler component set instead and say why.
Pricing model
Fixed-price project
Fixed price by component count, or a day rate for incremental delivery alongside an existing team. We will scope it down where a full system is not justified.
Questions
Design Systems questions
What is the difference between a design system and a component library?
A component library is the components. A system adds tokens, usage rules, accessibility standards, documentation and governance. The library is the visible part and the governance is what determines whether it still reflects the product in two years.
Should we use an off-the-shelf system?
Often, yes. Material, shadcn/ui or similar give you accessible primitives for free, and building from one is faster and safer than starting blank. What you add is your tokens and your usage rules. Building components from scratch to look different is rarely a good use of budget.
How do we stop the system diverging from the product?
Governance and a single source for tokens that both design and code consume. Divergence is not a discipline problem, it is a process one — if a developer can add a one-off component with no route to contribute it back, they will, and so will the next one.
How long before it pays for itself?
For a team of three or more producing features regularly, typically six to twelve months in saved rework and faster delivery. For a smaller team or a static site, possibly never — which is why we scope this down rather than up when the case is not there.
Do we need Storybook?
Useful where developers need to see components in isolation and test states, which is most product teams. Overhead where the system is small. It is a tool decision rather than a principle, and it should follow from whether anyone will actually open it.
Can you build the system into our existing codebase?
Usually, and it is generally better than a greenfield rewrite. We start by consolidating what already exists into consistent components rather than replacing everything at once, which lets the team keep shipping while the system takes shape.
Last reviewed 28 July 2026.
Tell us what you are trying to fix
A 20-minute call, no pitch deck. The Nexclick will tell you what we would do, roughly what it costs, and whether we are the right people for it.