What does a UX prototyper do, and do you need one?
Most teams who go looking for a UX prototyper do not need a separate person. If your product is forms, lists, tables and settings, a designer working in Figma will answer every question you have, and adding a prototyping specialist adds a handover rather than a capability. The role earns its place when the risk in your product lives in movement, timing, state or input, because none of those can be evaluated from a still frame.
What does a UX prototyper actually build?
Something you can operate. A prototyper produces a working model of an interface that responds to input the way the real thing would, so that a specific question can be answered before engineering commits to an approach. The output is not a picture of a product, it is a disposable version of one.
The important word is disposable. A prototype is built to be wrong cheaply. It fakes the data, ignores error states that are not under test, and hard-codes anything the question does not depend on. A prototyper who builds carefully, handles every edge case and writes tests has misunderstood the assignment and spent your money on production code that will be rewritten anyway.
This is also why prototyping is a distinct skill rather than junior engineering. Knowing what to fake is most of the job. A prototype that takes three weeks has usually answered its question two weeks too late to change anything.
When do you not need a prototyper?
When the interaction is conventional and the risk is elsewhere. Sign-up flows, dashboards, admin panels, checkout, settings, search results and content sites are all solved patterns. Their difficulty is in information architecture, copy and prioritisation, which is a designer's work, and a clickable Figma flow is a sufficient prototype for all of it.
You also do not need one when the real uncertainty is whether anyone wants the thing. No prototype answers a demand question. Teams commonly spend a month making an interface feel right for a feature that nobody later uses, and the prototype was not the wrong tool so much as the wrong question.
A blunt test: write down the question you want answered. If you can answer it by drawing the screen and asking someone what they would tap, you do not need a prototyper. If the answer depends on what happens between two screens, on how fast something responds, or on what the user's hands or camera are doing, you probably do.
Which questions genuinely need a working prototype?
Five kinds, and they share a property: the answer is in time rather than in layout. Does this gesture feel controllable. Does the delay before the result appears read as broken or as considered. Can someone hold the whole state of this tool in their head while they use it. Does the transition explain where they just went. Does this work when the person is standing up, wearing gloves or holding a scanner.
Data-heavy tools deserve special mention because they mislead people. A dense table looks fine in a mock-up with twelve invented rows and becomes unusable with four thousand real ones, and no amount of visual design review catches that. Prototyping such a tool means wiring it to a realistic volume of realistic data, which is often the only honest way to see the design.
Novel input is the clearest case of all. Anything involving a camera, a sensor, voice, a game controller, a headset or a bespoke device cannot be evaluated on a laptop screen. If your product has any of these, prototyping is not a phase, it is how the design gets made.
Which prototyping tools answer which questions?
Tool choice follows the question, and a prototyper who reaches for the same tool every time is telling you something. The practical distinction is not which tool is best but which class of question each one can and cannot settle.
| Approach | Answers well | Cannot answer | Typical build time |
|---|---|---|---|
| Clickable Figma flow | Navigation, wording, whether people find the thing | Anything about speed, real data volume or gesture feel | Hours |
| Motion tool such as ProtoPie or Framer | Transitions, timing, gesture response, micro-interaction | Whether it survives contact with a real backend | Days |
| Coded web prototype | Dense data, complex state, keyboard use, real latency | Native platform behaviour and device permissions | Days to weeks |
| Coded native or on-device build | Camera, sensors, offline behaviour, performance on real hardware | Little, but it costs the most and dates fastest | Weeks |
| Wizard of Oz, a human faking the system | Whether an automated feature would be wanted at all | Anything about the automation itself | Hours to days |
What should a prototyper hand over?
Three things, and the prototype is the least important of them. The findings come first: what was tried, what was rejected and why, written down in a form an engineer can read in ten minutes. Then a specification of the interactions that survived, with actual numbers for durations, thresholds and easing rather than adjectives. Then the prototype itself, clearly labelled as reference and not as a starting codebase.
Insist on the numbers. The difference between a prototyper and a designer with a motion plug-in shows up here: one hands over a video and says it should feel snappy, the other hands over durations, the distance at which a swipe commits, and what happens when the gesture is released halfway.
Be explicit in the contract about whether prototype code may be reused. Sometimes it should be, particularly for a small web feature where the prototype was written in your production framework. Usually it should not, and letting prototype code drift into the product is a reliable way to inherit code with no error handling and no tests in a part of the system nobody wants to touch.
How do you tell a prototyper from a designer who prototypes?
Ask how they would fake the backend. A designer who prototypes will describe screens and hotspots. A prototyper will talk about stubbing responses, injecting artificial latency to see whether the loading state is honest, and generating enough plausible records to stress the layout. That single question separates the two more reliably than any portfolio.
Ask what they threw away. Someone who prototypes seriously will have discarded whole directions and will remember why, usually with an unglamorous reason such as it needed a second hand to operate. Someone who only builds polished walkthroughs has nothing to discard because everything they made was already the answer.
Ask what they measured. Good prototyping produces observations that are hard to argue with: seven of eight people tried to drag rather than tap, nobody noticed the confirmation, everyone waited for the animation to finish before scrolling. Preference is not the point. Behaviour is.
Common questions
- What is a UX prototyper?
- A specialist who builds working, disposable models of an interface so that questions about movement, timing, state and input can be answered before engineering commits. The output responds to input the way the real product would, but fakes data and ignores anything the question under test does not depend on. Knowing what to fake, and therefore how to get an answer in days rather than weeks, is most of the skill.
- Do I need a UX prototyper or just a UX designer?
- A designer is enough when the product is built from solved patterns such as forms, dashboards, checkout and settings, because the difficulty there is information architecture and wording rather than interaction. A prototyper is worth hiring when the answer depends on what happens between screens, on response speed, on realistic data volume, or on camera, sensor, voice or device input, none of which can be judged from a static frame.
- How long should a prototype take to build?
- Long enough to answer one question and no longer. A clickable flow that tests navigation and wording takes hours. A motion prototype that settles gesture and timing takes days. A coded prototype that reveals how a dense tool behaves with realistic data can take a week or two. A prototype that has run for a month has usually stopped being a prototype and started being an unsupported product.
- Should prototype code be reused in production?
- Usually not, and the decision belongs in the contract rather than in a later argument. Prototype code deliberately omits error handling, accessibility, tests and edge cases, so promoting it means inheriting a fragile area of the system that looks finished. The exception is a small web feature prototyped directly in the production framework, where the saving is real and the omissions are visible and few.
- What should a UX prototyper deliver at the end of an engagement?
- Written findings covering what was tried and rejected and why, an interaction specification with real numbers for durations, thresholds and easing rather than adjectives, and the prototype itself labelled as reference material. The numbers are the part teams most often forget to ask for, and their absence is what forces engineers to reinvent the interaction from a video.
