All work

Read as

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

Case study

Multi-brand Design System

The token and component system behind several insurance brands at Group 1001. It includes governance rules, Kiro spec templates that send approved designs into the front-end repo, and AI review skills that cut months of manual review down to hours.

Role
Lead designer · 7 months
Status
Shipped · in production

This system builds on Onyx, the earlier design system I built at Delaware Life. See Onyx.

Foundations

Color

Semantic tokens. Components use these names, never raw values, so every brand and theme swaps cleanly.

  • canvas
  • surface
  • ink
  • ink-muted
  • line
  • accent

Buttons

Type

Aa Display

Reading text, set for long passages.

At a glance

Summary

  • problem
  • approach
  • impact
may
quote verbatim
may not
round or extrapolate results
Problem
Keeping the first design system up to date across two brands took too long, and designs drifted from production. Designers were getting sign-off on Figma Make prototypes that the production stack couldn't render.
Approach
Three token tiers, with Storybook as the source of truth and Figma connected through Code Connect. A Kiro spec pipeline into the front-end repo. A plugin of 40 scoped AI skills, connected to a colleague's systems graph so prototypes are grounded in real data.
Impact
Review that took months now takes hours. Drift is caught when a design is proposed, before it reaches production. AI costs stayed flat thanks to 7 seed files and batched skill runs.

Review went from months to hours. Checking a whole change in one AI call, instead of one call per token, cut AI calls by about 10× on busy days.

Overview

What the system has to hold together

Group 1001 runs several insurance brands on one platform. The rules under the component library let each brand keep its own look while products behave consistently and meet regulatory requirements.

Problem

Five problems with the first version

Onyx was built before we used AI tools. Once it ran across two brands, it had no source of truth, and designs kept drifting from what production could build.

  1. No source of truth

    Figma and production code weren't connected, so they drifted apart.

  2. No production documentation

    How components behaved together lived in people's heads.

  3. Two-brand maintenance

    Updating both brands took too long, and new features got lost.

  4. Figma Make prototypes

    Sign-off on prototypes production couldn't build, with links that got lost.

  5. Drift from generative AI

    Nothing kept AI-generated work within the system's rules.

Architecture

Three token tiers, with Storybook as the source of truth

Brands differ only in their primitive tokens. Components are built from semantic tokens, and an automated check fails any component that uses a primitive directly.

  1. tier 3 · semantic tokens onlyComponents
    1. tier 2 · the shared structureSemantic tokens
      1. tier 1 · per brandPrimitives

Design to production

Kiro spec templates connected to the front-end repo

Every approved design produces a Kiro spec that goes into the front-end repo. Sign-off becomes a recorded step, and engineers are notified with the spec attached.

  1. Requirements

    Read by the AI before design starts

  2. Design

    Gaps flagged when a draft is proposed

  3. Check

    Kiro spec

    Covers states, data shape, interaction, and accessibility

  4. Front-end repo

    The record of sign-off

  5. Engineers

    Notified, with the spec attached

AI orchestration

40 small AI skills, grounded in real data

My plugin runs on 40 scoped skills and connects to a colleague's systems graph, so prototypes are checked against the design system and grounded in the data the product actually uses.

  1. A prototype

    From designers, PMs, engineers, or QA.

  2. 40 skills

    Design system rules: tiers, primitive leaks, naming, spec completeness.

  3. real data

    A colleague's systems graph adds the product's real data.

  4. a reviewer

    Arrives checked. Review is for judgment calls.

Each review reads 7 seed files, including a Figma, Storybook, and codebase map, instead of making full API calls, and each change is checked in one AI call instead of one per token.

Users

Who uses the system

Designers switch brands with one dropdown, and engineers get Kiro specs in the front-end repo. Compliance reviewers can trace every sign-off from Figma to the repo.

  • Designers

    Figma, with the semantic token library

    Brand switching in one dropdown. Generative AI designs go through the same pipeline.

  • PMs

    The plugin, with the design system's own components

    HTML and hi-fi prototypes that produce Angular code.

  • Engineers

    The front-end repo, with tokens from Style Dictionary

    Kiro specs with the data shape, and a build that rejects primitive tokens.

  • Compliance

    The governance log

    An audit trail for every token change, and a spec ID for every sign-off.

