UX researcher, designer or prototyper: which do you need?

What does each role actually produce?

A researcher produces decisions you can defend: who the users are, what they are trying to do, where the current thing fails and what is not worth building. Their output is evidence and a recommendation, not screens. A designer produces the interface: structure, hierarchy, wording, states, and the specification an engineer builds from. A prototyper produces working models that settle questions about movement, timing and behaviour that a static design cannot answer.

Stated that way the difference is about the artefact, but the real difference is the failure mode. Teams with no researcher build well-crafted things nobody needed. Teams with no designer build things that work and are exhausting to use. Teams with no prototyper build interactions that felt right in a review and feel wrong in the hand.

Notice that only one of the three failure modes is expensive to fix late. Interface problems can be revised after launch. Interaction problems usually can too. Building the wrong thing cannot, which is why the research question deserves answering first even when the research is informal.

Where do the boundaries actually sit?

They overlap heavily in practice, and job adverts describe the middle of each role while real work happens at the edges. The distinctions worth holding on to are about the question each person is best placed to answer and about what they can be held responsible for.

Which one does a small team actually need?

A product designer who is comfortable talking to users and building clickable prototypes. That single hire covers the majority of the work for a team of up to about thirty people, and the alternative, a visual specialist plus a research contractor, tends to leave the middle of the job unowned.

The trap is hiring for the part of the work that is most visible. Visual polish is what non-designers can see and judge, so early hires skew that way, and the team ends up with a beautiful product whose structure nobody questioned. When in doubt, hire the person who asks better questions rather than the person with the more attractive portfolio.

If the budget only stretches to one and the product is genuinely novel, prioritise research or prototyping ahead of visual craft. Visual craft can be bought later in short engagements and applied to a sound structure. The reverse, applying a sound structure to a shipped product, is a rebuild.

When is it time to split the roles?

When one kind of work is consistently being skipped. The signal for research is that arguments end with whoever is most senior; the signal for prototyping is that interactions get redesigned after they are built; the signal for a visual specialist is that every screen is negotiated from scratch because there is no system.

A second signal is queueing. If designers are waiting on each other, or if engineers are idle waiting for specifications, the constraint has moved and a specialist relieves it. Splitting before the queue exists creates handovers where a single person used to just decide.

There is one exception worth naming: regulated and safety-critical products should have research separated early, because the evidence has to survive scrutiny by people who were not in the room. Somebody whose job is to be rigorous about method is worth more there than the same hours of design time.

What about the titles that do not mean anything?

Treat UX/UI designer as a description of scope rather than of skill, because almost everyone who uses it means product designer. The same goes for design technologist, creative technologist, interaction designer and design engineer, which overlap enormously and are used differently by different companies.

Since titles will not sort candidates, sort by the artefacts they produce and the decisions they have owned. Ask what they personally decided on a recent project and what evidence they used. The answer separates a researcher from a designer from a prototyper faster than any title on a CV.

Be equally careful with your own advert. A job description listing research, visual design, prototyping, design systems and front-end code will attract generalists at the mid level and be ignored by strong specialists, who read it as a team's worth of work compressed into one salary. If you genuinely need all of it, say which part is the priority.

How do you tell which one you need this week?

Write down the last three design arguments your team had and mark what would have ended each one. If the answer is evidence about users, you need research. If it is a decision about structure or wording, you need a designer. If it is seeing the thing move, you need prototyping. If it is that the built version does not match the design, you need engineering involvement rather than another designer.

Run the same exercise against the last thing you shipped that underperformed. Most teams find the same category comes up repeatedly, and that category is the hire.

The result is often uncomfortable, because the most common answer is research, and research is the hardest capability to justify to people who want to see screens. That discomfort is itself information about why the arguments keep happening.