Turn one hypothesis into a working clickable prototype in v0, Lovable, or Bolt — no code written by hand — then design the five-user test that could actually falsify it. The graded artifact is the validity-limits note: five claims about what this prototype "proves" are provided, three are wrong, and you must say which and why.
Arjun is a PM at a Gurugram fintech serving small-business owners. His team debates a feature for two sprints before building anything; he wants to compress that to two days. Today's candidate is a cash-flow forecast view. The risk with prototype tools is not that they fail — it is that they succeed so vividly that everyone over-reads what the test showed. This lab builds the prototype fast, then spends its real effort on knowing exactly what the resulting evidence can and cannot support.
HYPOTHESIS (provided — test this one, not one you like better)
"Small-business owners will trust and act on a 30-day cash-flow
forecast if it clearly shows: projected balance line, the 3 biggest
upcoming outflows, and a plain-language 'risk of dipping below zero'
statement."
PROTOTYPE SCOPE
- One dashboard screen: balance forecast chart (30 days), top-3
upcoming outflows list, one risk sentence.
- One drill-down: tap an outflow to see date, payee, amount, source.
- Seeded demo data for a fictional business: "Kave Coffee Roasters",
current balance Rs 4,80,000, a Rs 3,20,000 supplier payment due
day 12, GST payment day 20, payroll day 28.
- Out of scope: real bank connection, editing data, alerts.
FIVE CLAIMS TO EVALUATE LATER (three are wrong)
C1. If 4 of 5 users say they would use this weekly, we have validated
demand for the feature.
C2. If users correctly explain what the risk sentence means without
help, the risk copy is comprehensible to this audience.
C3. The prototype demonstrates that a reliable 30-day forecast can be
computed from the users' real bank data.
C4. If users navigate from chart to drill-down unaided, that flow's
basic usability is supported for this design.
C5. If all 5 users react enthusiastically, we can skip the painted-
door test and commit engineering to the full feature.
Generate the prototype. Paste the prototype scope into your tool as a single prompt, including the seeded demo data verbatim. Ask for a clean, mobile-width dashboard. Iterate at most three times — fix only what blocks the test (unreadable chart, missing drill-down), not aesthetics. Resist scope creep: the tool will happily add alerts and settings screens; the hypothesis needs neither.
Sanity-check the seeded numbers. Walk the demo data yourself: with a Rs 4,80,000 balance and those three outflows, does the chart's shape and the risk sentence match the arithmetic? Prototype tools frequently generate charts that contradict their own seed data. If the risk sentence says "healthy" while payroll takes the balance negative on day 28, fix the prompt until data and display agree — testing users on self-contradictory stimuli invalidates everything downstream.
Write the test plan with a falsifiable success signal. Prompt your chat AI: "Draft a 5-user moderated test plan for this prototype and hypothesis. Include: recruiting criteria, 3 tasks, 5 open questions that avoid leading the user, and a pre-registered success signal." Then hand-fix the success signal so it is behavioral and falsifiable — e.g., "at least 3 of 5 correctly interpret the risk sentence unprompted AND identify which outflow they would act on" — not "users like it."
De-bias the script. Reread every task and question hunting for leading language: "How helpful is the forecast?" presumes helpfulness. Ask the AI to attack its own script — "Which of these questions lead the witness? Rewrite them neutrally" — then verify its rewrites yourself. Add the one question most PMs skip: "What would you need to see before trusting these numbers with a real payment decision?"
Dry-run the test on one person. Any colleague or friend, ten minutes, using the real prototype link. You are testing the test: task wording that confuses, a step where the prototype dead-ends, a question that yields shrugs. Note what you would change. (In a real sprint you would now run five users; the lab grades the instrument, not the sessions.)
Write the validity-limits note. For each claim C1–C5, write VALID or INVALID plus two or three sentences of reasoning grounded in research-method basics: what this study design (n=5, moderated, demo data, stated intent) can and cannot support. Do this before opening the answer key, and do it yourself — this is the judgment artifact.
Cross-examine your note with AI, then finalize. Prompt: "Here are five claims about what a 5-user moderated prototype test can prove, and my verdicts. Argue against each of my verdicts as a research methodologist." Where its counterargument moves you, revise and note why; where it does not, write the one-line rebuttal. Then check the answer key and score yourself.
Write the next-step line. One sentence per wrong claim: what test would generate the missing evidence (painted-door for demand, data-science spike for feasibility, unmoderated n=30 for usability confidence). This turns the limits note from criticism into a research roadmap.
Cap the prototype at 40 minutes by the clock — the tool rewards endless polishing, and every extra minute there is stolen from the part of the lab that changes decisions.
A complete lab has all of the following:
Prototype tools collapse build cost to near zero, which moves the whole risk into interpretation. A prototype test validates comprehension and flow, never demand or feasibility — write the validity-limits note before anyone sees the demo, because after they see it, enthusiasm does the interpreting.