← Blog

App Prototype Template: Scope One Testable Workflow

By SayCraft Team · 2026-08-16 · 10 min read

An app prototype should answer a product question with the smallest believable workflow. Define what this prototype must teach, who will test it, the real task, the entry and success exit, and which loading, empty, error, recovery, and success states must behave realistically. Use representative sample data and name interactions that must work rather than listing screens alone. Also record what may be simulated, what is out of scope, the evidence to capture, and the decision the test will support. A prototype can clarify flow and language; it does not by itself prove production security, durability, scale, or demand.

Copyable app prototype scope

Question to learn:
Target user and real task:
One core workflow:
Entry point and success exit:
Screens and states required:
Representative sample data:
Interactions that must really work:
What may be simulated:
Out of scope:
Test participants and task:
Evidence to record:
Decision after test: stop / revise / invest
Production risks not evaluated:

Completed example: client approval prototype

Question to learn: Can an invited client identify the current draft and record a decision without facilitator help?
Target user and real task: freelance client reviewing a named project's latest PDF
One core workflow: open invitation → review current draft → approve or request changes
Entry point and success exit: invitation link → retrievable decision receipt
Screens and states required: invitation validation, draft loading/empty/error, review, submitting, receipt
Representative sample data: Project North, draft v3, sanitized sample.pdf, one expired invitation
Interactions that must really work: validate invitation, switch decision, require comment, persist one result
What may be simulated: email delivery and designer notification
Out of scope: invoicing, team analytics, public links, production identity migration
Test participants and task: three representative clients complete a decision without coaching
Evidence to record: route taken, hesitation, error recovery, decision result, exact participant comments
Decision after test: revise if two participants cannot identify the current version; otherwise test the next risk
Production risks not evaluated: security, privacy compliance, durable storage, scale, operations, support

Screen and state matrix: client approval

What a prototype can and cannot prove

Use low fidelity when the decision concerns order or scope. Use a clickable or live preview when timing, form behavior, loading, recovery, or cross-screen state matters. Follow the user flow template, then use the full AI prototype workflow to test it.