A prototype is a way to learn. Its detail should match the question you need to answer. If you are exploring whether people understand the steps in a booking flow, rough screens may be enough. If you are evaluating keyboard behavior, you need an interactive implementation.
Name the risk
Choose one assumption: people understand the available plans, can find the right setting, or know whether their booking is confirmed. Write down what you would expect to see if the design works and what would suggest a problem.
Write a realistic task
Give participants a goal without naming the controls. “You need an appointment next Tuesday after work” is more useful than “Click the calendar and select Tuesday.” Use plausible content, but do not request real payment details or unnecessary personal information.
Watch before explaining
Ask the participant to think aloud if it fits the study. Observe hesitation, backtracking, misunderstandings, and recovery. If they get stuck, ask what they expected. Explaining the interface too early hides the very issue you wanted to find.
Capture a decision-ready result
- Observation: what happened and in which task.
- Impact: whether it blocked completion, caused an error, or created uncertainty.
- Evidence: the note or recording reference.
- Next action: what to change, investigate, or keep.
Use the first sessions to find problems and revise. Recruit relevant participants and include different access needs. Do not turn a handful of sessions into a claim about the percentage of all users who will succeed.
Try it yourself
Pick one existing flow. Write a neutral task, define successful completion, and list three behaviors you will observe. Test with someone who did not design it.