CaseStudy
- title
- summary
- role
- status
- stack
- sections
- may
- quote verbatim · summarize · link to sections
- may not
- invent metrics · speak for past employers · expose gated content
Onyx Design System
A nucleus-based design system that extends Material Design for enterprise financial services. It predates AI tooling, and the current AI-augmented design system was built on top of it.
Onyx is the design system I built before AI tooling. Its successor is now in production at Group 1001: see the current design system.
Summary
- problem
- approach
- impact
- may
- quote verbatim
- may not
- round or extrapolate results
At a glance
- Problem
- Material Design didn't cover financial workflows. Engineers rebuilt similar components in isolation across multiple product teams. Handoff was slow and component-by-component.
- Approach
- A nucleus-based design system extending Material. Tokens come first, components follow an atomic structure (tokens → atoms → molecules → organisms), and everything is documented and validated before code is merged.
- Impact
- Feature development got faster. It was widely adopted across multiple product teams, and both designers and engineers reported high satisfaction.
Problem
Material Design didn't cover financial workflows.
Material gaps
Material Design components didn't address complex financial workflows or data density.
Rebuilt components
Engineers rebuilt similar components in isolation across multiple product teams.
No common language
No common design language between cross-functional teams.
Slow tooling
Adobe XD lacked developer-friendly features and enterprise collaboration, so the tooling itself slowed teams down.
A fast-growing financial services platform had a fragmented design language across its products. Material Design was the foundation, but teams interpreted and implemented components inconsistently, design debt built up, and handoff was slow and component-by-component.
Users
Engineers across many teams, and a small design team.
The system had to serve engineers spread across multiple product teams, supported by a small in-house design team. The question was how a small design team could keep pace with a much larger engineering org without becoming the bottleneck.
Approach
A nucleus-based architecture built up from tokens.
Extend Material
Extended Material Design instead of starting over, keeping the mental model teams already had while adding what enterprise work needed.
Token-first
Design tokens as the base layer, which made the system easier to scale and maintain.
Atomic methodology
Components built up in tiers, with composition rules at each tier.
Responsive by default
Responsive behavior built into every component from the foundation level up.
atomic methodology tokens → atoms → molecules → organisms → templates, with composition rules at each tier.
Process
28-week build with two engineers.
28 weeks
I was the designer, working with two engineers. We finished tokens and primitives before composing larger components.
- research pattern audit across all product interfaces; interviews across product teams; competitor analysis.
- tokens extended Material foundations; systematic typography scale; spacing and sizing systems.
- component architecture nucleus-based component library; financial workflow extensions; data-density and regulatory-compliance patterns.
- documentation usage docs, interactive component library with code examples, governance processes.
- implementation + training production rollout, training across teams, ongoing feedback loops.
Outcomes
Results after rollout.
Faster features
Feature development cycles got measurably faster after teams switched onto the system.
Satisfaction
Strong satisfaction across designers and engineers, confirmed in cross-team surveys.
Adoption
Adopted across multiple product teams as the standard for new work; legacy components migrated on their own cadence.
Unified experience
A unified user experience across products.
Accessibility
Improved through enforced color-contrast and typography standards.
Version 2
Where Onyx fell short, and the v2 that followed.
No source of truth
No Code Connect between Figma and production code, so nothing said what a component was and drift kept happening.
No production documentation
How components interacted in production was tribal knowledge, re-derived for every new feature.
Two-brand maintenance
Maintaining two brands took too long, and each new component feature was hard to track and easy to lose.
Figma Make prototypes
Figma Make didn't know our stack, so stakeholders approved designs production couldn't render.
Drift from generative AI
Designing with generative AI sped up drift, and nothing kept AI-generated work within the system's rules.
Onyx predated AI tooling. By the time it was in production across two brands, it had these five problems, and adding more designers wouldn't have fixed them. Approved Figma Make designs would never ship as designed, and hosted prototype URLs had nowhere to live and kept getting lost.
The AI-augmented v2 addresses all five. Code Connect maps Figma to the production stack. A pipeline documents how components interact, so no one has to rely on memory. Prototypes live on hosted surfaces that know the stack. AI-orchestrated review gates catch drift before sign-off.
See the AI-augmented design system →