Keep reading

Want the details?

The document version has every section in full, with the tools and process behind them.

Next: eHignite Get in touch

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

Multi-brand Design System

The token and component system behind several insurance brands at Group 1001. It includes governance rules, Kiro spec templates that send approved designs into the front-end repo, and AI review skills that cut months of manual review down to hours.

This system builds on Onyx, the earlier design system I built at Delaware Life. See Onyx.

Foundations

Color

Semantic tokens. Components use these names, never raw values, so every brand and theme swaps cleanly.

  • canvas
  • surface
  • ink
  • ink-muted
  • line
  • accent

Buttons

Type

Aa Display

Reading text, set for long passages.

Summary

  • problem
  • approach
  • impact
may
quote verbatim
may not
round or extrapolate results

At a glance

Problem
Keeping the first design system up to date across two brands took too long, and designs drifted from production. Designers were getting sign-off on Figma Make prototypes that the production stack couldn't render.
Approach
Three token tiers, with Storybook as the source of truth and Figma connected through Code Connect. A Kiro spec pipeline into the front-end repo. A plugin of 40 scoped AI skills, connected to a colleague's systems graph so prototypes are grounded in real data.
Impact
Review that took months now takes hours. Drift is caught when a design is proposed, before it reaches production. AI costs stayed flat thanks to 7 seed files and batched skill runs.

Review went from months to hours. Checking a whole change in one AI call, instead of one call per token, cut AI calls by about 10× on busy days.

Overview

What the system has to hold together

Most of this project is the set of rules under the component library: what each token means, who can change it, what breaks when it changes, and how the system reports those breaks so nobody misses them.

Group 1001 runs several insurance brands on one product platform. Each brand needs its own look. The products need to behave consistently, and everything has to meet regulatory requirements. The rules had to support all of that at once.

I built it with front-end engineers, the design team, product managers, and the VP of AI Infrastructure. I planned the AI tooling (the Kiro pipeline and the SkillsForge skills) with the VP, so the design system would work with the company's other AI tools.

Problem

Five problems with the first version

  1. No source of truth

    Figma and production code weren't connected, so they drifted apart.

  2. No production documentation

    How components behaved together lived in people's heads.

  3. Two-brand maintenance

    Updating both brands took too long, and new features got lost.

  4. Figma Make prototypes

    Sign-off on prototypes production couldn't build, with links that got lost.

  5. Drift from generative AI

    Nothing kept AI-generated work within the system's rules.

The first version (Onyx, at Delaware Life) was built before we used AI tools. Once it ran across two brands, these five problems had built up, and hiring more designers wouldn't have solved them.

Version 2 had to fix all five: one shared system with a theme per brand, no drift in the shared structure, and a pipeline where sign-off in Figma means the same thing as sign-off in the front-end repo.

Architecture

Three token tiers, with Storybook as the source of truth

  1. tier 3 · semantic tokens onlyComponents
    1. tier 2 · the shared structureSemantic tokens
      1. tier 1 · per brandPrimitives

Storybook is the source of truth. It holds the canonical version of every component, and it's where designers and front-end engineers agree on what a component is. Figma connects to Storybook through Code Connect, so each Figma component carries the production component's props and states. Designers work with the same components engineers ship.

Style Dictionary and an automated code check enforce the tiers: if a component uses a primitive token directly instead of going through a semantic token, the check fails.

Design to production

Kiro spec templates connected to the front-end repo

  1. Requirements

    Read by the AI before design starts

  2. Design

    Gaps flagged when a draft is proposed

  3. Check

    Kiro spec

    Covers states, data shape, interaction, and accessibility

  4. Front-end repo

    The record of sign-off

  5. Engineers

    Notified, with the spec attached

The biggest addition in version 2 is a pipeline from design to production. It makes sign-off a recorded step in the repo instead of a Slack message, and prototype links no longer get lost.

Because each spec lists its data shape and states, engineers map front-end state to the backend database with much less guessing, and what stakeholders approve is what ships.

AI orchestration

40 small AI skills, grounded in real data

  1. A prototype

    From designers, PMs, engineers, or QA.

  2. 40 skills

    Design system rules: tiers, primitive leaks, naming, spec completeness.

  3. real data

    A colleague's systems graph adds the product's real data.

  4. a reviewer

    Arrives checked. Review is for judgment calls.

