How to hire a UX prototyper without guessing
Hire for a question, not for a headcount. The commonest failure in this role is not hiring a weak prototyper, it is hiring a good one with no defined uncertainty to resolve, at which point they produce beautiful walkthroughs that impress a steering group and change nothing. Before any sourcing, write down the two or three things you genuinely do not know about how your product should behave. If that list is empty, do not hire yet.
Should you hire a prototyper at all, or borrow one?
Most prototyping demand is lumpy, which is why the role is so often contract. The work arrives when something new is being designed and disappears once the pattern is settled, so a permanent prototyper on a mature product spends most of the year doing ordinary design work. If your roadmap has one genuinely novel interaction in it, that is a project, not a job.
The exception is products where the interface is the product and it keeps changing: creative tools, editors, anything with a canvas, hardware companions, mapping and simulation, immersive work. There the questions never stop arriving and a permanent prototyper stays busy and gets better at your specific domain, which compounds in a way contract work does not.
There is a third option people forget. Engineers who like interface work often prototype well and already know your constraints, so a fortnight of a front-end engineer's time with an explicit brief to build something disposable can beat a two-month contract. The reason it usually fails is that nobody gives them permission to write throwaway code, so they build it properly and slowly.
Where do prototypers actually come from?
Four backgrounds, and they are not interchangeable. Product designers who taught themselves motion tools are the largest group and the best fit for app and web interaction. Front-end engineers who moved towards design bring real data and real latency, which matters for dense tools. Motion and animation people bring timing instincts and often cannot wire anything to data. Game and creative-technology people handle 3D, sensors and hardware, and tend to be the only ones comfortable when the input is a camera or a controller.
Match the background to the risk. A motion specialist prototyping a data-heavy operations tool will produce something elegant that falls apart at realistic volume, and a front-end engineer prototyping a gesture-led mobile interaction will produce something functional that feels wrong in the hand. Both are competent people placed against the wrong question.
Job titles will not help you sort them. People in this work are variously called interaction designer, prototyper, design technologist, creative technologist, design engineer and simply senior product designer. Read the work, not the title.
What does a UX prototyper cost?
Expect prototyping specialists to sit above generalist product designers and roughly alongside senior front-end engineers, because the scarce part is the overlap rather than either skill alone. Rates vary far more by location and by how coded the work is than by seniority, and a coded-prototype specialist in a high-cost market is the top of the range in this discipline.
The number that matters more than the rate is the length of engagement. Prototyping questions are answered in weeks, so a six-month contract usually indicates the scope has quietly become production design work, at a prototyping rate. Contract in short blocks tied to questions and extend deliberately.
Budget for the thing nobody prices: the time your engineers spend with the prototyper. A prototype built without engineering involvement routinely proposes an interaction that the platform cannot deliver at an acceptable frame rate, and you discover this after paying for both the prototype and the failed attempt to build it.
| Engagement | Best when | Typical length | Main risk |
|---|---|---|---|
| Contract prototyper | One novel interaction, a hardware companion, a new product bet | Two to eight weeks | Scope drifts into production design and the rate stops making sense |
| Permanent prototyper | The interface is the product and keeps changing | Ongoing | Idle capacity on a mature product, so they drift into general design |
| Agency or studio | You need research, design and prototyping as one piece of work | Four to twelve weeks | Polished output, thin written findings, nothing transferable |
| Existing front-end engineer | The question is about data volume, latency or state, not motion | One to three weeks | They build it properly rather than disposably and lose the speed |
| Designer already on the team | The interaction is conventional and the risk is elsewhere | Days | You conclude prototyping does not work, when the tool was simply enough |
What does a good trial brief look like?
Pay for a short, real, bounded task and judge the reasoning rather than the artefact. A workable brief is one screen or one interaction from your actual product, a stated question, a stated time box of no more than a day, and a requirement to explain what they faked and why. Anything longer is unpaid work dressed as an interview, and the strongest candidates decline it.
The instruction to explain what they faked is doing the real work in that brief. It reveals whether they understand that a prototype is an argument with a scope, and it exposes the candidate who spent the day making it look finished rather than making it answer something.
Watch what they ask before starting. A prototyper who asks what the data actually looks like, how many items a real user has, what device this runs on and what happens on failure is reading the problem. A prototyper who asks for the brand fonts first is going to hand you a video.
What goes wrong after they start?
The prototype becomes a deliverable. Once a prototype is shown to executives it acquires an audience, and the pressure shifts from answering questions to looking finished. The fix is procedural: agree at the start that prototypes are shown with their fakery visible, ugly placeholder data included, so nobody mistakes them for a product preview.
The second failure is the orphaned finding. Prototypers commonly discover something important, say it in a meeting, and watch it evaporate because nothing wrote it down in a form engineering could use. Require a short written record per question, with numbers, as a condition of the engagement rather than a nice extra.
The third is testing with the wrong people. A prototype validated only by the team that commissioned it validates nothing, because everybody in the room already knows where things are. Five people from outside the project will tell you more in an afternoon than a month of internal review, and arranging them is your job, not the prototyper's.
How do you know the hire worked?
Decisions got made and stayed made. The honest measure of prototyping is the number of design arguments that ended, because the prototype answered them, and did not reopen three months later. If your team is still debating the same interaction after the engagement, either the wrong question was prototyped or the findings were never written down.
The second signal is what engineering estimates changed. A prototype that reveals an approach is unbuildable at acceptable performance, and causes a cheaper approach to be chosen, has paid for itself even though it produced nothing shippable. Teams routinely fail to count this because the saving is invisible.
The third is subtraction. Good prototyping usually reduces scope: an interaction turns out not to need the third state, the animation turns out to be unnecessary, the clever gesture turns out to confuse people and a plain button wins. An engagement that only ever added things is a warning sign.
Common questions
- How do I hire a UX prototyper?
- Start by writing down the two or three things you genuinely do not know about how the product should behave, because a prototyper hired without a defined uncertainty produces impressive walkthroughs that change nothing. Then source against the type of question: motion specialists for gesture and timing, front-end backgrounds for dense data and latency, creative technologists for camera, sensor or 3D input. Assess with a paid one-day task on a real screen.
- Should a UX prototyper be a contractor or a permanent hire?
- Contract suits most teams, because prototyping demand is lumpy and disappears once a pattern is settled. Permanent makes sense when the interface is the product and keeps changing, as in creative tools, editors, mapping, hardware companions and immersive work, where questions arrive continuously and domain knowledge compounds. A permanent prototyper on a mature product usually ends up doing ordinary design work.
- What should I ask a UX prototyper in an interview?
- Ask how they would fake the backend for a given screen, what they threw away on a recent project and why, and what they measured rather than what people said they liked. Ask what they would refuse to prototype. Strong candidates ask their own questions first, about real data volume, target device and failure behaviour, before discussing anything visual.
- How much does a UX prototyper cost?
- Rates typically sit above generalist product designers and near senior front-end engineers, because the scarce part is the combination rather than either skill alone. Location and how much of the work is coded move the number more than seniority does. The larger hidden cost is engineering time spent alongside the prototyper, without which prototypes routinely propose interactions the platform cannot deliver at acceptable performance.
- Is a paid design task fair when hiring a prototyper?
- Paid, short and bounded is fair and informative. One screen or one interaction from a real product, a stated question, a time box of no more than a day, and a requirement to explain what was faked and why. Multi-day unpaid exercises are not an assessment, they are unpaid work, and the strongest candidates decline them, so the exercise selects against the people you want.
- How do you measure whether a prototyping engagement worked?
- Count the design arguments that ended and stayed ended, and the engineering estimates that changed because a cheaper approach was chosen. A prototype that proved an approach unbuildable at acceptable performance has paid for itself while producing nothing shippable. Watch also for subtraction: good prototyping usually removes states, animations and clever gestures rather than adding them.
