Five Below Design System: one token named once, consumed by a component library, inherited by every page — a blue bg-brand-solid coin on the left, the Library panel in the middle, the fivebelow.com product page on the right, all wearing the same blue

Five Below Design System

Rebuilding the design foundation of a growing retailer — so one decision ships everywhere, automatically.

Overview

As Five Below's digital footprint expanded, design and engineering ran on separate sources of truth. We rebuilt the system on shared tokens and closed the loop through GitHub — turning the design system into an automated engine.

Role

Design Manager

Team

Lead Designer · Sr. Designer · Production Designer · DS Engineer

Tools & Timeline

Figma · GitHub · Tailwind — 4 months

01 — Context

Two sources of truth, zero shared language

Designers shipped high-fidelity Figma files; engineers re-typed every hex code, spacing value, and radius by hand. The audit told the story: 214 screens, 41 components — and six different opinions of the same button in production.

The symptom

Constant visual regressions, QA time sunk into logging padding bugs, and a brand that drifted a little further on every release.

The cost

Every new feature paid a redundant design-and-rebuild tax — inflating timelines beyond what the business could sustain.

02 — The challenge

How might we make one design decision propagate to every page — without a single handoff meeting?

03 — The solution

A token pipeline that erased the handoff

Every design decision became a semantic token that exists identically in Figma and in Tailwind. What a designer applies in the tool is exactly what an engineer ships in the browser.

One shared component library

BeforeBefore: a production audit of six Add to Cart buttons from six teams — four blues, three corner radii, two typefaces, all live at once
Six teams, six versions of “Add to Cart” — four blues, three radii, two typefaces, all live at once.
AfterAfter: one Button in the shared library, three variants by three states, bound to the tokens bg-brand-solid, radius-full and space-lg — one blue, one radius, one typeface
A single library with governed variants. Any component consuming the right token is guaranteed to render correctly.

Design decisions travel like code

The token pipeline, left to right: in Figma Variables the bg-brand-solid token is re-aliased from blue-700 to blue-500 and published; a GitHub pull request opens with the diff in tokens/color.json and the regenerated tailwind.config.js, checks pass and it merges; the fivebelow.com page updates. Five steps, about four minutes round-trip.
A designer updates a token → versioned JSON exports → a pull request opens → the Tailwind config regenerates → every page updates. Round-trip: about four minutes.
04 — Impact

Feature spin-up went from weeks to days — and visual QA bugs nearly disappeared.

Dev cycle: weeks → daysVisual regressions: ≈ 0Token round-trip: ~4 minOne source of truth
Shipping one feature, before and after. Before: Design, Handoff, Rebuild UI by hand, Visual QA loop, Ship — weeks, with the design-and-rebuild tax paid on every feature. After: Design, Build, Ship — days, with no handoff, no rebuild and visual regressions near zero; capacity returned to complex UX flows, user testing and feature innovation
Capacity once absorbed by UI debt was redirected to complex UX flows, user testing, and feature innovation.
05 — Process notes

What made it stick

  1. Audit before opinion

    We inventoried 214 screens and 41 components first, so every consolidation argument was a screenshot, not a taste debate.

  2. Semantic tokens, not raw values

    Naming decisions (color.brand.500, space.4) made them portable across Figma, Tailwind, and documentation — and future-proofed rebrands.

  3. Governance through pull requests

    Token changes ship as reviewable PRs. Design gained a change-log; engineering gained predictability; QA gained a day back.