The Design System Compendium

Start here

How to use this compendium

Five field guides I give product teams separately. Combined here as a bonus: the full path from UI chaos to a system that scales, governs, and ships.

Who this is for: design, engineering, and product leaders at companies with roughly 20 to 200 people, multiple UI surfaces, and no dedicated design systems team (or one person doing three jobs).

What you get:

• Part I: a 40-point diagnostic across tokens, components, parity, docs, governance, and accessibility
• Part II: readiness, build order, adoption, and governance without police
• Part III: pilot scorecard, five pilot types, and proof on funded work
• Part IV: a 100-day execution timeline with week-by-week plans
• Part V: design-dev collaboration rituals and the ROI of the seam

I led Aurora at Nord/NordVPN (dozens of teams, millions of users) and have spent 16+ years where Figma meets the repo. These guides are the honest sequence I run in paid audits and foundations sprints.

Contents

Five playbooks, one journey

Work through the parts in order for a full engagement arc: diagnose, orient, prove, execute, collaborate. Or jump to the part that matches where you are stuck today.

Suggested path: Part I if you need a baseline score. Part II if leadership asks "what is a design system?" Part III if you have funded work but no DS budget. Part IV when you are ready to run the quarter. Part V when design and engineering keep missing each other.

00 · How to use this

Tick what's true. The gaps are your roadmap.

This is the same diagnostic I use in paid engagements to find where a product's UI is drifting, and what it's costing. It works whether you have a mature system or none at all.

Go lens by lens. For each item, rate it honestly using the traffic-light scale below. Don't agonize, your gut read is usually right. When you're done, count your reds and yellows: that's your prioritized backlog.

Inconsistency is a tax you pay in rework, slow velocity, and slow onboarding, every sprint.

The foundation. Without layered tokens, theming and consistency fall apart.

• A primitive layer exists (raw palette, scale) with no semantic meaning.
• A semantic layer exists (e.g. color-action, surface) that components consume.
• Tokens live in a single source of truth, exported to both Figma and code.
• Spacing, radius, typography, and elevation are tokenized, not just color.
• Theming (dark mode / brand) works by re-pointing semantics, not editing components.
• There are no (or very few) hardcoded magic values in the codebase.

One governed set beats ten drifting copies.

• Core components have a single canonical version (one button, not seven).
• Variants and states (hover, focus, disabled, loading, error) are complete.
• Naming is consistent and predictable across Figma and code.
• Composition patterns are defined (how components combine into patterns).
• Deprecated components are marked and have a migration path.
• Coverage matches real product needs (no big gaps forcing one-offs).

If Figma and production disagree, the system isn't real.

• Production UI matches the Figma library (no significant drift).
• Components are connected (e.g. Code Connect / Storybook ↔ Figma).
• Engineers reuse system components instead of rebuilding patterns.
• There's a defined handoff process design and eng both trust.
• Changes propagate predictably from source to product.
• "Done" means the same thing to design and engineering.

If it's not documented, it doesn't scale.

• Usage guidance exists for each core component (when/how to use).
• A new engineer can build a screen without asking around.
• Docs are current and trusted (not stale or ignored).
• Do's/don'ts and accessibility notes are included.
• Docs are discoverable (one known home, not scattered in Slack).
• Examples/code snippets are copy-paste ready.

The #1 reason systems die. Boring, and decisive.

