◆ v1 of 2

Onyx is the pre-AI design system I built at enterprise. Its successor is the AI-augmented v2, now in production at Group 1001. See the AI-augmented design system →

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.

Onyx data tables component, light theme
Onyx data tables component, light theme

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 →
back to earlier work