04.4 / onyx
◆ shipped · v1 → succeeded by AI-augmented v2
Onyx Design System
A nucleus-based design system extending Material Design for enterprise financial services. The pre-AI foundation that the current AI-augmented design system was built on top of.
- Role
- Senior UX Designer · Delaware Life · 8 months
- Stack
- Figma (primary library)StorybookMaterial Design (extended)Design tokensAtomic methodologyCross-team governance
◆ 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.
◆ solution
Nucleus-based design system extending Material. Token-first architecture, atomic methodology (tokens → atoms → molecules → organisms), comprehensive documentation, and PR-time validation.
◆ impact
Faster feature development cycles. Strong adoption across multiple product teams and high satisfaction across both designers and engineers.
§01 · problem
Material Design wasn't enough for financial workflows.
A rapidly growing financial services platform had fragmented design language across multiple products. Material Design was the foundation, but teams interpreted and implemented components inconsistently. Material's out-of-the-box components didn't cover complex financial workflows. Engineers rebuilt similar components repeatedly. Design debt accumulated. Handoff was slow and component-by-component.
- Material Design components didn't address complex financial workflows or data density.
- Engineers rebuilt similar components in isolation across multiple product teams.
- No common design language between cross-functional teams.
- Adobe XD lacked developer-friendly features and enterprise collaboration; tooling itself was a bottleneck.
§02 · users
Many engineers, many teams, a small design team.
The system had to serve engineers distributed across multiple product teams, supported by a small in-house design team. The architecture problem was leverage: how does a small designer team ship at the velocity of a much larger engineering org without becoming the bottleneck themselves?
§03 · approach
Nucleus-based architecture: tokens first, components composed.

Four architectural decisions:
- extend, not replace · extended Material Design rather than starting over, preserving the established mental model while addressing enterprise needs.
- token-first · design tokens as foundational layer for scalability and maintenance, not as a styling afterthought.
- atomic methodology · tokens → atoms → molecules → organisms → templates, with composition rules at each tier.
- responsive-native · responsive considerations built into every component at the foundation level, not bolted on later.
§04 · process
28-week build with two engineers.
Designer (me) + 2 engineers. Sequenced to land tokens and primitives before composition.
- research (6 weeks) · pattern audit across all product interfaces; interviews across product teams; competitor analysis.
- tokens (4 weeks) · extended Material foundations; systematic typography scale; spacing and sizing systems.
- component architecture (8 weeks) · nucleus-based component library; financial workflow extensions; data-density and regulatory-compliance patterns.
- documentation (4 weeks) · usage docs, interactive component library with code examples, governance processes.
- implementation + training (6 weeks) · production rollout, training across teams, feedback loops for continuous improvement.
§05 · outcomes
Faster cycles. Wide adoption. Shipped.
- Feature development cycles got measurably faster after teams switched onto the system.
- Strong satisfaction across designers and engineers, confirmed in cross-team surveys.
- Adopted across multiple product teams as the standard for new work; legacy components migrated on their own cadence.
- Unified user experience across the product surface area.
- Improved accessibility through enforced color- contrast and typography standards.
§06 · v2
What came after: AI-augmented v2.
Onyx was the pre-AI foundation. By the time it was in production across two brands, five failure modes had stacked up that no amount of more designers could fix:
- no source of truth · no Code Connect between Figma and production code; drift kept happening because nothing authoritatively said what a component was.
- no production documentation · how components actually interacted in production was tribal knowledge. Every new feature required re-deriving it.
- two-brand scale · maintaining the system across two brands took too long. Each new component feature was hard to track and easy to lose.
- figma make prototypes · designers were prototyping in Figma Make and getting sign-off on designs the production stack couldn't actually render. Figma Make didn't know our stack. Stakeholders were approving things that would never ship as designed. Hosted prototype URLs had nowhere to live and kept getting lost.
- generative-AI drift · once designers started using generative AI to design, drift accelerated. The system had no mechanism for keeping AI-generated work inside the contract.
The AI-augmented v2 attacks all five directly. Code Connect mapping Figma to the production stack. Component-interaction documentation as a pipeline, not tribal knowledge. Hosted prototype surfaces that know the stack. AI-orchestrated review gates that catch drift before sign-off rather than after.
See the AI-augmented design system →