My Design System Workflow

Building Kärlek was genuinely fun — but something felt incomplete. A design system isn't really end-to-end until the components live in both Figma and code. So I set out to build a React + TypeScript component library to match.

I used the same AI-assisted workflow that's been working really well for me lately: Figma paired with Gemini CLI for development, and Claude for planning. Together they've been surprisingly good at nailing interaction details and layout precision. I connected the Kärlek design system file to Gemini CLI via MCP, asked Claude to draft an execution plan, then converted the design system documentation into a design.md file — essentially a set of instructions written in a way that's easy for AI to parse and follow. That file made it significantly easier for Gemini CLI to understand the rules defined in the system, and components started coming together fast. I built 5 of them in under 2 hours, including design accuracy and accessibility checks.

I set up Storybook for visual and accessibility testing alongside the build. The whole thing left me with that rare feeling of genuine leverage — like the workflow was amplifying what I could do, not just automating the boring parts. It also got me thinking. Writing the design.md file forced me to think critically about the architecture of every design system I've worked on before — and what AI changes about how those systems should be built in the first place.

Different Design Systems Architecture

Most of the hard work is done once you have a robust variable system — but only if you define those variables based on your product's actual needs, not what the industry is doing by default. Every product requires a different level of flexibility or complexity, and identifying that early is what gets the system right.

That became clear to me while writing the design.md file for Kärlek. Most of the context AI needed was already encoded in the variables themselves, which made translating the system into instructions surprisingly direct. Something like:

### Theme Support

Theme switching is handled via the `.dark` class on the body or container, which swaps the semantic variable mappings.

That one line works because the variable architecture already made the rule explicit. The documentation was almost writing itself. Not every design system should be architected the same way — and the token structure is where that difference shows up most.

Kärlek (Type 1) was built for a high-growth startup shipping new features and components daily, so flexibility was the priority. Semantic tokens defined at the component level kept things lean — introducing something new was as simple as defining the tokens and building. No ceremony.

(Type 2) was a different problem entirely. It was a white-label product, so we added a theme layer sitting between the global primitives and the semantic tokens. That layer is what lets the system absorb any brand's colors while still enforcing consistency and accessibility. The complexity earns its place there — but it would have been dead weight in Kärlek, where there were only two theme modes and speed of component work mattered most.

Layout tokens follow a similar logic to color, but with a different default. They're usually kept off the semantic layer — one component often needs multiple layout tokens, and defining them semantically adds complexity without much payoff. Flexibility in structure tends to win.

Except on HSV (Type 3), where the UI was designed to be generated and adapted dynamically by AI. There, explicit rules weren't optional. Semantic layout tokens became necessary because AI needs defined constraints to produce UI that's consistent and intentional — not just technically valid.

AI + Design System

HSV was where this thinking got stress-tested. Building the Figma side, I kept thinking about implementation — and the more I thought about it, the more the system just fell into place. The design.md file and the semantic tokens weren't two separate concerns; they were the same decision expressed in two different places.

The core rule for HSV was strict: components could only be assembled from within the system. No one-offs, no exceptions. For generative UI to work, that constraint has to hold — and that means the instructions fed to AI need to be detailed enough that there's no room to improvise outside the boundaries. Loose rules break the system. Tight rules let it scale.

What struck me is how close this is to how we build components with AI assistance today. The gap between a designer directing AI and AI generating UI autonomously isn't a gap in capability — it's a gap in how well the system is defined and communicated. The workflow is already the same. The instructions just need to get more precise.

That points to something worth keeping in mind when defining any architecture, from a standard design system to something as complex as a generative UI layer: the system should adapt to the application, not the other way around. The moment you start bending the product to fit the system, you've already lost the thread.

AI hasn't just changed how we build components — it's changed how we think about systems entirely. New AI interaction patterns are defining new architectural requirements, and design systems are no exception. That's a meaningful shift, and it deserves to be treated as one. Systems thinking and UX principles can't operate in separate lanes anymore. Companies that want to sustain a healthy design practice need to bring both together — deliberately, from the start — or they'll spend a lot of time retrofitting decisions that should have been made at the foundation.