Wireframes still earn their place for structure. But a real, clickable build is now often quicker than mocking one up, and it tests the thing you’re actually shipping. Where the direction is genuinely open, I build two or three rough versions and put them in front of someone rather than debating them.
The team is debating a direction in the abstract and going in circles. There's a spec everyone interprets differently. Something needs testing with real users before it's committed to a sprint. Or an idea sounds obviously right in a meeting and nobody has seen it as an actual sequence of screens.
Wireframes still earn their place for structure — deciding what goes where, and what the sequence is, without argument about colour.
But a real, clickable build is now often faster than mocking one up, and it tests the thing you're actually shipping rather than a picture of it. Where the direction is genuinely open, I build two or three rough versions and put them in front of someone rather than debating them.
The point of a prototype is to be thrown away. I build them to answer a specific question and no further — resisting the pull to polish something whose job is to settle an argument.
Then I test with people who match the actual users, and report what happened rather than what I hoped would happen.
One to three weeks depending on scope. Often the fastest way to end a long argument, so it's worth doing early rather than as a final step.
Figma or code?
Whichever answers the question faster. For interaction detail and anything data-driven, code is usually quicker now and tests more honestly.
Can we use the prototype as a starting point for the build?
Sometimes, but I'd rather you didn't assume it. Prototypes are built to answer a question, not to be maintained.
Do you run the user testing too?
Yes. Designing the tasks is most of the skill — a badly framed task produces confident, useless findings.