How to do prototype-first design without shipping AI slop.

For twenty years the design process started the same way on most teams. Research first, in the form of user interviews, persona work, and journey maps. Then wireframes, then prototype, then test. Prototypes were expensive in those days, often taking days to build properly, which meant you only made one when you were already confident about what to make.

Then AI changed the cost of prototypes. Twenty minutes, not twenty days. And the sequence flipped on its own. On most teams I work with these days, the prototype shows up before the user research has even kicked off, and sometimes before the brief has been finalised.

That isn't a craft failure on anyone's part; it's the new economics doing their work. The problem is that prototype-first design without a method around it produces what most teams in 2026 are quietly shipping: AI-generated UI that looks polished, references nothing in particular, and solves no real user problem. People in the field have started calling this slop. It isn't slop because AI is bad at design. It's slop because nobody has designed the workflow that the AI sits inside.

The rest of this piece is about a different way to think about prototype-first design. Not as the absence of process, but as a different process with the research repositioned. I've started calling the method prototype-as-probe, and the central idea is that the prototype is the question you're asking the user rather than the answer you're giving them.

What I mean by "prototype-as-probe."

Prototype-as-probe is a design method in which you treat the first prototype as your research instrument rather than as your design destination. The prototype's job isn't to ship; its job is to elicit a real reaction from a real user that tells you what to build next.

The classic design thinking phases are empathise, define, ideate, prototype, test. The order was never sacred to anyone who had thought about it carefully, and design has been talked about as non-linear for a long time. But the classic order was at least useful in an era when prototypes were the most expensive thing you made on a project. You wanted to be sure of the brief before you spent two days on UI work that might end up going nowhere.

Now the most expensive thing in the room is your team's attention. Prototypes are cheap to make, and the discussions around them are not. So the prototype migrates earlier in the process, before the research and sometimes before the brief, in order to give the team something concrete to react to. The phases haven't disappeared so much as they've reordered themselves around the new economics. The probe is the new opening move.

Why the old sequence broke.

Three forces, all stacking, all rational on their own terms.

The first is that the cost of prototypes collapsed. What used to be a high-effort artefact has become a five-minute exercise with Claude or v0 or Figma's AI features. When the cost of any one step drops to near-zero, that step migrates to wherever it's most useful in the process, and for prototypes that turns out to be earlier, because the team can't talk productively about something that doesn't yet exist on a screen somewhere.

The second is that small teams started defaulting to it. Mature product teams with established research functions still run the old sequence and get real value from it. Smaller teams (startups, two-person product squads, designers without dedicated researchers) never had the bandwidth for upfront discovery in the first place, and they've quietly been doing prototype-first design for years without calling it that. AI just made the practice more visible and more dangerous, because the slop it produces now is more polished than the slop the same teams used to ship before.

The third is that the new tooling implies the new order. When your design tool can spin up five UI variants from a one-line prompt, the friction is no longer "what should we build" but "how do we choose," and the whole stack pulls you toward starting with a thing rather than starting with a brief.

The trap is treating the new sequence as the old sequence with the research deleted. That isn't prototype-first design. That's prototype-only design, and it's how you ship slop.

The trap. Prototype-first without method.

You've seen this happen, probably more than once. The PM has an idea. AI generates twelve mocks in twenty minutes. The team picks the prettiest one. The designer spends two weeks polishing the pixels. Engineering builds it. Six weeks later the feature ships and nobody uses it, because it solved a problem the team had imagined rather than one users actually had.

That isn't a research failure. The team did "research" in their own definition of the word, in the sense that they had opinions, discussed alternatives, and asked their cousin what she thought. It's a method failure. The prototype was treated as a destination rather than as a probe. By the time anyone tested the design with real users, the cost of changing direction had already accumulated past the point of honest revision.

Slop, in the AI-design sense of the word, isn't really about the AI's output quality. The mocks are usually fine. Slop is what happens when the workflow around the AI-generated artefact has no real user contact at any stage. The prototype looks like design. The thing that isn't actually happening is design.

The new sequence. What comes before, what comes after.

