A prototype is useful when it answers a question that could change your product decision. AI can help you make it quickly, but the learning goal should determine what you build.
This five-day plan is a suggested practice schedule, not a promise that every product can be validated in a week. Access to participants and technical complexity may require more time.
Day 1: choose the question
Write one assumption that could make the idea fail. For example: “New team administrators can choose the right permission level when the consequences are explained before sending an invitation.”
Define a task that exposes that assumption. Decide what behavior would support continuing, what would require a revision, and what would make you reconsider the approach. These are learning thresholds, not proof of market demand.
Recruit people who resemble the intended users. If you can only test with colleagues, record that limitation. Do not turn their reactions into claims about customers.
Day 2: describe one complete journey
Write the starting state, user goal, steps, decisions, and ending state. Include one meaningful failure: missing information, an invalid input, or a denied permission. Keep the first version small enough that you can inspect every interaction.
Try this build prompt:
Create a prototype for the attached user task. Use fictional data. Implement only the specified journey. Include loading, empty, error, and success states that matter to this task. Label simulated behavior. Do not connect production services or add payment collection. First explain your planned screens and unresolved assumptions, then build the agreed flow.
Figma Make and Lovable document prompt-driven prototype or app creation. A repository-based tool such as Claude Code can be useful when the work needs to fit an existing codebase. Choose based on your workflow, not a universal ranking.
Day 3: inspect before inviting participants
Try the intended task without explaining the interface to yourself. Then use keyboard navigation, narrow the screen, enter incorrect information, and revisit a completed step. Fix broken interactions that would distract from the question you are testing.
Keep a “real versus simulated” list. If the invitation is not actually sent, say so. If permissions are hard-coded, say so. A realistic-looking prototype can create false expectations unless you document the boundaries.
Day 4: observe behavior
Give participants a neutral task: “Invite a colleague who needs to review the project but should not be able to change it.” Avoid “Click Viewer and press Send.” Watch what they do and what they believe will happen.
Record completion, hesitation, unexpected interpretations, and recovery from mistakes. Ask what they expected at confusing moments. A handful of qualitative sessions can reveal problems; it cannot establish a reliable population conversion rate.
Day 5: make a decision
Separate observations from interpretation. If several people pause, determine whether the confusion concerns wording, the underlying permissions model, or the value of the task itself.
Choose continue, revise, or stop. Explain the evidence and the next uncertainty. Share a short video, the prototype, findings, unresolved technical issues, and requirements for any production implementation.
Do not quietly promote the prototype into production. Real access controls, data handling, reliability, monitoring, and support require their own engineering and operational review.
Try it: Use the Prototype Test Kit or explore the Prototype & Decision Sprint for guided help.