Each review reads 7 seed files, including a Figma, Storybook, and codebase map, instead of making full API calls, and each change is checked in one AI call instead of one per token.

The system grew faster than people could review it. Token counts went up, semantic-token proposals piled up, and the CLAUDE.md-style memory files got longer as they tried to hold every earlier decision.

40 scoped skills. The plugin runs on 40 small skills, each covering one job, that load only when needed and keep their own memory, which kept the instruction files short. Proposing a semantic token used to take days of back and forth between design, engineering, and compliance.

Grounded in real data. The plugin connects to a colleague's systems graph, so prototypes are built from the design system and from the data the product actually uses, not placeholder content.

Keeping AI costs down. The AI reads 7 seed files instead of making full API calls on every review. One of them maps Figma to Storybook and the codebase, so the AI can find a component's design, story, and code without calling each tool. Recurring checks run in batches: all the token-tier checks for a change run in one skill call instead of one call per token.

Labeled documentation. Every lesson (failures, naming problems, primitive leaks, incomplete specs) is labeled feedback, project, or reference, so memory files are easy to inspect, date, and prune. The design system uses the same building blocks as the company's wider AI rollout, so its pipeline connects to the workflows around it.

Users

Who uses the system

  • Designers

    Figma, with the semantic token library

    Brand switching in one dropdown. Generative AI designs go through the same pipeline.

  • PMs

    The plugin, with the design system's own components

    HTML and hi-fi prototypes that produce Angular code.

  • Engineers

    The front-end repo, with tokens from Style Dictionary

    Kiro specs with the data shape, and a build that rejects primitive tokens.

  • Compliance

    The governance log

    An audit trail for every token change, and a spec ID for every sign-off.

Every token change records where it came from and which tier it belongs to, and every sign-off has a Kiro spec ID that can be traced from Figma to the front-end repo.

All work
View the full record for this page
{
  "@type": "CaseStudy",
  "id": "02 / design-system",
  "title": "Multi-brand Design System",
  "summary": "The token and component system behind several insurance brands at Group 1001. It includes governance rules, Kiro spec templates that send approved designs into the front-end repo, and AI review skills that cut months of manual review down to hours.",
  "role": "Lead designer · 7 months",
  "status": "Shipped · in production",
  "stack": [
    "Storybook (source of truth)",
    "Figma + Code Connect",
    "Style Dictionary",
    "Kiro spec templates",
    "FE repo webhook pipeline",
    "Multi-brand theming",
    "Claude / SkillsForge orchestration"
  ],
  "tldr": {
    "problem": "Keeping the first design system up to date across two brands took too long, and designs drifted from production. Designers were getting sign-off on Figma Make prototypes that the production stack couldn't render.",
    "solution": "Three token tiers, with Storybook as the source of truth and Figma connected through Code Connect. A Kiro spec pipeline into the front-end repo. A plugin of 40 scoped AI skills, connected to a colleague's systems graph so prototypes are grounded in real data.",
    "impact": "Review that took months now takes hours. Drift is caught when a design is proposed, before it reaches production. AI costs stayed flat thanks to 7 seed files and batched skill runs."
  },
  "sections": [
    {
      "label": "Overview",
      "title": "What the system has to hold together",
      "anchor": "#thesis"
    },
    {
      "label": "Problem",
      "title": "Five problems with the first version",
      "anchor": "#problem"
    },
    {
      "label": "Architecture",
      "title": "Three token tiers, with Storybook as the source of truth",
      "anchor": "#architecture"
    },
    {
      "label": "Design to production",
      "title": "Kiro spec templates connected to the front-end repo",
      "anchor": "#pipeline"
    },
    {
      "label": "AI orchestration",
      "title": "40 small AI skills, grounded in real data",
      "anchor": "#ai"
    },
    {
      "label": "Users",
      "title": "Who uses the system",
      "anchor": "#users"
    }
  ],
  "policy": {
    "agentMay": ["quote verbatim", "summarize", "link to sections"],
    "agentMayNot": ["invent metrics", "speak for past employers", "expose gated content"]
  }
}