• There's a clear owner (or team) for the design system.
• A contribution model defines how new patterns get proposed/added.
• Changes are versioned with a changelog.
• There's a review/QA gate before patterns enter the system.
• Adoption is tracked (who's using it, where the old patterns persist).
• Decisions are recorded so the "why" survives team changes.

Bake it into the system, not bolt it on later.

• Color contrast meets WCAG AA across themes.
• Focus states are visible and consistent on all interactive elements.
• Components use correct semantics / ARIA where needed.
• Keyboard navigation works across core components.
• Motion respects reduced-motion preferences.
• Components are tested (visual/interaction) to prevent regressions.

Where automation and clear workflow let one senior cover more ground.

• Repetitive work (migrations, doc generation, swaps) is automated where possible.
• The team has a fast feedback loop between design changes and shipped UI.
• Tooling scales the system without scaling headcount.
• There's a plan for keeping the system healthy as the team grows.

Score tally worksheet

Count your greens, yellows, and reds.

Fill this in as you work through the checklist. The lens with the most reds is usually where to start.

07 · Reading your score

Count the reds. That's your starting line.

Tally Green / Yellow / Red across all 40 checks, then find yourself below. The point isn't a grade, it's knowing what to fix first.

01 · Start here

Who this is for

You don't need another Pinterest board of component screenshots. You need a path that survives contact with engineering, product pressure, and the next reorg.

This playbook is for product teams (roughly 20, 200 people) who:

• Ship multiple surfaces (web app, marketing, maybe mobile) and the UI is drifting
• Have a Figma library, a Storybook, or both, but squads still rebuild from scratch
• Feel the "inconsistency tax" every sprint: rework, slow onboarding, endless design review
• Need to make the case to leadership without saying "consistency" twelve times

I've led design systems at enterprise scale (Aurora used by dozens of teams and millions of users) and spent 16+ years in the seam between Figma and the repo. This guide is what I wish every team had before they spent six months on a library nobody adopted.

Read straight through once. Then use the worksheets with your design, engineering, and product leads.

02 · The inconsistency tax

You're already paying for a system you don't have

Every squad that reinvents buttons, form layouts, and spacing is paying a tax. It shows up as hours, not line items.

The tax compounds in four places:

• Design time: Recreating patterns that exist somewhere else in the org (or in last quarter's file)
• Engineering time: Rebuilding UI that doesn't match spec, or spec that doesn't match what's shippable
• Review time: Debating micro-decisions (padding, label placement) that should be settled once
• User time: Inconsistent flows, accessibility gaps, support tickets from "it works differently on this page"

Fixing problems gets exponentially more expensive the later you catch them. A spacing mistake caught in design costs an hour. In code, a day. After release, a sprint (or a rollback).

Most teams don't need permission to feel the pain. They need a shared picture of what it's costing and a sequence that doesn't require stopping the roadmap for a year.

03 · Three things teams confuse

Style guide, library, system: not the same thing

Teams argue for months about "building a design system" when they mean three different things. Name it clearly.

A library without governance becomes shelfware: impressive in a demo, bypassed in production. A system without code connection becomes a PDF engineers ignore.

Practical test: Can a new engineer build a compliant screen on day one without Slack archaeology? If not, you have pieces of a system, not a system.

04 · The readiness gate

When formalizing helps (and when it hurts)

Starting too early creates process drag. Starting too late cements debt. Five green lights, three red flags.

Green lights (consider formalizing):

1. 5+ designers and engineers touch the same product surfaces
2. Patterns repeat across squads (forms, tables, settings, onboarding)
3. Leadership will fund maintenance, not just a one-time "library project"
4. Engineering wants in (or you've found an eng champion)
5. The product is stabilizing (core flows exist; you're iterating, not pivoting weekly)

Red flags (stay lightweight for now):

1. Pre-product / everything still moving weekly
2. No eng bandwidth for tokens, Storybook, or CI (Figma-only systems rarely survive handoff)
3. Leadership wants a "pretty UI kit" with no adoption plan

If you're in the red zone: organize tokens and top 10 components informally. Document decisions in comments. Revisit the gate in one quarter.

05 · The six-layer stack

What a real system contains

Think stack, not shopping list. Upper layers depend on lower ones. Skip a layer and the stack wobbles.

Squads usually ask for Layer 3. The expensive bugs live in Layers 4, 6. Patterns (configuration flows, data tables, settings wizards) are where teams bleed time, not another button variant.

06 · Pain map worksheet

Score where it hurts

Interview design, engineering, and product. Rate each area 1 (fine) to 5 (major pain). Highest totals = your starting point.

07 · Dual inventory method

See the product from two angles

Screenshots show what users see. The repo shows what ships. You need both.

Visual pass (half a day):

• Screenshot every unique button, form field, heading style, and nav pattern
• Line them up. Count variants. Note accessibility issues (contrast, missing labels, focus)
• Tag location: which flows use which variant

Technical pass (with an eng partner, half a day):

• Map components in code / Storybook vs what's in Figma
• Find hardcoded values (#hex, arbitrary px) bypassing tokens
• List duplication: how many button implementations exist?

Prioritize by: frequency in product × fix effort × user impact. Not everything gets fixed in sprint one.

08 · 30-day starter sprint

A month that creates momentum

Pair system work with active product delivery. Visible wins beat big-bang launches.

09 · Build order that sticks

Sequence matters

Teams that jump to 40 components before tokens almost always drift within two quarters. This order holds.

1. Token pipeline. Design tool → JSON/YAML → transform (e.g. Style Dictionary) → CI → CSS/platform outputs. Manual sync is where handoff dies.
2. Spacing as relationships. Semantic names (space-section, space-inline), not isolated pixel picks per component.
3. Color in three layers. Base palette → semantic meaning (success, danger) → contextual usage (surface-raised). Never attach hex directly to components.
4. Top 10 components. Buttons, inputs, selects, checkbox, radio, card, modal shell, toast, tabs, breadcrumb. Complete states + a11y.
5. Patterns. Form layouts, empty states, settings flows, data table shell. This is what squads request once components exist.
6. CI checks. Lint for hardcoded values. A11y checks on Storybook. Drift becomes visible before it spreads.

For EU products: plan logical CSS (margin-inline), RTL tokens, and typography that tolerates German copy expansion (~30%) from day one.

10 · Winning the room

Speak their language, not design jargon

"Consistency" doesn't open wallets. Hours saved, tickets avoided, and faster shipping do.

15-minute ROI exercise:

1. Pick one feature on next quarter's roadmap
2. Estimate design + engineering hours from scratch
3. Re-estimate with reusable components, clear specs, token-driven styles
4. Multiply the delta by blended hourly cost

Direction beats precision. You're proving the shape of the benefit, not winning a finance audit.

Pair system work with an active OKR when possible: "We improved checkout and shipped a reusable form pattern."

11 · Adoption beats assets

A library nobody uses is a failed project

I've seen teams spend a year on components only to hear "the design system failed" because only designers knew it existed.

Adoption playbook:

• Name it. Give the system an identity teams can reference in standups.
• Champions per squad. One design + one eng advocate who answers questions and feeds back gaps.
• Onboarding hook. New hires build a real screen from the system in week one.
• Ship in public. Changelog, release notes, #design-system channel. Visibility builds trust.
• Measure usage. Repo imports and Storybook views, not Figma library opens.

Consumption and contribution are different strategies. Design for the 95% who consume. Make using the system faster than bypassing it.

12 · Governance without police

Enable speed, don't block it

When governance is unclear, squads duplicate components and use one-off hex values. That's not rebellion. It's rational.

Hybrid model (works for most scale-ups):

• Core team owns: foundational tokens, base components, release process, deprecation policy
• Product squads own: domain modules built on core (billing UI, admin tables)
• Exceptions: documented with rationale, not silent bypass

Publish a one-page ownership map: who to ask, how to contribute, expected review time. Transparency beats more process.

Deprecation done right: announce → provide migration path → maintain for 1, 2 release cycles → remove. Old patterns clutter libraries and confuse AI tools.

13 · Measure outcomes

Vanity metrics won't save your budget

"We have 400 components" is not a win. Tie the system to product outcomes leadership already cares about.

Metrics that survive budget reviews:

• Onboarding or task-completion time on flows you standardized
• Support tickets tagged UI, accessibility, or localization
• Design review cycle length (days from ready to merged)
• WCAG compliance % across system components (strong signal for EU teams)
• Package adoption: % of UI built from system imports vs custom code

Align system goals to active product OKRs each quarter. Example: "Standardize billing forms → 25% fewer billing support tickets → WCAG 2.2 AA on all form components."

Establish baselines before you claim impact. A one-question pulse in Slack after each release beats an annual survey nobody fills out.

14 · Five ways systems die

Learn from the cliff, not the brochure

Most failures are predictable. Spot your team in this list early.

15 · AI guardrails

AI scales output. Your system scales correctness.

One prompt can generate a dozen plausible screens that all disagree with each other. Without guardrails, AI adds entropy.

Make your system machine-readable:

• Semantic token names (color.action.primary, not blue-500)
• Documented component states and interaction rules
• Do's/don'ts with rationale (not just screenshots)
• Encoded accessibility requirements per component

AI accelerates production. It doesn't replace intent. Designers who strengthen systems thinking, ethical constraints, and cross-functional collaboration become more valuable, not less.

I placed 1st at the Into Design Systems AI Hackathon 2026 with a Figma plugin that smart-swaps mismatched components. The system was the constraint that made AI reliable.

16 · 90-day roadmap worksheet

Plan the quarter

Fill this in with your leads after the pain map and dual inventory. One theme per month.

Need a day-by-day version? See my 100-Day Playbook. Need a health score? See the 40-Point Audit.

01 · Start here

Proof before the pitch deck

You do not need permission to start. You need a funded flow, three weeks, and something shipped that a product lead will defend in a steering meeting.

This playbook is for design and engineering leaders at product companies (roughly 20, 200 people) who:

• Keep losing the budget conversation to "we'll hire a design systems team later"
• Have a Figma library or Storybook that nobody imports into production
• Are sitting on a rebrand, replatform, or merger that leadership already funded

If you need readiness gates, build order, adoption rituals, and governance models, read my Survive Handoff playbook first. That guide answers what to build and in what order.

This guide answers a different question: how do you prove the system on real product work before anyone funds a dedicated team?

I led Aurora at Nord/NordVPN (dozens of teams, millions of users). Every time we scaled, proof on a live product beat a prettier roadmap.

02 · The Make System Use System trap

"Build it and they will come" is a fantasy

The default corporate playbook fails in the same order every time. You have probably seen it.

1. Pitch leadership with ROI slides and competitor screenshots
2. Win budget for an abstract "foundation" nobody ships against
3. Launch a comprehensive library in a big reveal
4. Mandate adoption while squads are underwater on feature work
5. Ask those same squads to contribute back while understaffed
6. Watch usage flatline within two quarters

Call it the Make System Use System fantasy: if we just make a really good system, people will use it. Duh!

It ignores three realities:

• Least effort wins. Under deadline pressure, teams reach for what they already know. Your library is unfamiliar until it ships something they needed yesterday.
• Abstract bloat. Palettes and primitives built for hypothetical futures do not survive contact with one real checkout flow.
• Zero slack. Adoption and contribution are two behavior changes. Most squads cannot absorb both at once.

03 · Hitch to moving work

Board the train that's already leaving

A pilot without product pressure is a side project. Side projects do not survive the next reorg.

Look for inflection-point work that already has budget, a sponsor, and a deadline:

• Rebrand or visual refresh landing in Q3
• Replatform or migration (monolith to micro-frontends, legacy stack swap)
• M&A integration forcing two UIs to look like one company
• New market launch with a greenfield surface
• Compliance push (accessibility, localization) with executive air cover

Your ask to the product lead is not "help me build a design system." It is: "Let us standardize this flow so your team ships faster and your launch date holds."

Reframe the conversation around schedule risk, not consistency theater. Velocity-measured teams fund what protects their roadmap.

DACH replatform waves are ideal Raiders hosts: funded engineering motion, visible UI drift, and leadership already paying for the refactor.

04 · Pilot Scorecard worksheet

Turn politics into a ranked backlog

Eight factors, scored 0, 10 each. Highest total goes first. Run this live with PM and engineering in the room.

Disagreement on scores is data. A 3 on receptiveness tells you to pick a different host or change the pilot type.

I ship a blank scorecard in every audit readout. It is the bridge from diagnostic to funded pilot.

05 · Five pilot types

Match the pilot to the political terrain

Not every host squad wants a design system embedded in their sprint. Pick the type that fits the work and the room.

06 · The Measuring Spoon Cycle

Make product, then extract, then reuse forever

The system is not the textbook. It is the margin notes from real builds.

Think of a well-worn measuring spoon in a kitchen: forged from daily use, shaped by what you actually cook. Your design system should grow the same way.

1. Make product. Ship the pilot flow on the host team's deadline. Use whatever components exist. Note every snowflake.
2. Extract. Pull reusable pieces into the system package. Document what you learned in production, not in a vacuum.
3. Reuse. Import those pieces into the next pilot. Measure whether the second host ships faster.
4. Repeat. Each cycle hardens the canon. The library stops being theoretical.

Apply the three-times rule before you systematize a snowflake: if three squads need the same pattern, promote it. If one team needed it once, leave it local.

07 · Connected npm vs copy-paste

Bootstrap is a download. Your system should be a package.

How product teams consume your system predicts whether pilots stick or drift within a quarter.

Audit question I ask on every diagnostic: "How do squads consume your system today?" Copy-paste is a red flag. Connected consumption is a green flag.

Pilots fail quietly when extraction stops at Figma. The proof point leadership remembers is merged code in a product repo, importing a package version they can point to in a release note.

• Publish from day one, even if the package only exports three components
• Semantic versioning from v0.1.0: signal that change is managed
• Pair Figma Code Connect or Storybook with the same version tag

At Nord scale, connected distribution was the difference between a library people admired and a library people shipped.

08 · Three concurrent pilots

One pilot's components rarely fit the second channel

Multichannel orgs that run pilots sequentially often wait 18 months to learn the web components do not fit mobile or marketing.

If you ship across web app, marketing site, and mobile (or admin + customer-facing), plan three concurrent pilots with a small dedicated system team (even 2, 3 people):

• Pilot A: Core product flow (often Raiders on a replatform)
• Pilot B: Marketing or docs surface (often Perimeter or Facelift)
• Pilot C: Secondary product or internal tool (Surrogate if partnership is weak)

Run the same Pilot Scorecard for each channel. Expect different winners. That is the point.

Sequential single pilots are fine for single-surface startups. For 20, 200 person product companies with multiple UIs, parallel pilots are cheaper than a false start.

Minimum viable design system after pilot one: three components teams can import Monday morning. Not a catalog. A wedge.

09 · Hot Potato beats handoff

Pass work in hours, not weeks

Pilots die in the gap between "design approved" and "engineering started." Hot Potato closes that gap.

The workflow is simple: designer and engineer work in the same session (virtual counts). The engineer drives implementation early. Work passes back and forth like a hot potato, same day.

1. Designer explores inside code-friendly constraints (real tokens, real breakpoints)
2. Engineer stubs the component in the product repo while pixels are still cheap to move
3. Designer refines in Figma or directly in Storybook against the stub
4. Engineer surfaces system gaps (missing variant, unclear token) before the PR is "done"
5. Ship to the host squad's branch before the standup ends

This is the studio wedge in one ritual: design intent survives handoff because handoff barely exists.

Still running waterfall comps? Pair this with my Design × Development Collaboration guide.

10 · Flow week / Systems week

You cannot ship product and harden the system at full throttle simultaneously

Alternate weeks. Product delivery, then extraction. WordPress teams figured this out years ago; it still works.

Without protected Systems weeks, extraction gets sacrificed every sprint. The library stays a side project.

• Put "Systems week" in the retainer contract or team charter: billable, protected, reported
• End each Systems week with a short extraction report: what landed in the package, what version shipped
• Alternate even when it feels slow. Flow without Systems creates debt. Systems without Flow creates shelfware.

11 · The store, not the catalog

Sell the Millennium Falcon kit, not loose bricks

Nobody walks into a Lego store asking for a 2×4 brick in #C91A09. They walk in for a kit they can build this weekend.

Most reference sites are parts warehouses: 47 button variants, alphabetized. Pilots need a store: assembled products teams can ship from.

Structure your docs around what squads actually build:

• Recipes: "Billing settings page" with components nested inside
• Templates: Starter frames for onboarding, empty states, error flows
• Flows: End-to-end patterns with copy, states, and accessibility notes

Components live inside those products, not at the top level. A PM browsing your site should recognize their roadmap, not a design textbook.

12 · Pilot planning worksheet

Plan the first 3, 4 weeks

Fill this before you embed. One row per week. Share it with the host PM so scope stays honest.

Need a day-by-day build plan after the pilot proves out? See my 100-Day Playbook.

13 · Prove it, then pitch

Bring shipped code to the steering committee

The second funding conversation should open with a merged PR, not a Figma link.

What leadership needs to see after pilot one:

• A production flow importing your package at a pinned version
• One metric moved (even 15% faster build time on the host flow counts)
• A ranked Pilot Scorecard showing where pilot two and three will land
• A Flow/Systems week rhythm the host squad will defend

What to ask for next:

1. Two more concurrent pilots (if multichannel)
2. A named system owner (even 0.5 FTE to start)
3. Protected Systems weeks on the roadmap
4. Budget for connected tooling (CI, visual regression, docs hosting)

Run the 40-Point Audit before pilot two if you need an objective health baseline. Reds become the extraction backlog.

00 · How to use this guide

A playbook, not a wish list.

This is the sequencing I run in paid engagements, compressed into a plan your team can execute internally or with a senior partner.

Who it's for: product companies with ~20-200 people, a real web product (often app + marketing site), a small design team, and engineers rebuilding the same UI patterns. You have leadership buy-in, or you're the leader making the case.

Who it's not for: pre-revenue startups with no product yet, teams that want "cheap screens" instead of a system, or orgs where engineering won't touch a shared component library.

How to read it: Phase 1 is non-negotiable. Phase 2 is where most of the build happens. Phase 3 makes the system real in production. Phase 4 is adoption: without it, you built shelfware.

What's new in this edition: pilot scorecard and Measuring Spoon extraction (proof before scale), connected npm delivery (not copy-paste), patterns and six-area coverage, Hot Potato collaboration, canon vs expanded governance, docs as a store, and AI guardrails. Deeper context lives in the full compendium.

Time commitment: plan for 0.5-1 FTE dedicated to the system (design engineer, or design + eng pair), plus ~2-4 hours/week from a sponsor in leadership. Squads keep shipping features; the system earns its place by removing rework.

100 working days ≈ 20 calendar weeks at 5 days/week. Adjust pace if you're part-time on the system. Sequence stays the same.

01 · Why 100 days works

Long enough to adopt. Short enough to finish.

Most "design system projects" stall because they start in the wrong place, ship components nobody uses, or never assign an owner. One hundred days forces the right sequence.

I've led systems at enterprise scale (dozens of teams, millions of users on Aurora) and in fast-moving scale-ups. The pattern is consistent: tokens first, core components second, parity third, adoption last. Skip a step and you pay the inconsistency tax again within two quarters.

One hundred days is not arbitrary. It maps to what a focused team can actually deliver:

• Days 1-14: know where you stand and align stakeholders (audit + charter).
• Days 15-49: token architecture + 15-20 governed core components in Figma and code.
• Days 50-77: extended library, Storybook docs, Figma↔code connection, pilot surfaces migrated.
• Days 78-100: squad rollout, governance live, metrics, handover to an owner.

Skip the "build the whole system, then convince people" trap. Hitch to funded product work in Phase 1, extract components as you ship (Measuring Spoon Cycle), and prove value before you ask for a permanent team.

On one product, a single consistency fix cut reclamations ~90%. No full redesign. Same component, same behavior, everywhere. That's what a system is for: operations and revenue, not a Figma trophy case.

If you need less: stop after Phase 2 with a usable foundation. If you need more: extend Phase 3 into a full rollout. The phases still hold.

02 · Before day 1

Get these in place or wait.

The system won't survive politics. Sort sponsorship and access before you tokenize a single color.

1. Executive sponsor. One leader (Head of Design, VP Eng, or CPO) who will defend system time against feature pressure. They don't need to run it. They need to unblock it.

2. System owner (named). Even 20% of one person's role. "Everyone owns it" means no one owns it. The owner runs office hours, triages contributions, and keeps the roadmap visible.

3. Design + engineering pair. At least one designer and one engineer with authority to change the shared library and merge to main. A system in Figma alone is a draft.

4. Access. Figma org/libraries (edit), repo + Storybook (write), staging environment, analytics if you track UI errors.

5. Scope boundary. Pick 1-2 surfaces for the first pilot (e.g. settings area + onboarding). Not the whole product. Hitch to work that already has budget: rebrand, replatform, or a funded feature migration beats a sandbox library.

6. Pilot host scored. Run the Pilot Scorecard (page 5) on 3-5 candidate flows before you commit. Highest score wins. Politics becomes sequence.

7. Working agreement. Weekly 30-min sync. Review turnaround: 48h for async feedback. Slack/Teams channel named and archived. Decision log location chosen.

03 · Pilot-first proof

Prove on product work. Then scale.

The system is the notes in the margin, not the textbook. Extract from real shipping UI; don't invent components in a vacuum.

The Measuring Spoon Cycle: make product UI on a pilot → extract what repeats → reuse on the next product → repeat. Your 100-day plan is one long Measuring Spoon loop, not a big-bang library launch.

Hitch to moving work. Replatforms, rebrands, and merger integrations already have executive attention. Embed there. Don't build a parallel "design system project" that competes for the same engineers.

Five pilot types (pick what fits your politics):

• Raiders: refactor existing UI on a live surface (low UX change, high extraction value)
• Facelift: visual refresh with new tokens and components
• Speed Run: greenfield screen shipped fast on the system
• Surrogate: system team ships for a squad that won't partner yet
• Perimeter: edge surfaces (marketing, auth, settings) with lower political risk

Pilot Scorecard (score each candidate 0-10; sum and sort):

Full pilot playbook: Pilot-First guide

04 · The four-phase map

Align → Foundations → Connect → Adopt

Each phase has a single outcome. Don't start the next until the current one is demonstrably done.

Detailed week plans start on page 6. Token and component references on pages 8-9.

You cannot fix what you haven't measured. Phase 1 is audit, inventory, and alignment. No component building yet.

Five weeks of build. Work in vertical slices: one component fully done (Figma + code + Storybook) before starting the next. No "Figma complete, code later."

Week 3 (days 15-19): Token architecture. Primitive palette, semantic aliases, spacing/radius/type scales. Figma variables published. Export pipeline to CSS/Tailwind stub.

Week 4 (days 20-24): Tier 1 components: Button, Link, Icon, Text styles. All states in Figma + React. Storybook stories live.

Week 5 (days 25-31): Form controls: Input, Textarea, Select, Checkbox, Radio, Switch, Label, Field error. Keyboard + focus on every control.

Week 6 (days 32-38): Feedback + layout: Alert, Badge, Card, Divider, Stack/Grid primitives, Skeleton.

Week 7 (days 39-45): Overlays: Modal, Tooltip, Popover, Tabs. Focus trap on Modal. Reduced-motion respected.

Week 8 (days 46-49): Midpoint review with squads. Fix parity gaps. Deprecate obvious duplicates in pilot surface.

07 · Token architecture

Two layers. One source of truth.

Primitives hold raw values. Semantics hold intent. Components never reference primitives directly.

Naming convention: {category}-{role}-{variant?}. Examples: color-text-primary, color-border-subtle, font-size-body, elevation-overlay.

Export path: Figma variables → JSON (Tokens Studio or native) → Style Dictionary → CSS custom properties / Tailwind theme extension. One pipeline, two consumers.

Theming: light/dark switches re-point semantics only. color-surface maps to different primitives per theme. Components unchanged.

• Document every semantic token in a table: name, primitive ref, usage, contrast pair.
• Ban hex in component files. Lint for it in CI by day 50.
• Start with 8-12 semantic colors, not 40. Expand when a real product need appears.

08 · Component priority tiers

Build in this order. Always.

Tier 1 unlocks 80% of screens. Tier 2 covers forms and feedback. Tier 3 is product-specific. Don't build Tier 3 until Tier 1 is adopted.

• Tier 1Button, Link, Text, Icon, Card, Stack, Divider · ship these before anything else. Every squad uses them weekly.
• Tier 2Input, Textarea, Select, Checkbox, Radio, Switch, Label, Alert, Badge, Tooltip, Modal, Tabs · complete form and overlay patterns.
• Tier 3Table (sort/filter/pagination), DatePicker, Combobox, Navigation, Sidebar, Empty state, Skeleton · after pilot adoption. Often product-specific APIs.
• DeferCharts, rich text, maps, custom widgets · wrap third-party or keep local until governance matures.

States checklist (every interactive component): default · hover · focus-visible · active · disabled · loading (if async) · error (if input) · empty (if container)

Figma structure: one library file per tier during build; merge to single published library at day 45. Component properties mirror code props (variant, size, disabled).

Three Times Is a Pattern: don't add to the system until a third squad needs the same thing. Snowflakes stay in the expanded universe until the pattern proves out.

09 · Patterns & the six-area model

Components are the easy part. Patterns are where teams bleed time.

Mature systems cover six interlocking areas. Squads ask for buttons; the expensive bugs live in regions, content, and flows.

Patterns to prioritize in Phase 3 (after Tier 1 adoption): settings panel, data table with sort/filter, empty states, onboarding wizard. These are "products" in your docs, not loose buttons.

10 · Phase 2 week-by-week

Days 15-49 at a glance

Async rhythm: Mon/Tue build · Wed WIP Loom to channel · Thu review comments · Fri merge + changelog entry.

Phase 3 turns a library into a system: automated token sync, complete documentation, and a real product surface running on governed components only.

Token pipeline (days 50-56): CI job exports Figma variables on merge. Style Dictionary builds CSS + Tailwind + JSON. PR fails if token drift detected.

Documentation (days 57-63): Storybook docs per component plus 2-3 pattern recipes (settings, table, onboarding). Products first, components nested inside. Optional: docs site if you need search and onboarding paths.

Tier 3 components (days 64-70): Data table and navigation for your product. Build only what the pilot surface needs.

Pilot migration (days 71-77): One squad rebuilds the pilot surface (e.g. settings) using system components only. Track: lines of custom CSS removed, components imported, time to ship vs. baseline.

12 · Connected delivery

Infrastructure installs. Libraries get copied.

Bootstrap is a download. Your design system should be a versioned package product teams import. Copy-paste drifts on day one.

Connected means:

• Published as npm install @your-org/design-system (or internal registry equivalent)
• Semver releases with changelog and migration notes
• Deprecation warnings in code, not surprise Slack threads
• One token change ripples to Storybook and consuming apps on upgrade

Week 50-52 checklist:

• Monorepo package or dedicated repo with build pipeline
• Peer deps documented (React version, etc.)
• At least one product app importing the package (not copy-pasted files)
• CI: lint for hardcoded hex in consumer apps optional but powerful by day 77

Speaks both Figma and the repo: tokens in variables, components in a package, docs that show live imports.

13 · Phase 3 week-by-week

Days 50-77 at a glance

On one project, Lighthouse went 34 → 77 partly from system discipline: fewer one-off components, less CSS chaos. Performance is a design-system outcome whether your roadmap admits it or not.

Building is the easy part. Phase 4 is rollout, rituals, and making sure the system doesn't rot when the initiative ends.

Squad rollout (days 78-88): Squads 2 and 3 migrate one feature each. Name one design + one eng champion per squad. Office hours twice weekly for 30 min. Capture questions → doc updates same week.

Governance live (days 89-94): RFC template for new patterns. PR review checklist for design QA. Changelog published every release. Owner runs triage.

Enablement (days 95-97): 60-min handover session: how to contribute, how to request components, how to deprecate. Record it.

Close (days 98-100): Metrics review with sponsor. 90-day backlog for Tier 3 gaps. Decision: fractional partner, hire, or internal owner only.

15 · Governance starter kit

Boring on purpose. Decisive by design.

Most systems die from no owner and no process. This is the minimum viable governance. Copy it.

Roles

• System owner: roadmap, triage, release, office hours.
• Contributors: squads propose via RFC; owner approves.
• Sponsor: escalates priority conflicts; protects system time.

Canon vs expanded universe

• Canon: supported forever, versioned, documented (core tokens + Tier 1-2)
• Expanded universe: squad contributions, best-effort, may promote to canon after the 3× rule
• Promotion criteria: third squad needs it + a11y bar + test coverage + owner

Flow week / Systems week (alternate if embedded in product teams):

• Flow week: ship product UI on the pilot with the squad
• Systems week: extract, document, version, test. No feature pressure.

Without explicit alternation, system work loses every sprint planning fight. Calendar it with the eng manager.

RFC template (one page)

• Problem: what product need isn't met by existing components?
• Proposal: new component or extend variant? Figma mock + API sketch.
• Alternatives: why not compose existing components?
• Adoption: which squads will use it in 30 days?
• Decision: approve / defer / reject (owner signs)

Rituals

• Weekly 30-min office hours (open Zoom, standing invite).
• Biweekly release with changelog (even if "fixed Button focus ring").
• Monthly adoption review: % screens on system, top override offenders, doc gaps.

PR checklist (design QA)

• Uses system components, not one-offs?
• Tokens only, no hardcoded colors/spacing?
• Focus visible? Contrast OK? Keyboard path works?
• Storybook story updated if API changed?

16 · Hot Potato & collaboration rhythm

Pass work in hours, not weeks.

Design intent survives handoff when handoff barely exists. Hot Potato beats comp-to-Jira-to-sprint every time.

Hot Potato process: designer and engineer in the same session (virtual counts). Engineer drives implementation early. Design explores inside real constraints. Pass work back and forth the same day.

Run it in Phase 2: pick one Tier 1 component. One designer, one engineer, shipped by end of day. Record the session as the pattern for squads.

Five collaboration rituals to institutionalize by Phase 4:

• Weekly design-dev sync (30 min, standing): blockers, parity gaps, upcoming extractions
• Component office hours (2×/week): open Zoom, no agenda, questions become doc PRs
• Design QA on system PRs: designer reviews component API and states before merge
• Shared definition of done: Figma parity, a11y, Storybook, merged to main
• Changelog in public: #design-system channel, every release named

Deeper teamwork guide: Design × Development Collaboration

17 · Phase 4 week-by-week

Days 78-100 at a glance

18 · Success metrics worksheet

People succeed, not systems.

Measure whether squads ship faster and happier. Component counts and doc page views are vanity metrics unless teams feel relief.

Align one system metric to an active product OKR each quarter. Example: "Standardize billing forms → fewer support tickets → WCAG 2.2 AA on all form components."

19 · Ten ways systems fail

Seen them all. Plan around them.

If you recognize your team below, fix the process before you add another component.

20 · AI guardrails

AI scales output. Your system scales correctness.

One prompt can generate a dozen plausible screens that all disagree. Without guardrails, AI adds entropy. Machine-readable tokens are the moat.

Make your system AI-readable by day 77:

• Semantic token names (color.action.primary, not blue-500)
• Documented component states and interaction rules in Storybook
• Do's/don'ts with rationale, not screenshots alone
• Encoded accessibility requirements per component
• Deprecation status visible to humans and tools

AI accelerates production. It doesn't replace intent. Designers who strengthen systems thinking, ethical constraints, and cross-functional collaboration become more valuable, not less.

I placed 1st at the Into Design Systems AI Hackathon 2026 with a Figma plugin that smart-swaps mismatched components. The system was the constraint that made AI reliable.

21 · Master 100-day checklist

Tick at phase end. Gaps = your backlog.

00 · The cost of the seam

Handoff isn't a file format. It's a relationship.

Design and engineering sit on opposite sides of the same user problem. When they don't share a language, you pay twice: once in rework, again in morale.

Most teams describe the pain as technical. "Figma doesn't match production." "Engineers rebuild everything." "We need better specs." True, and incomplete. Underneath is a teamwork gap: two groups with different definitions of "done," different incentives, and no one whose job is to hold the center.

The symptoms look like UI problems. The cause is often collaboration:

• Designers ship files; engineers ship code; nobody owns the gap.
• Reviews happen late, in PR comments, when change is expensive.
• Slack becomes the design system: answers live in threads, not docs.
• Each squad optimizes locally; the product drifts globally.

This guide is for Heads of Design, engineering leaders, and design engineers building the bridge. Pair it with the 40-Point Audit to score where collaboration is breaking today.

01 · People before tooling

You can't Slack-thread your way to alignment.

New tools arrive every quarter. The teams that improve are the ones that fix how they work together first.

I've seen orgs buy design-system platforms, Figma plugins, and AI assistants while the same three engineers rebuild the same button. The tool wasn't the bottleneck. Trust was.

What actually moves the needle:

• Shared rituals (same room, same cadence, same definition of done).
• A bilingual person who speaks design intent and production constraints.
• Artifacts both sides trust: tokens, components, Storybook, not static PDFs.
• Psychological safety to say "this doesn't match the system" without blame.

At Nord, with Aurora used by dozens of teams and millions of users, the hard part was never drawing components. It was governance: keeping dozens of designers and engineers building the same thing. Small teams can wing consistency. At scale, consistency is an engineering problem with a design surface.

02 · What design engineers do for teams

Translator, builder, and honest broker.

A design engineer lives in the seam so your designers and feature engineers don't have to fight there.

For design teams, they make constraints visible early: what composes cleanly, what needs a new pattern, what will break accessibility. Design intent survives handoff because someone validates it in code, not in a comment thread two weeks later.

For engineering teams, they remove guesswork: governed components, typed props, Storybook examples. Less "is this pixel supposed to be 12 or 16?" More ship.

For leadership, they turn UI chaos into a plan: audit, roadmap, adoption metrics. One senior person with systems thinking and craft, not a ticket ping-pong between departments.

Hiring this role is hard because it contradicts how companies hire. Contracting or fractional design engineering is often how teams get moving while the req stays open.

03 · A shared language

Tokens and components are diplomacy.

When design and eng argue about hex codes, they're arguing about ownership. Semantic tokens end the fight.

A shared language has three layers:

• Tokens: color-action, not #3b5bdb. Intent both sides can reference in critique and code review.
• Components: one governed Button, not seven squad variants. Names match in Figma and React.
• "Done": a checklist both disciplines sign: parity, states, a11y, docs, merged to main.

When everyone uses the same words, meetings shrink. Designers don't defend pixels; they reference semantics. Engineers don't improvise; they import from the library. PMs can write specs that mean something to both sides.

Building the language is work. Maintaining it is teamwork. That's why governance and a named owner matter as much as the first token file.

04 · Five collaboration rituals

Boring rituals. Dramatic results.

These five rituals fix most design-dev friction I've seen in 16+ years. None require new software.

• 1. Weekly design-engineering sync (30 min)Standing invite: design lead, eng lead, design engineer/system owner. Agenda: drift report, incoming patterns, blockers. No status theater.
• 2. Pair review before handoffDesigner and engineer (or design engineer) walk the Figma file together for 20 min before "ready for dev." Catch composition issues when they're cheap.
• 3. Office hours (30 min, twice weekly)Open door for "which component?" questions. Answer once, update docs same day. Stop answering in DMs that die in history.
• 4. Design QA on system PRsAny PR touching shared components gets a design pass: tokens, states, focus, parity. Not pixel nitpicks on feature branches.
• 5. Monthly show-and-tellOne squad demos shipping with the system. Celebrate adoption, not library size. Social proof beats mandates.

Start with rituals 1 and 2 in week one. Add the rest as the library grows. Rituals fail when they're optional. Put them on calendars, assign a facilitator, measure attendance.

05 · Roles and healthy boundaries

Clear roles beat heroic individuals.

Collaboration breaks when everyone does everyone's job, or nobody does the glue work.

The design engineer is not "extra design" or "extra eng." They're the connective tissue. Underfund that role and both departments pay the tax forever.

06 · When design and eng disagree

Conflict patterns and how to resolve them.

Friction is normal. Unresolved friction becomes drift.

Escalate to design + eng leads only when RFC-level decisions stall. Escalation should be rare if rituals run weekly.

07 · Trust at scale

Relationships don't scale. Rituals and systems do.

When everyone knew everyone, hallway alignment worked. Past ~40 people, you need structure.

Trust at scale comes from predictability:

• Transparent roadmap: what's in the system this quarter, what's not, why.
• Changelog discipline: every release notes what changed for designers and engineers.
• Credit both ways: design celebrates eng shipping parity; eng celebrates design contributing RFCs.
• No surprise reorgs of the library without migration paths.

I led design systems where contributors spanned continents. What held it together wasn't charisma. It was office hours, written decisions, and a design engineer who showed up in both Figma and the repo every week.

08 · ROI: where money hides

Make the tax visible. Then kill it.

Leadership funds collaboration when you speak in rework avoided, not in "better Figma."

Four cost buckets (estimate monthly, conservative):

ROI math (simple): (monthly tax × months) vs. investment in audit + foundations + fractional partner. Most teams I audit underestimate rework by half because it's spread across squads.

Collaboration ROI is rarely a single headline number. It's compound: fewer arguments, faster reviews, fewer production bugs, calmer teams. Track leading indicators weekly; lagging revenue shows up later.

09 · Proof from the field

Three patterns that repeat.

Different companies, same teamwork lesson: alignment pays.

Pattern 1: Consistency fixes revenue. On one product, unifying inconsistent UI patterns cut reclamations ~90%. Same action, same component, same behavior. Users stopped making avoidable mistakes. Support dropped. Nobody had put that on the roadmap slide; it showed up anyway.

Pattern 2: Scale needs governance, not more designers. At enterprise scale, the fight is keeping 40+ contributors from forking the library. Weekly syncs, RFCs, and a design engineer in the repo beat another design hire who only works in Figma.

Pattern 3: Performance follows discipline. Lighthouse 34 → 77 on one project. Part of that was fewer one-off components and less CSS chaos. Performance is a design-system outcome when collaboration keeps production tidy.

None of these required a bigger agency retainer. They required someone in the seam, rituals that stuck, and leadership that protected system time.

10 · AI and the human factor

AI compresses production. Judgment stays human.

AI doesn't replace design-dev collaboration. It deletes the grunt work that eats the time you need for it.

What agents handle well: token diffs, doc stubs, component inventories, migration PRs, parity checks. What they don't own: tradeoffs, brand judgment, adoption politics, saying no to a one-off that will haunt you for six quarters.

We won 1st place at the Into Design Systems AI Hackathon 2026 with SwapWizard, a plugin that smart-swaps mismatched components. The lesson: point AI at tedious high-volume work; free seniors for the conversations that build trust.

Collaboration + AI workflow:

• Planner agent structures the screen; human approves the plan with eng.
• Executor implements tasks; design engineer reviews for system fit.
• Reflect pass catches drift before the PR embarrasses anyone in review.

Bad collaboration with AI lets the agent invent the product. Good collaboration lets the team spend meeting time on taste, scope, and adoption, not renaming layers.

11 · Anti-patterns

Stop doing these. Today.

12 · 30-day collaboration sprint

Start here. This month.

A minimal program to prove collaboration ROI before a full system build.

If week 4 shows adoption on one component and fewer Slack questions, you've proved the model. Scale into the 100-day system playbook.

What to do next

Want a senior second opinion?

I help DACH and EU product teams turn UI chaos into systems that scale, govern, and ship. Start with the part that hurts most, then book a consult if you want help running it.

16+ years · Nord/NordVPN design systems (dozens of teams, millions of users on Aurora) · React/TypeScript · 1st place, Into Design Systems AI Hackathon 2026