Building a Design System Without Stopping Product Delivery

COMPANY

Under NDA

DOMAIN

B2B SaaS · no-code platform

DURATION

9 months

TEAM

1 designer + Frontend + PM + QA

SCALE

100–150 components

STATUS

Library complete, 100% adoption

TL;DR

Design system from scratch

The product is a B2B no-code platform where teams build operational dashboards and workflow automations. It was scaling fast, the UI wasn’t: conflicting patterns everywhere, handoff through verbal agreements, 5–7 rounds of back-and-forth per component.

I built a design system from scratch — token architecture, full component library, Figma documentation, Storybook and Chromatic integration — without pausing feature delivery. Iterations dropped from 5–7 to 1–2. Visual QA fixes went from 3–4 per sprint to almost zero. 82% of component code shipped to production without rework, and every screen now runs on the system.

RESULTS

What changed

ITERATIONS PER COMPONENT

1–2

down from 5–7

VISUAL FIXES PER SPRINT

0–1

down from 3–4

CODE TO PROD WITHOUT REWORK

82%

new baseline

SCREENS ON DS

100%

migration complete · 9 months

Metric

Before

After

Iterations per component

5–7

1–2

Visual fixes per sprint

3–4

0–1

Component code shipped without rework

—

82%

Screen adoption

0%

100%

01 — CONTEXT

Two users, one interface.

Two composite personas: the Operator, who lives in the interface all day, and the Manager, who checks in a few times a week — context, needs from the interface, what breaks, and what the system has to guarantee

The platform serves two types of users: technical operators who live in the interface all day and non-technical managers who check in less frequently. Both work with dense, state-heavy screens where a wrong status or missed error state has real consequences. The goal was to keep the interface visually polished while making it technically clear and readable.

Consistency here isn’t about polish — it’s about reliability.

CONSTRAINTS

No dedicated DS team. No design freeze. Active backlog throughout. The system had to be self-sufficient — developers and PM use it without pulling the designer into every question.

PROBLEM

No shared UI language. The same pattern existed in 3–4 variants depending on who built it. Components in Figma didn’t match code — developers filled in the gaps, which meant 5–7 clarification rounds per component. Visual bugs were caught at QA, not before.

The platform was about to grow. Building on top of that would have compounded the debt with each release.

02 — MY ROLE

What I owned, what I shared.

UI audit, before and after: the same settings pattern built four different ways, replaced by one tokenised component with every state — button, input and status badge

LED

UI audit · token architecture (primitive + semantic) · 100–150 components with full state coverage including composites · Figma documentation · Storybook + Chromatic integration · AI tooling for documentation and state coverage

WITH THE TEAM

Prioritisation with PM (Jira) · token naming alignment with frontend · composite structure with developers · Chromatic PR flow with QA

03 — PROCESS

Five stages, no design freeze.

01

STEP

Audit

Identify duplicated patterns and inconsistent components across the live product.

02

STEP

Foundations

Token architecture: primitive layer + semantic layer for theming and maintenance.

03

STEP

Components

100–150 components, primitive + composite, full state coverage including hover, disabled, error.

04

STEP

Documentation

Usage rules, dos/don’ts, annotated states, composite templates — all inside Figma.

05

STEP

Dev integration

Storybook with composite docs. Chromatic visual diffs on every PR with designer approval in flow.

Design system foundations and tokens: eight token systems, primitive and semantic, with a colour token, a radius token and the tokens in code

CORE BET

Rolling migration instead of design freeze. New screens go through DS from day one. Existing screens migrate on first touch in feature work. Agreed with PM upfront.

04 — KEY DECISIONS

Six calls that shaped the system.

01

KEY DECISION

Two-tier tokens, named with dev before the first commit

Two problems would both compound at 100+ components — palette changes touching every file, and design and dev naming the same tokens differently.

Without a semantic layer, every theme change or palette shift would propagate through every component file — maintenance debt by design. In parallel, design and code referenced the same tokens by different names; at 100+ components that drift would harden into code and become impossible to reconcile retroactively. The fix: a two-tier architecture — primitives hold the raw values; semantics reference primitives and carry intent (bg/canvas, text/inverse, accent/default); components consume semantics only. And before implementation began, one joint session with frontend locked a shared naming convention for every primitive and semantic token.

Components reference what a colour does, not its hex value — a cleaner contract with code, easier to maintain, and the foundation for dark mode and per-client themes without rework. And naming can’t be “agreed later”: conventions harden on first commit, so a 90-minute session up front replaced months of avoidable refactoring.

