Test a product decision with one small journey.

Example question: can someone find a request’s status without help? Prepare a list and a detail screen with three fictional records. You do not need to represent every future feature to observe this journey.

State what the exercise will not check: access security, real persistence or behaviour with thousands of records. Successful navigation does not establish those properties.

Include a pending request, an approved one and a rejected one with a reason. Add an empty list to see whether starting is clear. Keep wording and states consistent between screens.

Label demonstration data and simulated actions. If save only changes the mockup, do not present it as a completed operation in a real system.

Ask: “Find out whether the notebook request was approved and what you can do next.” Observe clicks, interpretations and questions without pointing to the answer.

Record the precise confusion. “They do not understand” is less useful than “They look at the date for a decision because they do not recognise the status label.” Change one thing and repeat the journey.

Record the question, example and useful change. Then list capabilities missing from a real application: saving requests, enforcing permissions and handling failures, according to its scope.

Finish the prototype when it supports the specific decision behind the exercise. Keep fictional data as examples for implementation tests.