Rapid Prototyping Plan Template

Five to seven participants will surface approximately 80% of usability issues, according to Nielsen Norman Group research. This is enough for prototype testing, where you are looking for qualitative patterns rather than statistical significance. If you are running a quantitative A/B test on a live product, you need hundreds or thousands. But for prototype feedback, 5-7 is sufficient.

Either works, but the facilitator should not be the person who designed the prototype. Designers who test their own work tend to unconsciously guide users toward success or explain things instead of observing confusion. If the designer facilitates, have them practice the script beforehand and commit to not explaining anything until the follow-up questions section.

That is the best possible outcome from a prototype test. You just saved weeks of engineering time by discovering the problem early. Capture the specific things they disliked, identify whether the issue is conceptual (wrong approach entirely) or executional (right approach, wrong implementation), and iterate accordingly. A rejected prototype at the testing stage costs days. A rejected feature in production costs months.

Prepare a standard response: "That part is not built yet. What would you expect to happen if you tapped that?" This turns a dead-end into a learning opportunity. Note what they tried to interact with, because it tells you what they expected to find. If multiple users try to tap the same non-prototyped element, it belongs in the next iteration.

Use a coded prototype when your key question involves real data, performance, or complex interactions that Figma cannot simulate. Examples: "Does the search algorithm return useful results?", "Does the animation feel smooth on a real device?", "Can users complete this flow with their actual data?" For most concept and flow validation, a Figma prototype is sufficient and much faster to build. ---