From a developer-run product to a system the whole team builds on.

We inventoried every button, input and colour before designing anything new.

Before designing anything new, we inventoried what already existed: screenshotting every instance of each UI element across the product and grouping them.

The audit did two jobs: it showed engineering and leadership the scale of the problem, and it told us which components to build first, the ones used most and broken most.

We aligned on a few principles to settle debates quickly.

Four layers, each built only from the one below it.

Before drawing a single component we agreed on the shape of the system. Foundations hold every raw decision; components are built only from tokens; patterns are built only from components; product pages are built from patterns. If a screen needs a hex value or a one-off margin, something is missing from a lower layer, and that gap becomes a request instead of a workaround.

Seven type tiers, including a high-density tier for data, and five colour groups.

Tokens are the named decisions (colour, type, spacing, radius, elevation) that designers and engineers share. Defining them first meant every component inherited the same choices.

A dedicated high-density 11px tier exists because revenue managers read calendars and tables with hundreds of cells; icon sizes (Font Awesome) are matched to each type tier: 18 / 14 / 12 / 11.

Three tiers of tokens

Early tokens were just named colours, so changing “the red” meant hunting through every component that used it. We split tokens into three tiers. Primitives hold the palette and scales. Semantic tokens say what a value is for (color-action-primary, color-border-default). Component tokens are the only thing a component reads.

That middle tier is what makes theming possible: the dark-mode work on buttons and split buttons only remaps semantic tokens, and no component code changes.

38 documented components and patterns, each with anatomy and usage rules.

We started with the basics that appear on almost every screen, and designed each with a clear anatomy, variants, sizes and states. The library grew to 38 documented components and patterns, each signed off in Figma before it was built:

documented and shipped   in progress

The library, page by pageOpening frame of each page in the Figma file · 38 documented ✅ · 4 in progress · plus foundations

Every component got an Introduction page (what it is, its anatomy) and a Usage guidelines page (when and how to use it) in Storybook.

Every component page answers the same five questions, so engineers know where to look.

Each of the 38 component pages in Figma follows one template, headed PriceLabs DSL / Documentation and linked to the matching Storybook page. Here is the Expansion Panel, exactly as documented:

1. IntroductionWhat it is and its anatomy, with every part named
2. VariationsEvery property combination, labelled with its prop values
3. Usage guidelinesWhen to use it, limits, and content rules
4. PlatformsWidths and rules for desktop and mobile
5. AccessibilityKeyboard, screen-reader and contrast requirements

The fifth part, Accessibility, was the thinnest in Figma (a heading and a one-line brief). That gap is what the spec below fills.

A designer reads anatomy; an engineer needs a contract. For each component we paired the Figma page with a spec that maps one-to-one to the React component. The Expansion Panel spec:

Specs were written for this case study from the Figma documentation; prop names illustrate the contract rather than the exact production API.

Tokens were the bridge. A decision made once in Figma variables flowed into code under the same name, so “change the brand red” was a one-line change.

The mobile app added a pl-m-* layer on top (48px controls, 32px chips), so the same names served both platforms.

Components alone don’t make a product consistent; how they combine does. We documented interaction patterns and a product voice alongside them.

Guidelines covered behaviour, not just parts.

Product patterns were documented the same way as components. The right panel shows how far the guidelines went: not just the parts, but the behaviour.

• Contextual, secondary work only: details or settings for a selected item, with the main page still visible under a 50% overlay
• Deliberate closing: Esc and outside clicks don’t close it, so a half-edited form can’t be lost by accident; a discard action makes the exit explicit
• Responsive by rule: on small screens it becomes a bottom sheet, the same decision that later shaped the mobile app

Test the token pair once, and the result holds everywhere it’s used.

Screen-by-screen accessibility reviews never finish in a product this size. Instead we checked contrast on token pairs against WCAG 2.2 AA, so a pass or a fail applies to every place that pair appears. Ratios below are calculated from the production hex values.

• The brand colour was the biggest catch. White text on coral #F37579 is 2.75:1, below even the 3:1 minimum for large text. Coral stays a fill and an accent; text and links that need to read as “brand” use red-900 (5.4:1).
• Status colours never work alone. Green #31C48D is 2.2:1 on white, so success, warning and error always pair colour with an icon and a label, including the demand colours in the pricing calendar.
• Secondary grey is for supporting text only. #7A7A7A is 4.3:1: fine for timestamps and helper text at 14px+, not for anything a user must read to act.
• Every component page carries the same checklist: visible 2px focus ring, 32px minimum targets on web and 48px on mobile, keyboard map, and ARIA roles that match the Figma property names.

We got a dedicated engineer for the migration. Design and engineering worked side by side: each component was designed, built in React, reviewed for parity and then rolled into pages.

1. Page by page, not big-bang. The highest-traffic pages (pricing calendar, dashboard, customizations) went first.
2. Component before page. Each component was built in React and checked in Storybook before any page used it.
3. Parity review. Old and new screens were compared side by side with a checklist (spacing, states, keyboard, copy) before release.
4. Swap and delete. Once a page shipped, its old CSS was removed so the two systems never lived side by side for long.

An audit of real code usage kept the system honest after launch.

After the migration we kept growing the library, and the same foundations later carried the mobile app: mobile variants on existing components instead of a separate library.

The system lives in two places that mirror each other: the Figma library for design, and Storybook (PriceLabs DSL) as the documented source of truth for engineering, with introduction and usage pages for each component.

A status page before anyone builds a duplicate

The most common way a system fails is quietly: a squad can’t tell whether a component exists or is ready, so it builds its own. We added a status page that tracks every component across Figma, React, Storybook, documentation, accessibility review and mobile, updated with each release.

Driving adoption, and measuring it

Auditing the system in code

A system drifts once it’s in engineers’ hands. In August 2025 we audited how buttons were actually used across the React codebase, screenshotting each case and tracing it to its file, then resolving every one against the guidelines.

Reviews happened in Figma comments with our design manager, and the same process now extends to dark-mode variants for buttons and split buttons. Design owns the Figma library and the documentation; engineering owns Storybook and the React package. Anyone can propose a component, and every change goes through the same path:

1. RequestA template: the problem, where it appears, and why existing components don’t fit
2. ReviewWeekly design-system sync: reuse, extend or create
3. DesignAnatomy, variants, states, platforms and accessibility in Figma
4. BuildReact component and Storybook story, with props matching Figma
5. ReleaseVersioned, with a changelog note to every squad

• Faster buildsNew pages are assembled from components, so design QA focuses on flows instead of pixels.
• A shared languagePMs, designers and engineers name the same things the same way, from Figma to Storybook to the codebase.
• Ready for the next platformThe mobile app reused the same tokens and component logic instead of starting over.