Oct 30, 2026 · 7 min read

My workflow has been updated!

Product design is changing fast, and the workflow is changing with it. Here’s how my process went from a straight line to a loop, what I’m seeing across the industry, and what I think still matters most.

The old flow was a straight line

For most of my career, every project moved through the same five steps:

research → wireframes → mockups → handoff → QA

It looked tidy on a slide. Each step had an owner and a deliverable, and each one finished before the next one started. Research became a deck. The deck became wireframes. Wireframes became polished mockups, and the mockups went over to engineering with a spec attached.

The problem was timing. Real users usually saw the product for the first time at the very end, when the big decisions were already locked in and changing them was expensive. Anything that got lost in the handoff came back in QA as a bug, a missing state or a quiet “that’s not what I meant”.

The new flow is a loop

Now the work goes around in circles, on purpose:

frame the problem → explore wide with AI → narrow with judgment → prototype in code → test with real users → repeat

Line drawing: the old process as five steps in a straight line, research, wireframes, mockups, handoff and QA. Below it, the new process as a loop: frame the problem, explore wide with AI, narrow with judgment, prototype in code, test with real users, and repeat. — The old flow ends at QA. The new one keeps going.

Frame the problem. Before I open any tool, I write down who this is for, what they’re trying to get done and what success looks like for the business. A clear frame keeps every step after it honest.
Explore wide with AI. This is where AI earns its place. I can look at ten directions in the time one used to take: different layouts, flows, copy, even rough data models. Going wide early stops me from falling for the first idea.
Narrow with judgment. Most of those directions are wrong, and that’s fine. I cut them down by asking which ones actually fit the user, the goal and the constraints. This step is still slow and human, and it should be.
Prototype in code. The direction that survives becomes a real, clickable prototype with real states, edge cases and believable data, not a static picture of one happy path.
Test with real users. People use the thing, and I watch where they hesitate, misread or give up.
Repeat. What I learn goes straight back into the frame, and the loop starts again, a little sharper each time.

The difference isn’t only speed. In the line, feedback arrived once, at the end. In the loop, it arrives every few days, while it can still change the outcome.

What I’m seeing across the industry

This isn’t just my own shift. In job posts, in conversations with teams and in how products get built, the same four patterns keep showing up.

Design and engineering are blurring

More teams want designers who can prototype and ship, not just hand off. The wall between “design is done” and “engineering starts” is where a lot of quality used to leak out. Specs go over, questions come back, and some detail gets lost every round.

When a designer can build a working version, the conversation with engineers changes. We talk about real behaviour instead of annotated screenshots. Engineers come in earlier, and the prototype becomes something everyone can click, not a document someone has to interpret. Designers aren’t replacing engineers. The overlap between the two roles is simply where a lot of the best work happens now.

Line drawing: on the left, design and engineering as two separate circles with a wall between them and a spec thrown over it. On the right, the two circles overlap, and the shaded overlap is labelled prototype and ship. — Less throwing specs over the wall, more building in the overlap.

AI is compressing the making phase

Generating screens is cheap now. One prompt can give you a dozen layouts in a minute. That sounds like it makes design easier, but really it moves the hard part somewhere else.

Deciding which ones matter is the hard part. Every generated option still has to pass the same filters. Does it help the user do what they came to do? Does it serve the business goal? What are we trading away to get it? AI can’t answer those for you, because the answers live in context it doesn’t have. The making got faster. The judgment got more important.

Line drawing: a grid of many generated screens passes through a funnel with three filters, users, business goals and trade-offs, leaving the one screen that matters, marked with a check. — Making got cheap. Deciding which screens matter didn’t.

Product thinking is the differentiator

Understanding business goals, users and trade-offs matters more than pixel polish. Polish still counts, because a product that feels careless loses trust. But polish is the part people see, and it sits on top of a lot of decisions they never see.

Who exactly is this for? Which problem is worth solving first? What moves the numbers for the business? What are we choosing not to build, and why? Designers who can answer those questions, and explain their reasoning to a PM, an engineer or a founder, end up shaping the product instead of decorating it.

Line drawing: pixel polish sits above a dashed line as what people see. Below the line, three nested arcs hold it up: trade-offs, business goals, and users as the widest. — Polish is what people notice. The layers underneath are what make it work.

Speed is expected

Teams want validated ideas in days, not weeks. A six-week cycle that only meets its first real user at the end is too slow when another team can test three ideas in the same week.

Speed doesn’t mean rushing or skipping research. It means keeping the loops small: put a rough version in front of people early, learn, adjust and test again. By the time real engineering time goes in, the idea has already been proven with real people.

Line drawing: two six-week timelines. Above, one big arc from zero to six weeks, labelled this is slow. Below, twelve small arcs over the same six weeks, labelled this is fast. — Same six weeks. Feedback in the first one, not the last.

How this looks in my own work

AI sits inside every step of my loop now, but it never makes the call. Here’s what a normal week looks like.

Claude to think. I use it to pressure-test the problem, sum up research notes and draft the first round of copy. It’s a sparring partner, not the decider.
Figma to design. Flows, key screens, components and tokens still start here. This is where I decide what good looks like.
Claude Code to build. I turn the direction into a working prototype in real code, with every state, edge case and believable sample data. The PSTAKE, COMDEX and CAPTL prototypes on this site were built this way.
GitHub to ship. Every prototype is versioned and lives at a real link, so people click through it instead of reading a deck.

Line drawing: four steps in a row. Think with Claude, design with Figma, build with Claude Code and ship with GitHub, with a bracket underneath reading: me, in every step, framing, judgment and taste. — The tools do the heavy lifting. The framing, judgment and taste stay with me.

What stays the same

The tools will keep changing. Whatever I use today will look different in a year, and that’s fine. The designers who thrive will be the ones who stay close to users, think in systems, and keep learning.

Stay close to users. Talk to them, watch them and test with them often. Everything else depends on it.
Think in systems. Design the rules, components and flows behind a screen, not just the screen.
Keep learning. New tools will keep arriving. Curiosity is what keeps the loop moving.

That’s what I’m holding on to.