The old way: weeks of busywork
Building a design system component the old way went like this. Day one: audit existing implementations across five apps, screenshot inconsistencies, compile a spreadsheet of variations. Day two and three: design the ideal version in Figma — every state, every variant, every breakpoint, every accessibility annotation. Day four and five: write documentation, create usage guidelines, prepare a presentation for the engineering team. Day six: present, debate, revise. Day seven: update the Figma library and hope engineers actually use the new component.
Two weeks. For a button. A dropdown took longer. A data table could take a month if you included all the sorting, filtering, pagination, and empty state variants. This is not because I was slow. This is the pace of a thorough design system build. Or at least, it was.
Now I can do the same work in an afternoon. The quality is comparable. The documentation is better. The engineers get implementation-ready code alongside the design specs. Here is exactly how.
The Claude-to-Figma pipeline
I start in Claude, not Figma. I describe the component I need — let us say a data table with sorting, filtering, row selection, and a bulk action bar. I specify the design tokens: spacing scale, colour palette, type ramp, border radius. I tell Claude the constraints: this must work on tablets used outdoors, so minimum touch target is 48px. High contrast. No hover-dependent interactions.
Claude generates the component specification — not just visual design, but interaction patterns, accessibility requirements, keyboard navigation, loading and empty states. It writes the Tailwind classes. It provides the React component structure. I review and refine through conversation, not through pixel-pushing. The back-and-forth takes maybe 30 minutes for a complex component.
Then I take the Claude output into Figma. There are plugins now — and manual workflows — that can convert structured design specifications into Figma components. The colours, the spacing, the variants, the auto-layout. It is not perfect one-click magic. I still need to adjust alignment, fine-tune spacing, and add the polish that only a human eye catches. But the grunt work — the repetitive setup of variants, the tedious token mapping, the manual creation of every state — that is gone. What used to take days now takes me an hour.
What the AI gets right (and what it still messes up)
AI is genuinely good at consistency. It does not forget that the border radius should be 8px on the third variant when it was 8px on the first two. It does not accidentally use a colour from the wrong palette. It handles the combinatorial explosion of component states — loading, empty, error, disabled, focused, hovered, active — without fatigue. A human designer will cut corners on state coverage after hour four. The AI does not get tired.
AI is also excellent at documentation. It writes clear, structured guidelines. It explains the 'why' behind decisions when I prompt it to. It generates code snippets in multiple frameworks. It creates contrast-checking tables for accessibility compliance. Documentation used to be the part I dreaded most. Now it is the part that takes the least effort.
But AI still struggles with taste. It will give me a competent data table. It will not give me a data table that feels right for a specific brand in a specific context. It does not know that the Valmont design system should feel industrial but not cold — robust but not clunky. That nuance comes from me. I provide the direction. The AI provides the execution.
It also struggles with novel interaction patterns. If I ask for a standard dropdown, it nails it. If I ask for a map-based field selector that lets users draw polygons on satellite imagery to define irrigation zones — something I actually designed for the Field Layout Tool — the AI has no reference point. It needs me to define the interaction first. Then it can help with the implementation details.
How this changes the designer's role
Here is the uncomfortable truth: a lot of what we called 'design system work' was actually production work. It was assembling variations, mapping tokens, writing documentation, updating libraries. It was skilled work — but it was repeatable. And repeatable work is what AI is best at automating.
What remains is the thinking work. Deciding what a component should do. Choosing which interactions feel right for the users. Understanding the context — the environment, the device, the user's mental state. Negotiating with stakeholders about priorities. Making trade-offs between consistency and flexibility. These are design decisions, and AI cannot make them.
The designers who thrive will be the ones who lean into the thinking work and let go of the production work. If your value proposition is 'I can build a design system faster than anyone,' AI will catch up to you. If your value proposition is 'I know what this system should be and why,' AI will never catch up to you — because that requires judgment, and judgment requires a human who has made mistakes, learned from them, and developed taste.
The exact workflow, step by step
For anyone who wants to try this: here is my current process. Step one — audit with AI. I screenshot existing components across all apps and ask Claude to identify inconsistencies. This replaces the manual spreadsheet phase. Step two — define tokens in conversation. I describe the brand, the platform constraints, the accessibility requirements. Claude proposes the token structure. I approve or revise. Step three — generate the component spec. I ask for all states and variants, with Tailwind classes, with accessibility annotations, with React skeleton code. I review and iterate over chat. Step four — convert to Figma. This is the messiest step. Currently I use a combination of plugins and manual setup. By the end of 2026, I expect this to be one click. Step five — publish. Figma library gets updated. Documentation goes to the team wiki. Code skeleton goes to the engineering repo. Engineers build on top of my foundation instead of starting from scratch.
The whole thing takes me about four hours for a complex component, start to finish. The same work used to take two weeks. That is not an exaggeration. The bottleneck is no longer production speed. The bottleneck is thinking speed — how fast can I make good decisions? And honestly, I am still working on that part.