A Kit, Not a Catalogue: Building a Minimum Viable Design System for a UK Product Team

Somewhere in most UK software products there are three primary buttons. One was built during the initial sprint, one was added by a contractor in a hurry, and one was copied from a competitor's site and never quite matched. They are all slightly different heights, two of them fail a contrast check, and the focus state on one has never worked on Safari.

No single decision produced this. It is simply what happens when a small team ships quickly without a shared vocabulary. The usual remedy offered is a design system, which is also the usual reason nothing gets fixed, because design systems are typically described as programmes with their own team, documentation site, governance model and contribution framework.

A product team of four engineers and one designer cannot run that. It can, however, run something smaller that prevents most of the damage.

Why the enterprise model does not transfer

Large design systems earn their overhead because they serve dozens of squads and hundreds of screens. The coordination cost is real, but so is the return. At SME scale the arithmetic inverts: a governance committee of three people who also write the code is not governance, it is delay.

Yet the problems a design system solves do not disappear at small scale. They simply appear in a different form. Instead of inconsistency across eight products, you get inconsistency across two, plus a support burden, plus an accessibility debt that gets re-litigated every time someone new joins.

The right ambition is not a comprehensive library. It is the smallest set of shared decisions that stops the same work being done twice.

The test a component must pass

Before anything is built, agree a rule for admission. A workable one is this: a component earns a place in the kit only if it is already used in at least three distinct places and has been built from scratch more than once.

That rule does two useful things. It keeps the library demand-led rather than speculative, and it means the first version ships in weeks rather than quarters, because everything in it is already needed today.

Tokens first, components second

Before a single button is abstracted, the team should settle the underlying decisions: colour palette including semantic roles, a spacing scale, a type scale, breakpoints and border radii. These are the tokens, and they carry more leverage than any component.

Getting colour into tokens is particularly worthwhile for UK teams with public sector or regulated clients, because contrast requirements are then resolved once at the palette level rather than argued about on every screen. A semantic naming scheme, where a role rather than a hex value is referenced, also makes a later rebrand a token change rather than a forensic exercise.

A shortlist that is genuinely sufficient

For most small products, the first release needs roughly a dozen items and no more:

• Button, in a small number of defined variants
• Text input, including label, hint and error states
• Form field wrapper and form layout
• Select and checkbox
• Card or summary panel
• Data table with defined responsive behaviour
• Modal dialogue with focus management
• Notification or inline alert
• Page header and breadcrumb
• Empty state and loading state

Each of these should be built to a consistent standard rather than merely styled consistently. That means keyboard operation, visible focus, correct labelling, and error messaging that is announced to assistive technology. Building accessibility into the component once is the single largest dividend of the whole exercise.

One owner, one page of rules

The difference between a design system that survives and one that quietly rots is rarely tooling. It is ownership. Name one person, typically the front-end lead or the designer who works closest to the code, as the owner of the kit. Their responsibilities are narrow and clear: review changes, keep the changelog, decide when something is deprecated.

The rules should fit on a single page. A useful shape is:

1. If the kit already covers the need, use it. Do not fork it locally.
2. If it nearly covers the need, propose an extension through the owner rather than building a parallel version.
3. If it does not cover the need and the need is real, build it in the product first, then propose promotion into the kit once the three-use threshold is met.

That third rule matters. It prevents the library filling with speculative components nobody uses, and it keeps the kit honest about what the product actually requires. A weekly review slot of fifteen minutes is generally enough throughput for a team of this size.

Versioning should be simple: semantic versioning, a changelog entry for every change, and a stated deprecation window so downstream work is not broken without warning.

Measuring whether it is earning its keep

A design system that is not measured becomes a cost centre, and cost centres get cut. The metrics that matter at small scale are modest and easy to collect:

• The number of screens or features built using kit components rather than bespoke markup
• Time to build a standard form screen, estimated before and after
• Repetition in design review comments, particularly the same spacing and state feedback appearing across projects
• Accessibility findings that recur, which should trend towards zero for component-level issues
• Onboarding time for a new developer to ship their first interface

Be candid about the curve. The first quarter costs more than it saves, because the team is building the kit and the product simultaneously. The payback appears in the second and third quarters, and it is most visible in review time rather than in raw development hours.

Where it intersects with procurement and handover

Two commercial situations make a small design system disproportionately valuable.

The first is buying a build. When commissioning an agency or a fractional team, the component kit and token set should be named as deliverables in the contract, alongside the source repository. A product handed over with a documented kit is materially easier to extend than one where every screen is bespoke.

The second is a change of supplier or an internal reshuffle. The cost of a new team picking up an unfamiliar codebase is dominated by the time spent working out which patterns are intentional and which are accidents. A kit with a changelog answers that question in an afternoon.

The failure modes worth avoiding

Three mistakes account for most abandoned attempts. The first is building the documentation site before the components, which produces an impressive shell around very little. The second is allowing the kit to drift from the product, usually because the kit lives in a separate repository that nobody updates. The third is a governance model so heavy that contributors stop contributing and start copying.

Keeping the kit in the same repository as the product it serves, or in a package consumed on every build, prevents most drift.

The measure of success is unglamorous: nobody has built a fourth primary button in six months, and the accessibility audit no longer returns the same finding five times.