A design system that brought speed and consistency to 4 product teams
A token-based design system in Figma and React that eliminated component duplication across 4 product squads and cut the time from design handoff to merged frontend.
The brief, in specifics
- Industry
- Professional Services
- Duration
- 14 weeks
- Cooperation model
- Fixed price, phased
- Services
- Design tokensReact component libraryDocumentation
- Integrations
- StripeSendGridSegmentSentry
- Technologies
- ReactTypeScriptTailwind CSSFigma TokensStorybooknpm
- Team
- 1 Project lead2 Product designers1 UX researcher1 QA engineer
Client name withheld under NDA. Engagement details are shown to the extent our agreement permits.
Every surface, in order
The color foundation: 84 tokens published from one Figma source to npm, every swatch carrying its hex value, and the contrast ratios that decide which may hold body text.
Adoption by squad: eight components across four products, and Onboarding at 62 percent, still hand-rolling its own date picker, table, modal and data grid.
Thirty days of use: 8,412 component instances in production, 84 percent of the UI on the system, and the six components still duplicated where there were thirty-seven.
Type and spacing scales: every step mapped from its Figma variable to the CSS custom property it compiles to, with two small steps marked AA only, not for body text.
The Storybook playground: the data grid with its props, its five states, and the accessibility checks that run on every story, at zero violations.
The migration guide: Onboarding's hand-rolled date picker beside the system component, with the prop renames, the codemod, and 41 call sites changed across 9 files.
The brief
Four product teams were building with slightly different buttons, inputs, and patterns. We built one design system everyone actually liked using.
Four product teams, twelve web surfaces, and a component audit that found nine visually distinct primary buttons. Nobody had decided on nine; each had been reasonable at the moment it was written. The engagement was commissioned when a compliance review flagged accessibility defects that turned out to be present in eleven of the twelve surfaces, each needing its own separate fix.
Design Engineering
What people were running into
Designers spent hours rebuilding the same components, and developers shipped inconsistent UI patterns across products.
The duplication was expensive in an unusual way. Building the ninth button was cheap; the cost was that a fix to any one of them fixed one surface. The accessibility findings made that concrete: the same missing focus state had to be corrected eleven times, by four teams, on four schedules, with no way to verify it had been done everywhere.
We built a shared design system with Figma tokens, a React component library, and interactive Storybook documentation.
Design decisions
- 01
Audited components across 12 existing product surfaces
The audit found nine visually distinct primary buttons, none of which anyone had decided on: each had been reasonable when it was written.
- 02
Created a token system for color, typography, and spacing
Tokens live in Figma variables and export to one JSON source the Tailwind theme is generated from, with CI failing the build on drift.
- 03
Engineered an accessible React component library with Storybook
Every interactive primitive was keyboard and screen-reader tested against WCAG AA before it entered the library, ahead of any adoption.
- 04
Embedded with squad leads to migrate existing products smoothly
Squad leads had the team beside them for the whole migration, since each of the four had already worked around a handed-over library.
Phase by phase
Phase 1: Inconsistent Component Audit
Product UI & Token Inventory
Audited 12 scattered fintech web applications to catalog duplicated button, form, and table component variants.
- Component Inconsistency Audit
- Token Inventory
- UI Debt Matrix
Phase 2: Core Token & Figma Library
Token Architecture & Accessibility
Designed unified Figma design tokens for color, typography, spacing, and accessible contrast ratios.
- Figma Token Architecture
- Accessibility Spec
- Token Engine
Phase 3: React Library & Storybook
npm Package & Component Portal
Engineered accessible React component library published to private npm with interactive Storybook docs.
- React UI Component Library
- Storybook Portal
- npm Package
Phase 4: Product Squad Migration
Multi-App Adoption & Sprint Speed
Migrated 4 core fintech applications, cutting the time from design handoff to merged frontend by 40% with zero UI regressions.
- App Migration Clearances
- Developer Adoption Workshop
- SLA Monitor
The audit that started it: nine visually distinct primary buttons across twelve surfaces, and eleven of the twelve missing a visible focus state.
Figma Token Sync & Design System
Bi-directional design tokens keeping Figma mockups and React code strictly aligned.
Tokens live in Figma variables and are exported to a JSON source of truth that the Tailwind theme is generated from, so a designer who changes a color changes the code, with no ticket in between. The sync runs in CI and fails the build on drift, which is the only thing that actually keeps a design system aligned once the launch enthusiasm wears off.
- Figma variables exported to one JSON source of truth
- Tailwind theme generated from it, never hand-maintained
- CI fails the build on token drift
A Figma variable exported to tokens.json and generated into the Tailwind theme, and the CI drift check failing the build where the generated value was edited by hand.
The financial table at row 214 of 1,000: tabular, right-aligned numerals, negatives in parentheses as well as red, the header pinned, a visible focus ring, and the keyboard, screen-reader and WCAG AA checks it passed before entering the library.
Accessible Fintech Component Library
WCAG AA compliant tables, inputs, buttons, and modal dialogs engineered for financial data.
Financial tables are the hard part: numerals are tabular and right-aligned so columns compare by eye, negative values are marked by more than color, and the header stays sticky through a thousand rows without leaving the accessibility tree. Every interactive primitive was tested with keyboard and a screen reader against WCAG AA before it entered the library, not after adoption.
- Tabular numerals, right-aligned, negatives marked beyond color
- Sticky headers that stay in the accessibility tree
- Keyboard and screen-reader tested before entering the library
Storybook Interactive Documentation
The modal's loading, empty, error, dense and long-content stories under visual regression, one change held for review, and the docs version picker set to the release Payments still runs.
Live component playground and developer documentation hosted on private Storybook server.
Storybook is the contract: every component ships with its states (loading, empty, error, dense, long-content) as stories, so a consumer can see what they're getting without reading the source. Visual regression runs over those stories in CI, and the private deploy is versioned alongside the npm package, so a team on an older release reads the docs for the version it actually has.
- Loading, empty, error and long-content states as stories
- Visual regression run over the stories in CI
- Docs versioned with the package, not just the latest
What moved after the redesign
-40%
Design handoff to merged frontend
100%
WCAG accessibility
12 of 12
Apps on single system
Build velocity is measured as time from design handoff to merged frontend for comparable feature work, before and after, across the four teams. The accessibility figure is a third-party audit of the component library rather than of every consuming surface. Twelve of twelve is adoption of the npm package, not of every pattern within it.
Client name withheld under NDA. Figures are approximate, drawn from the engagement’s own reporting.
Principles that held
Unified component library cut the time from design handoff to merged frontend by 40% on comparable feature work.
The velocity gain was in the second and third use, not the first: the library cost more to adopt than to ignore once, and less every time after.
Strict WCAG AA accessibility tokens eliminated UI compliance defects.
Defects went to zero because the fix has one home. The same missing focus state had previously needed correcting eleven times, with no way to verify it.
Private npm package powered consistent design across 12 product web applications.
Shipping as a versioned package instead of a shared folder is what made twelve of twelve possible: teams could adopt on their own schedule and still converge.
How design and engineering worked together
A cross-functional team of 4 worked on a fixed price, phased basis over 14 weeks, covering Design tokens, React component library, Documentation. We ran a weekly demo and a shared board they could read at any time. Their team took over day-to-day operation before the engagement ended, with handover built into the last phase.
The team embedded with squad leads through migration instead of delivering a library and a deprecation notice. That's the difference between a design system that gets adopted and one that becomes the thirteenth surface. The four teams had all been given libraries before, and had all routed around them for reasons that turned out to be specific and fixable.
The fix has one home
One missing focus state: eleven fixes, or one
The compliance review found the same defect on eleven of twelve surfaces. With nine different buttons, that meant eleven fixes by four teams and no way to check them. With one Button component, it's one change in one release. Switch tabs, or use the arrow keys once one is focused.
A fix to one button fixed one surface. The compliance review found the same missing focus state on 11 of 12 surfaces, so it became 11 tickets in four backlogs.
Onboarding team
Own backlog, own sprint
- Sign-up flowButton A
Patched, unverifiedPatched in sprint 31
- Identity checkButton B
ScheduledScheduled for sprint 33
- Welcome dashboardButton C
OpenNot started
Payments team
Own backlog, own sprint
- TransfersButton A
Patched, unverifiedPatched in release 4.12
- Bill payButton D
Patched, unverifiedPatched, different ring color
- Payee adminButton E
OpenIn backlog
Lending team
Own backlog, own sprint
- Loan applicationButton F
ScheduledWaiting on vendor form
- Underwriting consoleButton G
OpenNot started
- RepaymentsButton F
Patched, unverifiedPatched on links only
Wealth team
Own backlog, own sprint
- PortfolioButton C
ScheduledScheduled for Q4
- StatementsButton H
OpenNot started
- Advisor consoleButton I
Had a focus state
11
of 12 surfaces missing the focus state
11
separate fixes, one per surface
4
teams, on four schedules
None
way to verify it was fixed everywhere
From a Figma variable to twelve apps
A value changes in one place and travels through the same five stages every time, so the design file, the generated code, the docs and the shipped product can't quietly disagree.
- 1 · Source
Figma variables
- Color, type and spacing defined once, as variables
- A designer changes the value, not a ticket
One source of truth: nothing else defines a token
- 2 · Ingestion
JSON token export
- Variables exported to tokens.json
- Committed next to the code that reads it
The Tailwind theme is generated from it, never hand-maintained
- 3 · Engine
Build and checks in CI
- Tailwind theme and CSS properties generated
- Drift check against the committed theme
- Visual regression over every story
A token that drifts fails the build
- 4 · State
Versioned release
- @tessera/react on the private npm registry
- Storybook deployed at the same version
- Primitives keyboard- and screen-reader-tested first
Nothing enters the library untested against WCAG AA
- 5 · Delivery
Consuming apps
- Twelve apps across four squads install the package
- Each squad upgrades on its own schedule
The docs a team reads match the version it installed
Shared without breaking anyone
Change safety & accessibility
Visual regression on every story
Each component ships its loading, empty, error, dense and long-content states as stories, and visual regression runs over all of them in CI. A change to how a component renders is caught in the library, before any team installs it.
Versioned, adopted on each team's schedule
The library ships as a versioned private npm package with docs deployed for each version, so a release reaches a product only when its squad upgrades. Migration was done embedded with each squad lead, with zero UI regressions.
Accessibility tested before entry
Every interactive primitive is keyboard- and screen-reader-tested against WCAG AA before it joins the library. A third-party audit put the component library at 100% WCAG AA; it covers the library, not every surface built with it.
Product teams shipping the same component four different ways? Scope your build in 3 minutes.
Scope your buildNearby engagements
AI & AutomationA private legal assistant grounded in verified precedents
A private knowledge assistant that searches internal case files and precedents, providing cited answers legal teams can verify in seconds.
Legal & Law Firms · 14 weeks
Product DesignAn onboarding flow that guides trial users to value
A redesigned SaaS trial onboarding experience with progressive checklists, sample data, and inline guidance that turns signups into active subscribers.
Professional Services · 10 weeks
Web PlatformsThirty small tools behind one account, each one a template and a route
A Python platform where adding a tool means adding a template and a router, with no deployment of its own, and subscriptions, orders and webhooks shared across every one of them.
Professional Services · 20 weeks
Let's talk
Running a large platform, shaping a first MVP, or getting a product ready for a funding round? Tell us where you are. We'll shape the process around it, and stay with you after launch.
