UI/UX Design

Design systems for growing products

If you have five kinds of button and two teams building the same date picker, a design system could save you money. If you have one small product and three people, it probably won’t yet.

Discuss Your Project

A design system is a shared set of decisions, including colours, spacing and type as tokens, components such as buttons, forms and dialogs, and guidance on when to use them. The design side lives in Figma and the code side in a component library, and the real value comes when the two match. Teams stop rebuilding the same things, and accessibility fixes made once carry over everywhere.

The cost is upfront work and ongoing ownership. A system that nobody maintains goes out of date fast, then people stop trusting it and go back to working around it. That’s why governance matters as much as the components: who owns it, how people propose changes and how new versions get released. For smaller teams, it’s often more sensible to adopt an established library such as Radix or shadcn/ui and customise it.

Start from what you already have

We start by auditing your live products to see what exists, including every shade of grey and each button variant. This shows up the duplication, and makes the case for the work. Then we build the most-used components first, roll them out on real screens and grow from there. Trying to design everything in advance is a classic way of producing a beautiful library that nobody adopts.

Signs you need one

Visible inconsistency

Screens built by different teams look and behave differently.

Repeated work

Designers and developers keep recreating components that already exist elsewhere.

Rebrands that take forever

Changing a colour means hunting through thousands of hard-coded values.

Accessibility fixes repeated everywhere

The same dialog bug needs fixing in six different places.

What we deliver

Interface audit

A catalogue of what you have now, along with the duplication.

Design tokens

Colours, type and spacing, defined once and shared between design and code.

Figma library

Well-organised components with variants that designers will actually use.

Code components

Accessible, tested React or Vue components, documented in Storybook.

Governance

A contribution process, versioning and clear ownership.

Where it fits

  • Companies with several products or teams
  • Fast-growing SaaS products
  • Preparing for a rebrand

Technology

  • Figma
  • Storybook
  • React
  • Vue
  • TypeScript
  • Style Dictionary
  • Radix UI
  • shadcn/ui
  • Chromatic

Design Systems questions

When is a team big enough for a design system?
There’s no fixed size. It usually starts paying off when you have several teams or products, or if you’re regularly rebuilding the same components.
Should we build our own or use an existing library?
Many teams should start with an established library and customise it. A fully custom system makes more sense at a larger scale or when you have very specific needs.
How do we get teams to adopt it?
Make it the easiest option, include people from those teams from the start and migrate real screens early. Good documentation and a responsive owner matter far more than a launch event.

Related services

Interested in Design Systems?

Outline what you need, and we will reply by email with questions or next steps.

Start a Project