design system

Built an AI-readable Design System
For Consistent, On-brand UI Generation

Over the past few years of development, our design system was often overlooked — leading to messy components, visual inconsistency, and frustrating slowdowns for both design and development teams.
I led the charge to rethink and rebuild it from the ground up: modular, scalable, and theme-ready

Timeline

V1: Q1 2025
V2: Q1 2026

My Role

Lead Product Designer

Team

Led design with
1 Designer and 1 Intern

Scope

Tokens · Library · AI rules

Problem

The design system was fragmented and difficult to scale.

As Jefit's product surface continued to grow, our original design system struggled to scale. Colors were managed manually, components lacked a reusable structure, and common UI patterns had evolved into multiple inconsistent versions over time.
‍
This created three key problems:

01

Unscalable Color System

Colors were defined as static values rather than semantic tokens, making theme updates difficult and preventing efficient support for future color modes.

02

Poor Reusability

Components were built as individual assets instead of flexible systems. Designers often duplicated and modified existing components, leading to unnecessary maintenance overhead.

03

Slow Handoff to Engineering

Handoff to engineering was inefficient and error-prone. Components lacked standardization and clear guidelines, with too many custom variants. Engineers often had to guess how things should work or rebuild them from scratch.

We often had to rebuild UI from scratch because the components didn’t support real use cases.
— Frontend Engineer

Process

1. Token-based foundation

The original system relied on hard-coded values and duplicated components, making updates difficult and reuse inconsistent. I rebuilt the foundation around semantic tokens and structured component architecture, creating a shared language that was easier for designers to understand, maintain, and eventually, for AI to interpret.

Before

▸Frame 217

▸Group 4

▭Rectangle 12

TText

▸Group 5 copy

After

◈Card/base

◈Button variant=primary

◈Button variant=ghost

◈Badge tone=success

◈ProgressBar

Instead of referencing visual values directly, the new system introduced semantic tokens that describe purpose rather than appearance. This created a single source of truth for themes, component variants, and future system expansion.

#1B1D26→text/primary

#878C98→text/muted

#F5F4F9→surface/base

#FFFFFF→surface/raised

#2E69FF→accent/brand

#2E69FF→ai/accent ✦

#12B76A→state/success

#F0455A→state/danger

2. Theme support through variants

Components were redesigned using variants and semantic tokens, enabling support for both Light and Dark modes without creating separate component libraries. Theme changes could be applied systematically rather than manually screen by screen.

3. Reusable components at scale

Common UI patterns were consolidated into flexible component structures with configurable properties and states. Designers could assemble new experiences by reusing existing building blocks instead of duplicating and modifying components, improving both consistency and design velocity.

• Auto layout, variants, and constraints for all core components
• Clear naming + consistent structure = faster design & handoff
• Built with real usage scenarios in mind

challenge

UI had grown faster than the system holding it together.

Components had been copy-pasted and tweaked until "the same" button existed in a dozen slightly different forms. There was no variant model, no dark mode, no shared library — and nothing a machine could reason about. So I ran two optimisation passes: first make it a real system for the team, then make that system readable to AI.

Pass 1 · for the team

Loose parts → a system

Turn detached elements into structured components.

Elements & components consolidated into one library
Variants (state / size / type) instead of copies
Color modes — light & dark from one token set
Semantic tokens & names underneath

→

Pass 2 · for AI

System → AI-readable

Layer AI-specific structure on the clean system.

Usage rules the AI must obey
Used AI to complete the variant coverage at scale
Tuned it so AI generates UI that matches real design
Closed the loop: AI reads → drafts → I refine

Then I made that system readable to AI

With a clean system in place, the AI work was no longer "make AI guess better" — it was giving the AI structure and rules to compose from. Two parts: how I did it, and the result.

How · the rules & structure I added

Usage rules

Constraints the AI must obey, written into the system.

Before

No rule for the AI accent → AI defaults to purple, the "AI cliché" colour.

