Case Study: Design System

Codifying 15 Years of Design Drift in a Week, with Claude

• Client: Enterprise software company (custom development shop)
• Product: Workforce development platform
• Role: Lead UI/UX designer, working with Claude
• Timeline: About one week, fall 2026

In about a week, Claude and I reverse-engineered a design system out of 15 years of design drift across over sixty screens, with attention to accessibility compliance paid to each atomic detail. Then we wrote it so Claude could enforce it without a designer in the room.

That designer is me, by the way. A year ago, I would have been the designer this project replaced. AI's role in product design is inevitable, so I've pivoted. Now the components I design aren't just illustrations; they speak in code. I take on bigger challenges, move fast, tinker and iterate, and spend more time in a flow state than in a Jira board or a Slack channel. The design judgment didn't leave the room. The method changed.

I've spent a lot of time asking whether drawing the boxes and lines myself is essential to feeling creatively expressed. For me, it isn't. Developing the aesthetic is. AI lets me take bigger chances with it, change direction when something isn't working, and show clients fully designed options with several aesthetic treatments. This project shipped three: the current state, a refined version, and a vision of its future.

Overview

The product is a workforce development platform: it tracks training, skills and certifications for learners, their managers and the administrators who run it. It is more than 15 years old. It has survived several tech stacks, several eras of best practice, and repeated customization for individual clients. It is also the base for industry-specific editions.

In October 2026, the company asked me to retrofit a design system onto it. The why was simple: they wanted non-designers to be able to add new screens and features to the product. The bar was specific: detailed enough that their developers could use Claude to design new pages, confident that the design rules would carry over without a designer directly involved. The system also had to be reskinnable, with colors, fonts and button shapes mapped to each client's brand. And it had to come together on a tight timeline, with no budget to fix or recode the screens that already shipped.

My gentle pushback from the onset of the project: new pages built on an unfixed product add technical debt. I believe agentic coding will make that debt much cheaper to pay down later, so my aim was to hold the client to best practices without blocking them today.

Fifteen years of drift across 60+ screens raised problems no greenfield design system faces.

How it worked

I started with a pilot on one component, the data table. From there, every screen followed the same rhythm. I captured it from the demo site and narrated what each control does and what bothers me about it. Claude drew it three ways, mapped each part to a component and logged the issues. Claude and I brought complementary strengths to the design review. I'd gripe about side panels that open overlays. Claude would catch contrast ratio issues I'd have needed an external tool to notice myself.

Challenges and solutions

1. Three products' worth of styling in one product

Of the 62 screens I inventoried, 18 were built with Tailwind, 35 with Bootstrap 3, and 8 mixed the two. Each used different fonts, colors and spacing, so the same element looked different from page to page.

The move: don't describe what exists. Name the role each element plays (control border, table header, selected row) and give every role one token. All three stacks can then point at the same names.

2. Document the product, or fix it?

The review found 212 issues, and the urge to correct them was strong, especially the outright best-practice failures: poor contrast, color as the only signal, controls that did nothing. But the short-term priority was different. New pages had to match the product as it ships today, so the system first had to document the current state, flaws included. And many of the problems were structural, which no amount of restyling could reach without recoding.

The move: don't choose. I delivered three themes and drew every screen in all three in the same pass:

• Current documents the product exactly as it ships, so new pages fit in today.
• Refined corrects best-practice failures as far as CSS alone can reach. Its hard rule: only stylesheet and token values may change, no recoding. It ships through the per-site stylesheet slot each client site already has.
• Vision offers one possible direction for the product's future, labeled that way on purpose so it invites reactions instead of approval.

The gap between Refined and Vision shows exactly which problems need a rebuild. Refined fixed spacing, type and color on almost every screen. The problems users notice most (wording, structure, missing feedback) only went away in Vision.

3. Turning 15 years of drift into rules

Drift isn't one big mistake. It's hundreds of small inconsistencies.

The move: log every issue with location, type, severity and a suggested fix (212 in all: 3 high, 82 medium, 127 low), then group them into 18 recurring patterns, each with the rule that fixes it. Four date formats and six paging styles became one of each.

Color got the same treatment: one meaning per status color, and never color alone. White-on-orange grid cells at 2.0:1 contrast (4.5:1 is required) became icons on a neutral cell.

