Where AI sits in my process
What I hand to it, what I keep, and where I've learned not to trust it.
The Problem
As a solo designer or one embedded in a fast-moving startup, production work (setting up design tokens, formatting copy, synthesizing 30 user interviews) eats up the time I should be spending on strategic product decisions and talking to users. "I use AI in my workflow" is often an empty buzzword. I needed to build a concrete, measurable system that offloaded rote production without outsourcing actual design judgment.
Compress a standard 3-5 day design production and research synthesis cycle down to a single day, freeing up time for high-leverage product strategy and iteration.
What I've actually learned using it
The thing I keep running into is that AI is very good at reading across a lot of material and very bad at knowing what any of it is worth. It will find the same theme across thirty interview transcripts faster than I can, and then weight that theme the same as one a single person mentioned once, with no idea that the second one came from the only user in the set who was going to pay us. Finding the pattern is the cheap half of synthesis. Deciding which pattern outranks the others, against a constraint the business actually has, is the part I still do by hand.
The same split shows up in copy. If I ask for "copy for this empty state" I get something serviceable and anonymous. If I hand it the voice rules I've already written down (short sentences, no exclamation marks, never call the user a "creator") and ask it to edit a draft I wrote, I get something I can ship. It's a much better editor than it is a writer, and most of what I get out of it comes from setting it up as the former.
Where it goes wrong most reliably is trade-offs. Ask it to improve a flow and it will improve that flow, cheerfully, at the expense of the system around it: a new pattern here, a one-off component there, none of it wrong in isolation. It has no sense that consistency is a thing being spent. So the line I hold is roughly: direction, naming, prioritisation and voice stay with me; token setup, component scaffolding, transcript synthesis and first-pass copy edits go to the machine. And I'd rather build a narrow agent for a specific job than type into a general chat box, because a job I've written the rules down for is a job I can check.
Two things I built this way
The PeerX design system, via Figma MCP
Building the PeerX system by hand (40+ components, 23 variables) was days of repetitive clicking and consistency checking, most of it the kind of work where being careful is the entire skill. I rebuilt it through Figma MCP in 2025 and have used the same workflow since.
The setup is two-part: I generate the component sets and variables from a token source, then run a second agent whose only job is to read the result back and flag anything that doesn't match the rules: a hardcoded hex where a variable should be, a component missing a state, spacing that doesn't sit on the scale. I still decide what the system is; it does the part where a human gets bored on component 34 and stops checking.
Roughly 75% off the build time, which is what let the MVP ship weeks earlier than it otherwise would have.
Narrow agents instead of a chat box
I don't get much out of general-purpose prompting. What works is building small Claude-based agents for jobs I've already written the rules for: one for UX writing against a voice guide, one for research synthesis against a question list. The rules are the actual work; the agent just applies them consistently.
↓
Claude (Transcript Synthesis)
↓
Figma (Affinity Mapping & Design)
↓
Cursor (Code UI Components)
↓
Prototype (Lovable)
↓
Handoff to Developer
↓
Iteration
I step back in to refine the hover micro-interactions and adjust the border radius from 8px to 4px to match the global brand token, making the component production-ready.
Tradeoffs & Decisions
Using Cursor for Prototyping vs Figma
Pros: Zero code required, native to the design tool.
Cons: Limited by Figma's state management. 'Fake' data entry.
Pros: Real inputs, real state logic. Identical to final product.
Cons: Steeper initial setup curve.
The highest-fidelity feedback comes from someone typing their own data into a real input, not clicking a 'next' hotspot in Figma. Coded prototypes cost me more setup and got me answers I'd have otherwise had to guess at.
What changed in practice
Manual Component Building
↓Days of formatting variables
↓Less time talking to users
Components generated from tokens
↓Variables set up in an afternoon
↓More time talking to users
Business Impact
Reflection
- What worked: Treating AI as an automated editor rather than a creator yielded instantly usable results.
- Where I don't trust it: it is confident when it's wrong, and the failure looks like competence. Building the PeerX token set, it handed me a clean eight-step type scale off a 1.25 ratio: internally consistent, mathematically perfect, and wrong, because half the interface needed two adjacent steps to sit on the same row and read as equal weight, and no ratio knows that. I had to break the scale by hand in two places. It optimises whatever rule it was handed. It won't tell you the rule was the wrong one.
- The real value: The honest version of this isn't "AI replaces design thinking." It's that repetitive production gets compressed, meaning more of my actual time goes into talking to users and arguing with myself about a trade-off.