A Design System for a Small Brand — Not a Luxury, an Economy

The objection always arrives in the same shape: design systems are for Google, Airbnb and Shopify, not for a law practice with eight pages. That is a confusion of scale, not of principle. What large companies run is a library of hundreds of components, with governance, npm versioning and a dedicated team. What a small brand needs is something else entirely: a set of decisions made once, in writing, instead of the same decisions made ten times, badly, at different hours of the night.

The gap between a site that looks expensive and one that looks improvised rarely comes down to the designer's talent. It comes down to consistency. Three greys instead of one, four font sizes for the same level of text, corner radii that drift between sections — the visitor never names the problem, but feels it, and translates it instantly into distrust. It is the same mechanism I unpack in what a brand actually is beyond the logo.

A design system is not a design deliverable. It is an architectural decision that pays itself back on every new page.

A system that is genuinely useful to a small brand fits in a single CSS file and holds six families of tokens. Nothing more, at the start.

• Color. Three or four brand colors, each with two or three steps, plus a neutral ramp of five to seven. If you find yourself needing a fourth grey, the system is telling you that you have a hierarchy problem, not a palette problem.
• Type scale. Six or seven steps, generated from a fixed ratio, not picked by eye.
• Spacing. One base unit and its multiples. Everything else is arithmetic, not taste.
• Radius. Three values: small, medium, fully rounded. More than that is noise.
• Shadow. Two or three elevation levels, all sharing the same light direction.
• Motion. Two durations and two easing curves. That is the entire budget.

Components come afterwards: button, form field, card, badge, navigation, footer. If the tokens are right, the components almost write themselves, because you are no longer making visual decisions while building them — you are choosing from a closed list.

A hex code typed straight into a component is a decision that can never be renegotiated. A variable is a decision that can be renegotiated once, somewhere else.

The practical test: the client moves the brand accent from blue to deep green. With one-off values you search the whole project, miss three places, and one of them is the hover state of a button inside a form nobody opens — until the day the director opens it. With tokens you edit one line. The same mechanism is what makes dark mode possible without rewriting anything: you redefine the token values under a preference query, and the components never learn that anything changed.

This is where most amateur systems break. Literal names describe the pigment: --color-red, --color-blue-light, --font-24. They work perfectly until the day red becomes burgundy and you are left with a variable called red that renders maroon. Semantic names describe the role: --color-primary, --color-danger, --color-surface, --color-text-muted, --text-lg.

The healthy practice has two layers. A primitive, literal layer that holds the actual pigments, and a semantic layer that assigns them roles. Components consume the semantic layer only. A rebrand touches the primitives. Dark mode touches only the semantic mapping.

• Bad: --gray-3 used directly for secondary text.
• Good: --color-text-muted, which points at --gray-3 today and at something else tomorrow.

If you only have time for one thing, do this one. Pick a base size — 16px on the web — and a ratio: 1.2 for dense interfaces, 1.25 or 1.333 for editorial sites. Generate six steps up and one down, round to whole numbers, and forbid yourself every other size. Fix the line heights in the same pass: tight for headings, generous for body copy.

Spacing works identically: one base unit of 4px or 8px and a scale of multiples. The rule I apply is that space inside an element must always be smaller than space between elements, and space between sections must be at least double the space between blocks. Proximity then becomes a grouping signal rather than an accident. A layout built on a coherent scale reads as calm even when the content is mediocre.

A component is not a button. It is a button in seven situations. Cheap systems document the first state and abandon the rest.

• Rest — the only one you ever see in Figma.
• Hover — a visible difference, not a cosmetic one, and only on pointer devices.
• Visible focus — mandatory, not optional, with an outline that survives colored backgrounds. It is also a requirement I cover at length in accessibility as a competitive advantage.
• Active — immediate press feedback, under 100ms.
• Disabled — visibly inert but still above the contrast threshold; light grey on white is a trap.
• Loading — the width must not jump when the label becomes a progress indicator; reserve the space up front.
• Empty and error — a result list with nothing in it and a rejected form are product screens, not exceptions. Write their copy before you write the code.

Documented in the system, these states are inherited for free by the third page. Without a system, every page reinvents some of them and skips others entirely.

The first page built on a system is slower than an improvised one. The second breaks even. From the third onwards the system pays. On a real eight to ten page project, the cumulative saving lands around twenty to thirty percent of implementation time, plus a near-total collapse in visual revision rounds — because there are no decisions left to renegotiate, only components to assemble.

There is a performance dividend few people anticipate as well: a constrained system produces smaller CSS and fewer font variants to load, which shows up directly in your Core Web Vitals numbers.

Do not build a system for a three-week campaign landing page. Do not build one before you know what the brand looks like. Do not build one for a five-page site that will never be touched again — there you only need discipline: the same five or six values, used consistently. A premature system costs exactly as much as having none, except you pay for it up front.

My practical threshold: if the site passes eight pages, or if it will grow within twelve months, or if someone other than me will touch it, the system justifies itself.

The cost argument has expired. Native CSS variables are supported everywhere and can be redefined on any selector, which turns theming into a few lines of work. Tailwind v4 moves configuration into CSS itself: tokens are declared as variables inside a theme block, and utility classes are generated from them. There is no longer a JavaScript config file drifting out of sync with the real stylesheet. In practice, the design system and its implementation become the same artifact.

The last argument is commercial, and it is the one that ends the discussion. A site without a system is a site only its author knows how to change. That looks like leverage for the supplier and is a disaster for the client.

A proper handover contains one commented token file, an internal page showing every component in every state, and three or four rules written in plain language: which color for what, which text sizes exist, how things are spaced. With that, any competent developer can pick the project up months or years later. You can see what those deliverables look like across the projects in my portfolio, and if you want an assessment of what you already have, get in touch.