One system.
Six products.
Three client brands.
A token-based design system that lets 6 enterprise products maintain visual coherence while expressing 3 distinct client identities - built, documented, and adopted by 4 designers and 12 engineers across 12 months.
One system.
Six products. Three clients.
How I designed and shipped a shared UI architecture for an enterprise energy platform suite - delivering a token-based design system that lets 6 products maintain visual coherence while expressing 3 distinct client brands.
Before the system existed
- 4 different button styles in production across products
- No shared spacing scale - teams guessed independently
- New engineers spent 3+ weeks building UI from scratch before writing product logic
- AI features (confidence scores, agent state) solved differently in every product
- Design reviews consumed 40% of sprint time on pixel-level debates
“We were shipping 6 products at once. Without a shared system, we'd be shipping 6 separate design languages - each one technically correct, none of them coherent.”
Defined the 4-layer architecture, token taxonomy, and AI component conventions. Secured CTO and Design Director sign-off.
Managed 4 senior designers. Set contribution model, review cadence, and versioning governance. Ran weekly system critique sessions.
Led AI component design from scratch: confidence visualization, agent state indicators, uncertainty communication. No reference system existed.
12 months. 6 phases.
Each phase had a defined scope, a measurable output, and a handoff to the next. No phase started until the previous was stable.
Inventoried all existing components across 6 product codebases. Found 247 unique UI elements, 89 of which were duplicates with visual variation.
Defined 7 token categories (Color, Typography, Spacing, Radius, Elevation, Motion, State). Every decision documented with rationale and WCAG compliance notes.
Built 87 components in order of product demand. Each component had accessibility spec, usage guidelines, and 3 usage examples.
Designed 12 AI-specific patterns from scratch: confidence bands, model state indicators, uncertainty visualization, agent workflow blocks, and human-AI handoff states.
Built the theming engine. 3 client themes delivered as token overrides - zero component forks.
Published contribution guidelines, deprecation protocol, and weekly system office hours. Established design system as a product, not a project.
4-Layer System
From raw design tokens to client-branded product experiences - every layer is independent, versioned, and composable.
Three decisions that defined the architecture
Every system has forks in the road. These are the ones that mattered - and why we chose differently than the default.
The instinct was to copy-paste existing components and standardize them. I pushed back.
Starting with tokens forces alignment on values - color philosophy, spacing intent, motion meaning - before anyone has opinions about button border radius. Components built on shaky tokens are just a different kind of technical debt.
The engineering default was to create separate theme components (ButtonThemeA, ButtonThemeB).
3 clients × 87 components × 2 modes = 522 component variants to maintain. A single CSS variable override reduces that to 1 component, infinite clients. The theming layer becomes a data problem, not a component problem.
The plan was to add AI-specific states (loading, confidence, error) as modifiers on existing components.
AI interactions have fundamentally different trust semantics. A button in error state means "try again." An AI panel in low-confidence state means "don't act on this yet." Treating them as the same pattern obscures a critical difference. AI components needed their own vocabulary.
Live Demo
The same component layer responds to any client theme and light/dark mode. No layout changes. No component forks. Just token overrides.
Seismic anomaly in Block 7. Pattern match suggests producible reservoir. Recommend interpretation session within 14 days.
| Well ID | Field | Status | Production | Change |
|---|---|---|---|---|
| W-1024 | Murban | Active | 8,420 | +3.2% |
| W-0891 | Field B | Active | 7,180 | −1.1% |
| W-1156 | Field B | Drilling | — | — |
| W-0734 | NDC | Active | 6,890 | +5.4% |
12 patterns. One trust framework.
When we started adding AI features, no design system reference existed for the patterns we needed. I led the design of 12 AI-specific components grounded in a Trust Framework I wrote alongside the system.
Don't show AI output as true/false. Show it as a spectrum with thresholds that map to human decisions.
Users need to know if AI is loading, processing, confident, uncertain, or degraded. Each state has a distinct visual treatment.
When AI recommends and a human decides, that transition must be designed. Not implicit.
Horizontal bar showing AI confidence %, with threshold zones (green/amber/red).
Dot + label showing: idle / processing / confident / uncertain / degraded.
Range display (not point estimate) for predicted values.
Two-state button: "AI recommends X" → "I approve".
Small chip showing which model/data source produced a result.
"Why did AI suggest this?" expandable panel.
What actually happened
Measured outcomes 90 days after v1 launch, across 3 product teams and 3 client onboardings.
After adoption, product teams shipped UI features 40% faster. Measured by sprint velocity before/after system adoption across 3 teams.
First quarter post-launch with no design review failures due to component inconsistency. First time in 2 years.
Client B (4 days), Client C (3 days), a third in 5 days. Previous baseline: 6–8 weeks of UI customization per client.
What I learned
The hardest part wasn't the components. It was convincing product managers that investing 12 months in infrastructure would return 10x in product velocity. I learned to speak in product language - time-to-market, onboarding cost, regression risk - not design language.
You can't design AI confidence indicators without first deciding: what does confidence mean to the user? I needed to answer a product question before I could answer a design question. That shift - from "how does it look" to "what decision does it support" - is what makes AI product design different.
A design system without adoption is a side project. The governance model - office hours, contribution protocol, deprecation policy - was what turned this from a library into infrastructure. Infrastructure is invisible when it works. That's the goal.