A focused app prototype should let you test one important user task and leave you with a written account of what the next build requires. Agree whether it is a clickable design, a working slice of software, or a technical experiment. Those outputs answer different questions and need different acceptance criteria.
Name the decision before the screens
An illustrative booking prototype might answer: “Can an office manager assign a job and can a field worker see what they need to do?” A technical experiment might instead ask whether an existing system exposes the data that workflow requires.
Write down the intended user, starting information, desired result, and the uncertainty you want to resolve. Use that statement to decide which screens belong in the prototype. A polished settings page adds little if the assignment flow is still unclear.
State what is simulated
Ask which parts are interactive and which use sample data. Identify any real account, external service, or device capability involved. Label simulated results in the demonstration so a reviewer can distinguish a design decision from a working integration.
A clickable prototype can be useful without a backend. A working prototype may use temporary storage or a small fixture. Neither proves that production authentication, permissions, backups, or store release preparation is complete.
Ask for a small, reviewable handover
| Deliverable | What it lets you decide |
|---|---|
| A defined user flow | Whether the proposed task matches the user's work |
| A prototype you can open | Whether the interaction is understandable |
| Written scope and exclusions | What the production estimate includes |
| Data and role notes | What information exists and who can access or change it |
| Open questions and technical findings | What still needs investigation before a reliable quote |
| A build recommendation and estimate | Whether to proceed, reduce scope, or try another approach |
If an export, offline task, or device feature is the main risk, include it in the experiment rather than leaving it behind a static button. Agree the limits of that test before the work starts.
Review it with a realistic task
Give a representative user a starting situation and ask them to finish the task. Avoid narrating every click. Note where they hesitate, which information they expect, and whether the result means what they think it means.
Keep observations separate from preferences. “The user could not find the assigned job” calls for a different change from “we prefer another button color.” Record unresolved questions so the next team does not mistake a provisional choice for a requirement.
Decide what happens next
The prototype may support a production build, reveal that an existing tool is sufficient, or show that the problem needs a different scope. Keep the artifact and specification usable by the people making that decision.
LifeVen's prototype sprint provides a usable prototype, written specification, and a fixed quote for the agreed production work. Bring the task you want to test and examples of the current process. If an existing application already needs investigation, a technical review may be the better first step.