For years, every design started the same way. Open Figma, drop a frame, push pixels around until something looked right. Figma was where I did my thinking.
It isn't anymore. These days it's the last tool I open, not the first. The thinking moved upstream, and AI is the reason. Here's the actual process, and why the order matters more than the tools.
Design the problem before you design anything
The most useful thing I do now happens before a single pixel exists. I take the messy input — the ticket, the Slack thread, the half-formed ask from a founder — and work through it with Claude until the problem is clear.
I don't ask it for a design. I ask it to argue with me. What are we actually solving? Who are the stakeholders, and where would they disagree? What breaks if we ship nothing? It's a rubber duck that talks back. Most times I find the problem I wrote down first was a symptom, and the real one is sitting a layer underneath.
Karri Saarinen has a line I keep coming back to: design projects usually fail because the problem was never clear, so everyone quietly solves a different one. AI makes it cheap to get clear before you commit. It would be foolish not to.
A prototype argues better than a mockup
Once I have a solution in mind, I don't draw it. I build it. A rough, clickable prototype in Replit, often with a coding agent doing the heavy lifting, ready in the time it used to take me to lay out a few frames.
A mockup is a picture of an idea. A prototype is the idea, behaving. People respond to the two completely differently. Show someone a static screen and they critique the layout. Hand them something they can click and they tell you whether it actually works. The second conversation is the one worth having.
Align before you polish
That prototype isn't a deliverable. It's a conversation piece. I put it in front of the team early, while it's still ugly, precisely because ugly things are easy to change.
This is where alignment happens, and it's the step most people skip. Disagreement is cheap to resolve when nothing on the screen is precious yet. Find it now, in a rough build, and you avoid the much worse version where it surfaces after a week of polish. That early agreement is what decides whether the work survives. Skip it and even flawless execution just gets you to the wrong place faster.
Figma comes last now, and that's the point
Only once the team agrees on direction do I open Figma. And the job there has changed. Figma used to be where I figured out what to build, which meant I produced beautiful, high-fidelity versions of the wrong thing on a regular basis. Now it's where I finish something the team already chose.
The expensive thinking is done. The argument is settled. Figma becomes craft and refinement, the place where I sweat the spacing and the motion, instead of the place I gamble a week on an unvalidated guess.
AI didn't give me taste. It gave me reps.
The temptation is to read all this as "AI designs for me." It doesn't, and I'd be wary of anyone who says it does for them. What it actually did was make the loop cheap. When trying a direction costs an afternoon instead of three days, I try ten where I used to try two. More reps, sharper instincts. You can't buy taste, but you can train it, and cheap iteration is just training in disguise.
There's a real risk buried in here too. When execution gets this cheap, it's tempting to skip the framing and just build, fast, toward a direction nobody actually chose. That's why the first step matters most. The prompt that frames the problem is the guardrail on everything the prototype lets me do.
How I work now
Frame the problem with Claude. Build a prototype, not a picture. Align the team while it's still rough. Then, and only then, open Figma.
None of this made me a better designer overnight. It moved the hard thinking to the front, where it belongs, and turned the tools into what they should have been all along: a fast way to find out whether I'm right.