Give the prototype a question
Imagine you want a customer portal. You could begin with a list of features: registration, documents, notifications, an assistant and a tracking dashboard. Before building all of them, decide what you need to learn first.
Perhaps the question is whether a customer can find the status of a request without calling. That question defines a first version: entering the portal, identifying the request and receiving an understandable answer.
A prototype of this journey helps you examine the language, steps and information required. It does not yet demonstrate that permissions, integrations or operations are ready for production.
Explain what is real in the test
Identify which parts work, which are simulated and which depend on a connection still to be made. If a request status comes from fictional data, say so next to the experience. Reviewers then know what they can evaluate.
The scope should also explain what is outside the test. A prototype can help people understand an interaction before addressing concurrent usage, recovery from failures or the team's daily operating work.
Test more than one journey
Ask someone to complete a specific task. Observe where they hesitate, what they look for and what they interpret differently than expected. Include an incomplete situation, such as a request with missing details or an answer that needs clarification.
Record the result against the criterion set at the beginning. Looks good may be a useful design observation. The person found the status and understood the next step provides evidence about the task itself.
At the end, decide what to keep, what to adjust and what still needs validation. Production requires its own scope and tests. The first version is useful when it makes that decision clearer.
Before requesting a prototype, complete three fields: the question it should answer, the journey it should show and the evidence you will accept before moving forward.