Prototype-first doesn't mean prototype only. It means the prototype shows up earlier in the loop, and the rest of the work (research, definition, iteration) wraps around it instead of preceding it linearly.

The minimum that has to come before the prototype is short and concrete.

A problem statement, written down in one paragraph. Who the user is, what they're stuck on, and what success would look like for them. Not a research report. A working hypothesis the team aligns on. The problem statement is the spec the prototype is trying to express, and without it every variant the AI generates is solving a slightly different problem.

A success metric, even if it's rough. "We'll know this works if 30% of new users complete X within Y." Pre-committing to a metric stops the team from rationalising whatever the prototype eventually turns into.

That's the entire upfront list. Two artefacts, both written, both under a page. Anything more upfront is the old sequence sneaking back in through a different door.

What comes after the prototype is where the real work happens.

User observation. Five users. Structured task. Recorded response. Done within a week of generating the first prototype. This is the research that the old sequence put first; in the new sequence it sits second, and it tends to be higher-signal than upfront research because users are reacting to a real artefact instead of imagining a hypothetical one.

Iteration that runs against the signal you saw, not against team opinions and not against more variants. The next prototype is informed by what actually happened in front of the users, not by what got debated afterward in Slack.

Engineering involvement, early. Pull an engineer into the prototype loop before the prototype is "done" in any traditional sense. Real implementation constraints are a form of research, and they're cheaper to learn while the prototype is still rough enough to revise easily.

This is roughly the loop I ran on Simplero. Onboarding redesign, three sprints to MVP. The first prototype wasn't grounded in deep research; we had a problem statement (cold dashboard, day-three churn) and a hypothesis (a single first-win as the activation lever). I prototyped a guided setup, watched seven new users move through it, and learned that two of the seven first-win moments I'd designed for weren't the ones that actually felt like wins to people. I iterated against what I'd seen, not against what the team thought, and 7-day activation lifted by 38%.

That wasn't waterfall. It also wasn't a vibes-based prototype-only sprint. It was prototype-as-probe with the research repositioned to where it actually does the most work.

Five moves that make prototype-first work.

The method, condensed.

Lead with a written problem statement. One paragraph. Who, what, why now. Pin it to the top of the Figma file, and review every variant against it.

Prototype to ask, not to answer. The first prototype is a question the team is putting to users. Design it to elicit a strong reaction, opinionated enough to be wrong in interesting ways. Vague prototypes produce vague feedback.

Put it in front of real users fast. Five users is enough for the first round, within a week of the prototype existing. Structured task, recorded session, no leading questions. The research that should have come first now comes second, and it's better grounded for it.

Iterate against the signal, not against the team. What the users did and didn't do is the brief for the next round. Internal opinions are a separate input: useful, secondary, often noisy. The trap is letting team review become the loop.

Pull engineering in before the prototype is "done." Implementation constraints are research. The earliest version of the build that touches real infrastructure usually surfaces problems that even the prettiest mock will hide.

One more counterargument, resolved.

The argument I take seriously is this. Isn't this just doing UX badly? You skipped the research. You shipped on hypotheses. You called user testing "research" and gave it five users and called it a day.

Three responses.

First, the research isn't being skipped, it's being repositioned. The total amount of contact with real users is often higher in a prototype-as-probe loop than in a research-first loop, because the artefact gets in front of users earlier and more often. The shape of the contact is different. The volume isn't smaller.

Second, five users is a defensible number for early-loop research. Nielsen Norman published the math on this in the nineties: five users surface around 80% of usability issues for any single round. The trap is only doing five users, ever. The fix is doing five users every round, which prototype-first actually makes possible because the rounds are faster.

Third, the alternative I'm comparing this to isn't research-first design done well; it's research-first design done poorly. A discovery phase that becomes a research budget no one defends, a deck that nobody re-reads, and a brief that's already stale by the time the prototype work starts. When that's the realistic alternative (and on small teams it usually is), prototype-as-probe with five-user rounds and a written problem statement is a better method, not a degraded one.

The standard moves up. The shape of the work changes. The discipline is different, not less.