Image: the activity grid in Current, Refined and Vision.

4. "Do we need this control?"

Old enterprise screens collect controls nobody questions. I made one question a principle and asked it of every screen. A Next/Previous pager on a settings table with only a few rows. Removed: setup lists under about 100 rows now show everything. An "add" button that did nothing when clicked. A side panel that opened a full-screen overlay just to pick a person. Replaced with a small menu.

5. Writing rules for a reader with no taste

With no designer in the loop, rules can't lean on judgment. "Keep it clean" means nothing to an AI.

The move: every rule exists three ways: a drawn screen for people deciding, a plain-English rule for designers and developers, and a file Claude reads before it builds. Rules are short yes-or-no checks Claude can verify against its own output, such as "The name is the link. No separate View button." Anything it can't follow, it must report.

A single entry file routes Claude to only the specs and checklists each task needs.

Image: the records table shown as drawing, rule and Claude file.

6. More output than humans can absorb

Doing this much work this fast yields a ton of output, more than most human teams will reasonably read or review. Issues and questions also surface faster than humans can respond to them.

The move: design the output for how it will actually be consumed, and let humans catch up at their own pace:

• A package Claude reads in full. Even if no human reads everything, the Claude-optimized package guarantees that one reader does, every time it builds.
• A hub for the humans. One page gives a visual overview of every output and clearly separates what's for humans to read from what's for AI to consume.
• An issues log built to be worked through. All 212 issues, each with a suggested fix and a status, grouped into 18 patterns so one decision can cover dozens. Humans, or Claude, can clear them at whatever pace makes sense.
• Best guesses, marked and listed. I kept moving on informed guesses, marked each one on the canvas, and collected the 12 questions only the client can answer in one list.

The speed didn't push decisions onto the client faster than they could make them. It gave them a backlog they could act on at their own pace.

Designer as editor, AI as production team

I brought judgment, product knowledge and the client relationship. Claude did the volume work of drawing, logging, writing and checking. That split is the point: the deliverable lets Claude keep doing this after I step away.

What I did

• Captured and narrated every screen, and made the calls: which problems matter, what the future should feel like, what the client would accept.
• Separated real bugs from drawing artifacts, and kept Vision ideas out of Refined. (Of one hover-animation idea, my own note was: "Maybe I'm getting carried away.")
• Steered the presentation, for example asking to "see just enough to demystify" the Claude-facing files. That became the hub's "three ways" section.

What Claude did

• Built every screen in code instead of Figma, in three themes from the same markup, and logged all 212 issues along the way.
• Wrote each rule once and generated everything else from it: specs, theme CSS, a Tailwind preset and the hub.
• Checked its own work, from contrast ratios in every theme to a new admin screen built only from the package.

What the split made possible. Because Claude carried the production load, my time went almost entirely to judgment calls. That is what let a project of this size happen in about a week instead of months.

What was delivered

In about a week, the system covered most of the product, with reporting deferred at the client's request. Five principles settle most questions before they reach a meeting: one meaning per status color, never color alone, question every control, say what happens in plain words ("Add 2 mentors," not "Submit"), and one component per job.

What I learned, and what's next

• You can't codify a design you haven't excavated. The archaeology (62 screens, 212 issues, 18 patterns) was most of the work.
• Speed moves the bottleneck to review. When AI produces more than humans can read, the deliverable has to be designed for both of its readers: a complete package for the AI, and a clear map for the humans.
• The real user of this design system is an AI. That changed how every rule was written: checkable, not inspirational.
• Two strategies, not one. "Manage drift" (Claude keeps new pages consistent) can start now; "rebuild on a common stack" can follow screen by screen. The client pictured the first; the evidence points toward the second.

The ending isn't written yet. The real test is whether Claude, using only the package, builds new features that pass the client's review.

• Outcome of the first features built from the package
• Whether Refined ships to a live client site
• Which strategy the client chooses: manage drift, rebuild, or both
• How many of the 12 best guesses held up

My Takeaway

I started this project as the designer who wouldn't be in the room. I finished it knowing I'd never been more in it. Every rule Claude follows is a call I made. Every Vision screen is an aesthetic I chose. The boxes got drawn faster than I ever could have drawn them, and I spent my time on the part I actually care about: deciding what good looks like. That's the job now, and I'm glad it's mine.