Design & Creative - Design & UX
UX Prototyper & Researcher
IC / Practitioner
Independently auditedMakes the product understandable, usable, and worth returning to. Owns a defined area of the function and the outcomes it produces.
Audited package
Built, independently audited role package. Everything on this page is written for this seat.
Your Stack (Swappable)
This role works against whatever tools you already run. We list the tool categories the role operates in, never a named vendor, so you are never asked to replace a system that works.
- Design & Prototyping
- Analytics & BI
- QA & Testing
- Recruiting & ATS
- Synthesis
Deliverables
- Designs and prototypes
- Design system components
- Research synthesis
- Handoff specifications
Responsibilities
- Turn an evaluative research question into a build plan for the prototype that will answer it - deciding the fidelity, what must be real, what can be faked, and the tool or code to build it in
- Build the interactive prototype as a test instrument: real flows and states, motion and transitions where they carry the question, realistic or piped-in data, and code-level or advanced-tool fidelity when a clickthrough cannot simulate the behavior under study
- Design the evaluative study that runs on the prototype - neutral task set, success criteria, sample, and what a pass or fail actually proves given the fidelity built
- Recruit or partner on the recruit, moderate the sessions, and observe what users do with the working artifact rather than what they say about a picture of it
- Iterate the prototype between sessions and rounds - because the same seat builds and tests, fix the instrument and re-test the change same-day rather than filing it for later
- Synthesize the sessions into findings traceable to what happened on the prototype, separating a build artifact (a bug, a stub) from a genuine design failure, and drive the finding into the design and the decision
- Simulate real conditions that change behavior - latency, error and edge states, real content, hardware or sensor input, novel or emerging interactions - so the signal is valid for the claim being made
- Specify and hand off cleanly: take a "what needs testing" from a researcher or designer and return a prototype and a read; hand a heavy generative or large-sample program to a pure researcher
The essence of this seat
The UX Prototyper & Researcher is the seat that answers a research question by building the thing that produces the answer: a working, interactive prototype - real interaction, real motion, real or realistic data, sometimes real code - and then running the study on it.
Signature move
Set fidelity to the question before you touch a tool. The first move is to name the lowest fidelity that still makes the finding valid, then split what must be real (the interaction, motion, data, or latency the question lives in) from what can be stubbed, hardcoded, or Wizard-of-Oz'd - realism spent past that biases the read
What good looks like
refuses to build before pinning the question the test must answer, sets fidelity to that question rather than defaulting high, makes real only the thing under study and fakes the rest, and agrees the build plan and what a result will prove before building
Decision rights
- - the prototype build and its fidelity level, what is made real versus faked, the tool or code used to build the instrument, the evaluative study design that runs on it (task set, success criteria, how it is moderated), the synthesis and the findings you publish, and the call on whether the built fidelity is faithful enough to support the conclusion at all
Working vocabulary
What this role does
The UX Prototyper & Researcher is the seat that answers a research question by building the thing that produces the answer: a working, interactive prototype - real interaction, real motion, real or realistic data, sometimes real code - and then running the study on it. This is a hybrid individual-contributor role, part research and part construction, reporting to a Design / Research Manager. Its craft is the marriage of the two: not "a researcher who also clicks around Figma," but someone who can build a prototype faithful enough that what a user does with it is real signal, and design and run the evaluative study that reads that signal cleanly. Core ownership is the prototype-as-instrument, the study that runs on it, and the synthesized finding fed back to the design and the decision. It is not the UX Researcher, who owns method rigor and insight across all research and specifies what needs testing (this seat adds the build of the interactive artifact under test and runs the study on it, and hands a heavy generative program back to a pure researcher). It is not the Product Designer or UI Designer, who build to ship (this seat builds throwaway test instruments to learn, and cedes the shipping design). It is not a Design Technologist / Front-End Engineer, who writes production code (this seat writes prototype code to answer a question, then throws it away). And it is not the Product Manager, who owns the decision (this seat produces the evidence and advises). What separates great from average is building the least prototype that produces a valid answer, then reading it honestly - fidelity set to the question rather than to the tool, realism spent only where the answer lives, and the discipline to treat a failed task as the finding it came for rather than a bug in one's own work.
Best-fit customer
product teams that need consistent design quality as contributor count grows
Need more than one role?
Buying the whole team or the complete department lowers your effective cost per role at every tier of the ladder.