A problem found in a prototype costs a designer ten minutes. The same problem found after launch costs a sprint, plus every customer it lost in the meantime.
Yet most prototypes only get tested by the people who made them — and they already know where every button goes.
What a prototype can show you
Even a clickable prototype with a few screens shows most of the problems a real page will have:
- A step where it isn't clear what to do next
- A button whose words don't match where it goes
- A price, fee or date that's missing or appears too late
- Too many questions before the person gets anything back
- A layout that falls apart on a phone-sized frame
What to ignore
A prototype isn't finished, so don't count unbuilt screens, dead links or placeholder text as faults. Judge the path that exists, and note where it stops.
How to test it
Give the prototype to someone who hasn't seen it, with one task: "sign up for the yearly plan" or "buy the blue one in medium." Watch where they pause. Write down every spot where they weren't sure what to do, and what would have made it clear.
How a Run does it
Paste your Figma or Framer prototype link, pick desktop or mobile, and say what the panel should try to do. The Run Sheet comes back in under an hour with each confusing step pinned to the screen where it happened and the change to make — before anyone builds it.
— FAQ
Questions people ask
- Can you test a Figma prototype before it's built?
- Yes. A clickable prototype shows most of the problems a real page will have — a confusing step, a missing price, a button that says one thing and does another.
- Does Prior.Run work with Framer too?
- Yes. Paste a Figma or Framer prototype link.
- Will unfinished screens count as problems?
- No. A prototype isn't finished, so dead links and unbuilt screens aren't counted as faults.
- How long does it take?
- Under an hour — usually about 45 to 55 minutes.