Two-tier tokens: colour primitives mapped to semantic variables in Figma, the token naming anatomy, and the spacing scale reworked after a session with the developers

02

DECISION

Composite component hierarchy and documentation

Moving from atoms to composites exposed three problems at once: Figma structure didn’t match code, state inheritance wasn’t documentable, Storybook had no pattern for composites. We added a composite tier and a dedicated template.

Component configuration for a primary button and for a search-bar composite: states, layout, typography, colours, and how focus and disabled states are inherited by the children

03

DECISION

Rolling migration instead of design freeze

New screens go through DS always, existing ones migrate on first touch. Simple enough to hold even when feature work crowded out migration time. Every screen was migrated within 9 months, alongside active delivery.

Screen migration by the first-touch rule: new screens start on the DS in month 1, legacy screens migrate on first touch by month 5, every screen is on the DS by month 9

04

DECISION

Chromatic in the PR flow

Visual bugs used to surface at QA — 3–4 per sprint. Chromatic added visual diffs on every PR with async designer approval. Style breakage became impossible to miss before merge. Result: 82% shipped without rework, sprint fixes down to 0–1.

One component through its lifecycle: designed in Figma, documented in Storybook, reviewed as a visual diff in Chromatic, shipped to production

05

DECISION

Full state matrix as the definition of “done”

Components existed in default state only — hover, disabled, error were improvised by developers. Making the full matrix a hard requirement removed the guesswork at implementation. AI prompts helped catch edge cases.

State matrix for an outline button with an icon: default, hover, pressed and disabled observed in the product, the focus state caught by AI

06

DECISION

AI as part of the workflow, not a one-off tool

One designer, team-level documentation coverage. AI handled the routine — usage rules, state matrix gaps, Storybook story scaffolding, token naming audits. Decisions stayed with me; AI removed the bottleneck between thinking and writing.

Who did what: AI handled the routine — drafting usage rules, spotting state-matrix gaps, scaffolding Storybook stories, auditing token names — while token architecture, naming, composite logic and the quality bar stayed with me

05 — ARTIFACTS

Created artifacts

01

Figma Library

100–150 components (primitive + composite), Variables/Tokens, full state sets

02

Figma Documentation

Usage rules, dos/don’ts, annotated states, composite templates

03

AI Workflow Guide

Reusable prompts for documentation, state-matrix gaps, Storybook stories, token-naming audits

04

Token Architecture

Primitive + semantic layers, Figma → CSS mapping

05

Handoff Specs

Spacing, typography, states, edge cases — embedded in Figma

06

Storybook

Props, variants, composite components with nesting docs

07

Chromatic

Visual snapshots per PR, designer approval in the flow

06 — WHAT ALSO CHANGED

In the product, in the team.

IN THE PRODUCT

Design and development share one source of truth for the first time. Every screen moved onto the DS within 9 months of parallel feature delivery. Migration ran through normal product work — no separate “DS rollout sprint” was ever needed.

IN THE TEAM

Developers stopped pinging the designer with component-level questions — Figma documentation answers most of them. Handoff conversations moved from “what does this do” to “should it do this differently here.” The work moved up a layer.

07 — REFLECTION

What I’d do differently.

01

Run the naming session before the first component

Not as a reaction to a mismatch caught in week two of Figma work. The convention belongs in the foundation, not in the rework.

02

Track adoption from day one

Reconstructing the picture retrospectively made it harder to show progress to stakeholders. Numbers earn trust faster than narrative.

03

Set governance rules before anyone asks to add a new component

Easier to establish proactively than under backlog pressure. “Who can add” and “how it gets reviewed” should be answered before contributions arrive.

08 — WHAT’S NEXT

Where the system goes from here.

#01

Token sync

Automate Figma Variables → CSS via Style Dictionary or Tokens Studio.

#02

Theming

Dark mode and per-client themes — the semantic layer is already structured for it.

#03

AI screen assembly

Consistent patterns, clear semantics, full state matrices — the DS is structured to support AI-assisted screen composition.

#04

Governance

Contribution model, review gates, section ownership — needed as the team grows.

NEXT CASE

CASE 02 / 05

DesignOps case — a senior designer’s week before and after the quality system

03

DesignOps in a Small Team — Scaling Quality Without Adding Senior Workload

A four-element quality system for a team of four — 2–3× fewer iterations after handoff, a third of senior time freed.

B2B SaaS · 2025–2026