Skip to content
Back to case studies

Design Systems

How My Approach to Design Systems Evolved

Fifteen years and five systems: from unifying a fragmented UI, to domain-built rigor, to engineering systems that AI agents can implement correctly.

My approach to design systems did not arrive fully formed. It evolved.

It began with unifying a fragmented visual language, sharpened into domain-specific rigor, matured into a disciplined token architecture with accessibility built in as a constraint, and now centers on engineering systems that AI agents can implement correctly and fast. Through all of it a few beliefs held: tokens are the source of truth, semantics beat raw values, accessibility is structural rather than a final QA pass, and a good system makes the right thing the easy thing.

2016
Era 1

Ictinus · Orfium · V5.1.1

Foundations & token architecture

Ictinus began as a way to unify a fragmented language, and matured into a disciplined token architecture.

I joined Orfium as the first designer. The system started out serving dense music-rights tooling, then grew with the company into the broader entertainment industry. Over years of iteration, theming and consistency became automatic rather than manual.

A system's power lives in its token architecture, not its component count.

291
Tokens, four tiers
139
Global, raw values
31
Dimension, spatial aliases
87
Semantic, theming engine
34
Component, element tokens

Global holds raw, immutable values. Dimension aliases spatial scales. Semantic is the context-aware color layer, the theming engine itself. Component tokens bind it all to specific elements. One change cascades everywhere.

comp/button/normal/size, to sizing/9, to 36px

borderColor/default, to blue/4 (light), to blue/6 (dark)

naming schema: {tier}/{category}/{property}/{variant}

Theming happens by token swap, not by inversion. Dark mode shifts scale positions to keep perceived weight. Accessibility is a constraint, not a final check: every text and background pair is validated to WCAG AA with the Stark plugin, and if a token cannot pass 4.5:1 on its surface, it does not ship. The 291 tokens are the result of relentless subtraction, not addition.

#E9EFFB#DAE4FB#B8CCFA#8EAAEC#5E8DF8#175BF5#194DCC#173DA0#173382#12204E
One of 9 raw palettes (10-step ramps) feeding the semantic layer.
Component library
Ictinus component library in Figma (navigation, inputs, datagrid), light and dark.
Variables panel
Figma variables panel showing the four-tier groupings: global, dimension, sem, comp.
2020
Era 2 · Stage 1

Pounce · Panther

Designing for the domain

Pounce was built for a dark-first SIEM, where density and severity are not optional.

Every token was shaped by the operational reality of security work: late-night triage, split-second decisions, dense log data. Building it taught me that a system has to fit its domain.

Domain-specific systems outperform generic ones.

50+
Tokens
14
Spacing steps
6
Color categories
11
Type sizes
7
Component sizes
5
Severity levels

Severity is a first-class token category: Success, Warning, Error, Info, Critical, each with a foreground and a background. It is the backbone that lets analysts scan a dashboard and know where to look.

#0F1923#162231#1E2D3D#243648#2A3F54
Surface layering creates depth without borders.

Spacing was tuned for tables of 10,000+ rows, with virtualization in mind and minimal animation. Text tokens hold 4.5:1 on their surface, and the cyan focus ring (border/focus, #38BDF8) stays visible in both themes. Type is DM Sans across a 10 to 40px scale. Beyond standard UI, Pounce carries domain components: a JSON Tree for nested log schemas, an embedded Python editor for detection rules, and a syntax-highlighted JSON preview.

Domain component
A security component in Panther: the JSON Tree or the embedded Python rule editor (dark).
Severity in context
Status badges or table rows showing the five-level severity system.
2025
Era 2 · Stage 2

Pounce · Panther

Remediation & theming rigor

I built Pounce. Years later I came back to rescue it.

I was full-time at Panther from 2020 to 2024, and a contractor since. In 2025, with the design team tiny and me part-time, the company brought in an external firm to tokenize, revamp, and add a light theme, work I could not staff at the time. It failed on several levels. The clearest was theming: a transparency, alpha-based color scale that could not hold across light and dark, because a token's effective contrast depended on the surface behind it. Flipping themes broke legibility and introduced real accessibility issues. That, plus years of accumulated tech debt, pulled me back in. I rebuilt the system accessible and correct in both themes, working iteratively with the front-end engineers to find and replace old code and broken components, with AI tooling doing the heavy lifting.

A color scale that looked fine in one theme broke the moment you flipped it.

Before and after theming
Before and after theming: the broken alpha-based theme versus the corrected, accessible result, light and dark.
2025
Era 3

Lungo · Dialectica

AI-native delivery

Lungo is engineered so AI can implement it correctly.

As Principal Designer I lead Lungo, Dialectica's token-driven, multi-theme system. It grew out of an earlier system called Smoothie, but the refactor became a ground-up rebuild. I work in close partnership with the engineer who owns implementation, and together we built the toolchain around the system. Custom Figma plugins export tokens in a Style-Dictionary shape, keep version history and diffs so an LLM implements only what changed, and emit component specs as both YAML and Markdown. On top of that I authored AI skills and rules for Claude and Cursor that enforce the system's components, constrain building to approved tokens, surface implementation gaps, and audit work against the system.

The design source of truth and the code that ships stay in lockstep.

01Figmasource of truth
02Token exportStyle Dictionary shape
03Versioned + diffedimplement only what changed
04CodeAI-assisted, constrained
Figma to code: the Lungo delivery pipeline.
md
# AI skill, Claude / Cursor
- Build UI only with approved Lungo components. Never hand-roll equivalents.
- Use only tokens from the export. No raw hex or arbitrary values.
- Flag any gap where the system lacks a needed component or token.
- Audit the diff against the system and report violations before finishing.
Token export plugin
Custom Figma plugin UI: the token-export or spec-export panel.
Skill in action
Claude or Cursor building against Lungo, constrained to the system.
2026
Era 4

ProxyFoods · Contractor

AI-assisted migration

A full migration from stock shadcn to a themed system, done mostly with AI.

A platform for food scientists. I took full ownership of moving from a base shadcn/ui setup to a more advanced, themed system with custom components and variants. I executed it primarily with AI assistance, following the front-end engineering chapter's best-practice guidelines so the output stayed aligned with their standards.

Stock baseline in, a themed and extensible system out.

AspectBase, shadcn/uiThemed system
Themingsingle, hardcodedlight and dark, tokenized
Variantsstock defaultscustom variants and sizes
Tokensad hocsemantic and Style Dictionary
A11yunverifiedchecked across themes
Before and after components
Before and after components: base shadcn baseline versus the themed system with custom variants.

What stayed constant

  • Tokens are the source of truth.
  • Semantics over raw values.
  • Accessibility is a constraint, not a QA pass.
  • A system fits its domain.
  • Enforceable beats documented, and now, AI-enforceable.

Where this is going

As agents take on more implementation, the design system becomes the source of truth that governs them. The designer's leverage shifts toward toolmaking and guardrail-setting: deciding what is allowed, encoding it, and making the system the path of least resistance for humans and machines alike.