Fast prototyping can skip the flows and journeys that do the actual thinking. Speed doesn't remove that step, it defers it to the worst possible moment.
Speed has a way of looking like progress, and one of my senior designers put words to why that’s a trap. We were talking about how fast the team can move now, prototypes in an afternoon, whole flows generated and clickable before lunch, and she made a point I haven’t stopped turning over. A lot of what’s getting prototyped this fast is skipping the part that does the actual thinking.
Her examples were the unglamorous artifacts. The flow diagram, the user journey, the map of states and edges you build before you build the screens. The stuff that’s slower and less satisfying than a working prototype, and that AI-assisted tools make very easy to skip past, because you can go straight to something that looks real. And a prototype that looks real is persuasive in a way a half-finished journey map never is. It demos well. It feels done.
But the flow and the journey aren’t documentation you produce after you’ve figured it out. They’re how you figure it out. The act of drawing every state, every error, every path a person can take, is the thinking. Skip it and you haven’t saved that step, you’ve deferred it to the worst possible moment, which is after the prototype has convinced everyone the problem’s solved. The gaps were always there. The polish just hid them until they turned up in a real flow, in front of real edge cases, with a build already underway.
This isn’t an argument against fast prototyping, which is one of the genuinely good things about how we work now. It’s an argument for noticing what the speed is letting you skip. When a prototype comes together suspiciously quickly, the useful question is whether the thinking happened somewhere, or whether the tool just got you to something clickable before anyone did the hard part. A prototype is an answer. The flows and journeys are the work of making sure you asked the right question.
So when I review fast work now, I’ve stopped being impressed by how quickly it came together, and I ask to see the thinking underneath it. Not as a process tax. Because a prototype that skipped the journey is a confident-looking guess, and it’s a lot cheaper to find that out at review than after the edge cases do.
The teachable part
A prototype that comes together fast can be hiding the fact that the thinking never happened. The flow and the journey map aren’t artifacts you produce after figuring it out, they’re how you figure it out, and tools that get you straight to something clickable make them very easy to skip. Speed doesn’t remove that step, it defers it to after everyone already believes the problem’s solved. When work comes together suspiciously fast, ask to see the thinking underneath. Not as a tax, but because a polished guess is the most expensive kind to discover late.