Prototype the behavior before expanding the application.

A prototype does not need every screen of a proposed application. Select a task with a clear beginning, a local change, and a point at which information is expected to reach a shared system. Include the interruption that makes the task uncertain.

Use invented information where possible. A focused example can reveal whether the behavior is understandable without requiring access to operational accounts or confidential field records at the first stage.

Some prototypes imitate connectivity states while others implement local storage and a test service. Both can answer useful questions, but their conclusions differ. A visual simulation can test whether a label is understood; it cannot establish the durability of a particular storage implementation.

Document which parts are real, which are simulated, and which conditions have not been investigated. Reviewers should be able to interpret the evidence without inferring capabilities from the appearance of the interface.

A review should include leaving a screen, returning to a pending item, and encountering a transfer that has not completed. The user needs to understand what was preserved and which action is appropriate. A successful uninterrupted path alone misses much of the research question.

If the prototype includes attachments, consider them separately from the text record. A form and a large file may reach different states and require different explanations.

Record the task, conditions, expected behavior, and what was actually observed. Distinguish a user misunderstanding from a technical failure and from a behavior that the prototype did not implement. Each points to a different next action.

The output can support a decision to refine the interface, investigate a storage strategy, or scope further development. It does not establish production reliability across devices and environments that were outside the agreed investigation.