← David Randolph CASE 02 / 04
Motion graphic · 20-second loop · illustrative

SYSTEMS · PLATFORM · CROSS-FUNCTIONAL LEADERSHIP

Atlas: one design system for three products and forty engineers

By my third National Grid product, the problem was hard to miss: our three products looked like they came from three different companies. I founded Atlas, pitched it as a speed investment rather than a style project, and grew adoption until teams chose it by default.

MY ROLE
Founder & design lead
TEAM
Me, 2 front-end engineers, an 8-person contributor guild
TIMELINE
Mar – Dec 2024 · National Grid
TOOLS
Figma variables, React, Storybook
82%
Of production UI built from Atlas components
−35%
Median front-end build time per feature
54 → 97%
Audited screens meeting WCAG 2.1 AA
14 → 1
Button implementations in the codebase
01 — THE PROBLEM

Inconsistency was a cost nobody was counting

I audited all three products in a week and screenshotted every interactive pattern. We had 14 different buttons, 9 date pickers, 41 shades of grey, and no shared definition of "error." For employees moving between two of our tools, it felt like switching vendors.

A previous design-system attempt had stalled because it was pitched as a visual cleanup. Engineering leadership saw it as a cost with no deadline. I needed a different argument.

02 — MAKING THE CASE

I pitched speed, not beauty

I paired with an engineering manager to time-track five recent features. On average, 31% of front-end time went to rebuilding UI that already existed somewhere else. Multiplied across 40 engineers, that was roughly 12 full-time people rebuilding buttons.

That number got a yes from the VP of Engineering in one meeting — and two dedicated engineers for a six-month pilot, with a clear success bar: cut build time by 20% on pilot teams.

03 — FOUNDATIONS

Tokens first, so three brands could share one engine

Each product kept its own personality. A three-tier token model — raw values, semantic roles, component slots — let one component library render three brands, plus dark mode, with no forked code.

TIER 1 · PRIMITIVES
blue-100 … blue-900
TIER 2 · SEMANTIC
action-primary → blue-600
feedback-danger → red-600
surface-raised → white / grey-850
TIER 3 · COMPONENT
Pay invoice Pay invoice Pay invoice
One button, three brands, light and dark — zero forks.
04 — PRIORITIZING

Build what's used most, not what's most fun

I ranked every component by usage frequency × number of inconsistent versions. The top 12 — buttons, inputs, selects, tables, modals, toasts — covered 70% of all screens. We shipped those first, each with accessibility built in: focus states, keyboard support, ARIA patterns and contrast-checked tokens.

Data tables were the hardest. I ran sessions with the internal teams who work in them all day and designed for density first: sticky headers, inline editing, and keyboard-driven bulk actions.

05 — ADOPTION

Making the right way the easy way

Mandates create resentment. Instead, I treated product teams as my customers:

Office hours
Twice a week. Every request logged and answered within 48 hours.
Contributor guild
8 designers and engineers who could propose and ship components.
Codemods
Scripts that migrated old buttons automatically — 2,300 swapped in a day.
Adoption dashboard
Public coverage per team. Friendly competition did the rest.
06 — IMPACT

The pilot beat its target — then the system funded itself

Pilot teams cut front-end build time by 35% against a 20% target. Leadership made Atlas a permanent team of four. By December 2024, 82% of production UI came from Atlas, and accessibility compliance on audited screens rose from 54% to 97%.

07 — REFLECTION

What I learned

A design system is a product. It has users, a roadmap and a churn rate. The moment I started running it that way, adoption stopped being a fight.

Document decisions, not just components. Early on we wrote usage docs but not the "why." When I went on leave, the guild re-litigated three settled debates. We added decision records afterward.