Project build
Show your MVP to a classmate — cold
- 1 Open your MVP on your laptop. Hand it to your neighbour.
- 2 Do not explain anything. Watch them use it.
- 3 Write down: what did they try first? Where did they get confused? What did they ask?
- 4 Swap back. Get your neighbour's notes.
- 5 Identify the top two usability failures in your MVP.
- 6 Fix one of them in the first 10 minutes before we move to the build phase.
You have two identified usability failures written down and at least one fixed.
Iterating on a live system
Key concept
A system that works on the cases you designed it for is not validated — it is overfitted. Real validation means running cases you did not anticipate. The goal is not to add features but to find the edge of what your current MVP handles.
- ?What is the most surprising way your system failed during the peer test? Was it a model failure, data format issue, or logic error?
- ?What is the slowest part of your pipeline? Is speed a constraint for your users?
- ?If you could only fix one thing before the demo, what would it be? Fix that first.
Run five test cases and fix two failures
Your task
Validate your MVP against five test cases. Document inputs, outputs, and failures. Fix the two highest-impact failures.
- 1 List five test cases: one easy, two edge cases, one adversarial, one from a colleague's data.
- 2 Run each case. Record: input | expected | actual | pass/fail | failure type.
- 3 Identify the two highest-impact failures.
- 4 Fix those two. Write one sentence per fix explaining what was wrong and what you changed.
- 5 Re-run the fixed test cases. Verify they now pass.
- 6 Take screenshots of your five test cases with results.
Deliverable
Test log (5 cases, results, failure analysis) + screenshots of fixed cases.
Self-check · tick before you mark done
✎After running real test cases, how has your understanding of the system's limitations changed? What would you design differently if you were starting over?