After

ai/accent = brand-blue documented as a rule → AI uses it every time.

Semantic tokens

Meaning instead of hex, so AI knows intent.

Before

#1C1C1E — AI can only guess what it's for.

After

text/primary — AI reads the role and picks correctly.

Instead of asking AI to design components, I first defined the system. Once the foundations were in place, AI generated the remaining component states and variants while following the same rules—allowing the design system to scale much faster without sacrificing consistency.

Using AI to Scale the Design System

Component	Default	Hover	Active	Loading	Disabled	Dark
Button	had	AI	had	AI	AI	AI
Card	had	AI		AI	AI	AI
Badge	had				AI	AI
ProgressBar	had		AI	AI		AI

Built by hand

✦ AI-completed

Not applicable

result

Same prompt. Same AI. The only thing that changed was the system underneath.

I asked the AI to generate one component — before the system upgrade, and after. This is the whole case study in one image.

Prompt “Create an exercise item.”

Before Visual reference only

Default

≡

Dumbbell Incline Fly With A Twist

3 sets · 8 reps 120 sec

Superset

≡

Dumbbell Incline Fly With A Twist

3 sets · 8 reps

SUPERSET

Completed

✓

Dumbbell Incline Fly With A Twist

3 sets · 8 reps

Tailwind defaultsrounded-lg · 8

Without component specs

Generic utility defaults
States styled independently
Component anatomy drifts

After Component spec available

Default

Dumbbell Incline Fly With A Twist

3 × 8 reps 120s

Superset

↗

Dumbbell Incline Fly With A Twist

3 × 8 reps 120s

Completed

✓

Dumbbell Incline Fly With A Twist

3 × 8 reps 120s

Thumbnail radius · 10Defined variants

With component specs

States are real variants
Anatomy stays consistent
Tokens stay enforced

Prompt“Build the fitness-level onboarding step.”

BeforeAI uses generic form patterns

Onboarding · AI output

9:41● ◖ ▰

Step 2 of 16

FITNESS PROFILE

Choose your fitness level

Select the option that best describes you.

Off-scale spacingMixed radiiGeneric form UI

What drifted

Card composition was improvised
Selected state uses a generic radio
Progress and CTA patterns do not match

AfterAI uses the onboarding pattern

Onboarding · AI output

9:41● ◖ ▰

2/16

What is your fitness level

Defined choice cardSelected variantSticky CTA

What matched

Choice cards keep fixed anatomy
Selected state is a real variant
Progress and CTA follow the screen pattern

result

Across the two passes, AI played two roles at once.

I asked the AI to generate one component — before the system upgrade, and after. This is the whole case study in one image.

🛠️

AI as builder

Completed the system — generating missing variants & states at a scale that would take weeks by hand.

→

richer system

←

better drafts

✦

AI as consumer

Reads the finished system to draw real UI. The cleaner the system, the better it draws.

The two roles compound: a better system lets AI build more of it, which lets AI draw from it better. That flywheel is the real asset — not any single component.

result

The system made reuse the default.

Once tokens, variants, and composition rules became explicit, AI stopped rebuilding familiar UI and started assembling with the system. Component reuse increased, first drafts became more consistent, and designers spent less time correcting spacing, states, and structure. The system became an active part of the workflow—not just a reference.

01

Higher component reuse

Existing components and variants are used before new UI is created.

02

Faster UI assembly

Documented composition rules move work from rebuilding to assembling.

03

Fewer visual corrections

Spacing, radius, states, and component structure match on the first pass.

Takeaways

What I'd carry forward.

AI-readiness is a system-health problem first. Pass 2 only worked because Pass 1 made the system structured and legible.

Rules are design. A one-line constraint ("accent = brand blue") shaped more screens than any single component I drew.

Still open. this covered the tooling-facing side (AI reads the system). The product-facing AI patterns — streaming, confidence, accept/reject — are the next layer to formalise.