By the end of the lesson, you can adapt the level of detail of the prototype to the question being examined, and you can write a scenario and a task that make the design testable without telling the solution in advance.
Why do we build a prototype?
The wireframe is understood by the designer, but the user does not "use" it: they cannot click it and do not see what happens. A prototype fills this gap. If the user goes through a task on a clickable model, we see where they got lost, what they misunderstood, and where the design proved good. All of this before a single line of code has been written, so we can modify cheaply and quickly.
A prototype answers a question
A prototype is a model of connected screens that simulates a situation of use. It does not prove the technical operation, but whether the user understands the interface and can go through the task.
Prototype fidelity is the visual, content, and interaction detail of the model. You can think in three dimensions:
Dimension
Low
High
Visual
Gray blocks
Final style, images
Content
Placeholder text
Real texts and data
Interaction
Only clicking between screens
States, transitions, form handling
The three dimensions can be set independently. For example, a test that examines the comprehension of registration conditions can be visually low but high in content fidelity (with real texts).
Which fidelity when?
Question
Enough fidelity
Is the order of the screens good?
Low-fi, a clickable sketch
Do they find the option to cancel?
Low-fi or mid-fi, with real labels
Do they understand the text of the error message?
With real text, any visual fidelity
Is the appearance attractive, does the user trust it?
High-fi
The limitations of the prototype
Document the limitations of the prototype. If there is no real search, payment, or notification, you do not need to present this to the tester as a technical detail, but you must know what the result can and cannot refer to. The list of limitations is part of the prototype's documentation, and it will appear in chapter 9 as well when interpreting results.
Scenario and task
A scenario is a frame describing the situation and goal of a user task. A scenario gives a situation: who you are, what happened, what the goal is and what constraint matters. The task is the concrete request to the participant arising from it. The task does not instruct the participant toward the solution.
Compare:
Weak
Better
"Open the filter and choose Friday."
"On Friday evening you want to go out with four friends. See whether you can find a free, English-language program."
"Find the cancel button."
"Tomorrow you cannot go to the event you registered for. See what you can do."
A good scenario:
is plausible, belongs to the target user's situation;
starts with a goal, not with a control;
contains as much background information as is needed for the decision, but not more;
does not name the elements of the interface.
Fix the starting point and the success criterion in advance (as in chapter 1). The success can be a choice, a correctly interpreted condition, or a completed process. If the tester chooses another, reasonable path, do not treat it as an error just because they did not follow the planned route. We learn detailed test-task writing and moderation in chapter 8; here we clarify the basics needed to try out the prototype.
Building a prototype: steps
flowchart TD
A["Question to examine"] --> B["Scenario and task"]
B --> C["Choosing the necessary detail"]
C --> D["Building the prototype"]
D --> E["Trying out and observing"]
E -->|"new question"| A
The cycle is not linear: the observation raises new questions, which need a new prototype or a new detail.
Worked example: trying out the filters of Mai program
The designer of Mai program wants to examine whether the filters are understandable. A real database is not necessary: a few carefully selected events and a state where filtering visibly modifies the list are enough. The test task: "For tonight you are looking for a free, English-language program that does not require advance registration." The subject of observation is what words the participant uses, what data they expect on the card, and whether they can decide that the result fits.
The known limitation of the prototype: the filters work only for three predefined combinations. The designer notes this, so they do not consider it an error of the result if the participant tries another filter.
Common misconceptions
Claim
Clarification
"High fidelity is always better."
Only if it is necessary for the examined question; otherwise it is expensive and misleadingly looks final.
"The fault of the prototype is the tester's fault."
The test shows exactly where the model or the task is not clear enough.
"A prototype is a scaled-down version of the finished product."
A prototype is a tool for a question, not a product.
In brief
A prototype is a model of connected screens that answers a question.
The three dimensions of fidelity (visual, content, interaction) can be set independently; adapt them to the question.
The scenario gives a situation and goal, the task is a request to the participant; neither reveals the solution.
Note the limitations of the prototype, so that the result can be interpreted correctly.
Review questions
For which question is your low-fi prototype enough, and for which would more realistic content be needed?
Does your task instruction reveal the name of the solution?
Prototype fidelity and scenarios
Objectives
By the end of the lesson, you can adapt the level of detail of the prototype to the question being examined, and you can write a scenario and a task that make the design testable without telling the solution in advance.
Why do we build a prototype?
The wireframe is understood by the designer, but the user does not "use" it: they cannot click it and do not see what happens. A prototype fills this gap. If the user goes through a task on a clickable model, we see where they got lost, what they misunderstood, and where the design proved good. All of this before a single line of code has been written, so we can modify cheaply and quickly.
A prototype answers a question
A prototype is a model of connected screens that simulates a situation of use. It does not prove the technical operation, but whether the user understands the interface and can go through the task.
Prototype fidelity is the visual, content, and interaction detail of the model. You can think in three dimensions:
The three dimensions can be set independently. For example, a test that examines the comprehension of registration conditions can be visually low but high in content fidelity (with real texts).
Which fidelity when?
The limitations of the prototype
Document the limitations of the prototype. If there is no real search, payment, or notification, you do not need to present this to the tester as a technical detail, but you must know what the result can and cannot refer to. The list of limitations is part of the prototype's documentation, and it will appear in chapter 9 as well when interpreting results.
Scenario and task
A scenario is a frame describing the situation and goal of a user task. A scenario gives a situation: who you are, what happened, what the goal is and what constraint matters. The task is the concrete request to the participant arising from it. The task does not instruct the participant toward the solution.
Compare:
A good scenario:
Fix the starting point and the success criterion in advance (as in chapter 1). The success can be a choice, a correctly interpreted condition, or a completed process. If the tester chooses another, reasonable path, do not treat it as an error just because they did not follow the planned route. We learn detailed test-task writing and moderation in chapter 8; here we clarify the basics needed to try out the prototype.
Building a prototype: steps
flowchart TD A["Question to examine"] --> B["Scenario and task"] B --> C["Choosing the necessary detail"] C --> D["Building the prototype"] D --> E["Trying out and observing"] E -->|"new question"| AThe cycle is not linear: the observation raises new questions, which need a new prototype or a new detail.
Worked example: trying out the filters of Mai program
The designer of Mai program wants to examine whether the filters are understandable. A real database is not necessary: a few carefully selected events and a state where filtering visibly modifies the list are enough. The test task: "For tonight you are looking for a free, English-language program that does not require advance registration." The subject of observation is what words the participant uses, what data they expect on the card, and whether they can decide that the result fits.
The known limitation of the prototype: the filters work only for three predefined combinations. The designer notes this, so they do not consider it an error of the result if the participant tries another filter.
Common misconceptions
In brief
Review questions