Digital products ·
Test a prototype with questions that are still inexpensive to answer
Prototype testing is not a ceremony for approving a finished idea. It reveals whether a person understands the task, finds the next step and completes the journey before mistakes become part of production development.
Begin with the risk
Asking someone to “look at the interface” usually produces opinions about colour, copy and taste. A useful test begins with uncertainty: will a client understand the difference between formats, can an employee correct the data, will a user notice a change of status?
A round only needs a small set of connected research questions. They determine the prototype fragment, participants and observations. If a question cannot change a future team decision, it does not belong in the session.
Fidelity follows the question
A paper sketch can test the order of steps and section labels. An interactive mock-up reveals navigation and comprehension. A coded prototype becomes useful when real inputs, device behaviour, loading or complex states matter.
The more finished a prototype looks, the more likely participants are to discuss polish. Build only what the research question requires. A rapid prototype is valuable because the team can change or discard an idea without defending a large development investment.
Participants need to recognise the situation
Colleagues know the internal language and understand the concept in advance. Future users approach it differently. Recruit people who resemble them through the task, context and constraints. The important distinction may be frequency, access level or device rather than job title.
A small varied group can reveal more than a convenient, uniform one. Include different levels of experience and digital confidence and, for significant journeys, people who use assistive technology. This does not produce a statistical forecast, but it exposes different ways of meeting the same design.
A task describes a goal, not the route
“Click the Continue button” tests a person’s ability to follow instructions. A neutral task describes the situation and outcome: “You have chosen a service and want to understand when the work will begin.” The participant decides where to go and what to trust.
Keep scenarios believable and avoid naming the controls being tested. Run a pilot with a colleague before the sessions to remove accidental dead ends and confirm that the prototype supports the complete task.
Observe rather than teach
Begin by explaining that the product is being tested, not the participant. Ask people to think aloud, but do not explain the interface or rescue them at the first pause. Record every intervention as part of the result: the journey was not completed independently.
Notes should separate action, speech, pause and context from interpretation. “Returned to the previous screen three times” is more useful than “navigation is confusing” because the team can investigate the cause and compare the behaviour after a change.
Group findings by pattern and consequence
After the sessions, gather observations around moments in the journey. One reaction may be incidental or may expose a rare but critical risk. Repetition matters, but consequence matters too: an unclear heading and an incorrect payment deserve different priorities.
For each problem, record the observation, possible cause, affected journey and the next idea to test. Research then remains a connection between evidence and hypothesis rather than becoming a vote on fixes.
The next version answers the question
Not every observation needs an immediate response. Change the issues that prevent the key journey or distort a person’s decision, then test again. A new design can remove one barrier while creating another.
Within the Method, prototype testing connects the Concept, user journey and readiness criteria. It defines the first release of a website or application and lets development begin with a clear view of what has been tested and what remains a hypothesis.
From an idea to a digital product
If the task calls for a service or internal tool, we can define the first complete journey and a path to a working release.