Milestone map
Milestone map
3 milestones
Define interaction problem and produce design brief
1 week (1–2 hrs/day)
Select a specific interaction problem from your research or a real product context — a task flow failing for users, an unclear interface state, or a new feature requiring interaction design from scratch. Produce a design brief (minimum 400 words) covering: the interaction problem, the specific users affected, testable success criteria, and technical or business constraints.
Proof required
Submit your interaction design brief (minimum 400 words) with problem statement, user description, success criteria, and constraints.
What gets checked
- Problem is specific enough to scope the design work — not 'improve the homepage'
- Success criteria are testable — not 'users will feel better about it'
- Brief describes an interaction problem, not a visual design problem
Common mistakes
- Problem is too broad to produce a concrete interaction design
- Success criteria are subjective and unmeasurable
- Brief describes aesthetics rather than interaction behaviour
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Check brief defines a specific interaction problem, not a visual design problem
- Verify success criteria are testable — ask student how they will measure success
- Ask student: what makes this an interaction problem rather than a content or visual problem?
Produce interactive prototype through minimum two documented iterations
3–4 weeks (2–3 hrs/day)
Design and prototype your interaction in Figma (or equivalent free prototyping tool). Produce minimum two documented iterations: document your first version, note specifically what was wrong with it, and produce a revised version. Your final prototype must cover the complete task flow including non-happy-path states (error, empty, loading, and success where applicable).
Proof required
Submit your final interactive prototype (shareable Figma link or PDF export of all screens including states) and iteration documentation (V1 screens + what changed and why → V2 screens).
What gets checked
- Final prototype covers complete task flow including non-happy-path states
- Iteration documentation shows what changed between V1 and V2 with design reasoning
- All significant interaction states are designed — not just the primary flow
Common mistakes
- Prototype only shows the happy path — error and edge states are undesigned
- Iteration documentation shows cosmetic changes rather than interaction design decisions
- Prototype is too low-fidelity to test — wireframes without interaction states cannot be meaningfully evaluated
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Check prototype covers all significant interaction states including error and edge cases
- Verify iteration documentation shows interaction design decisions, not just visual changes
- Ask student: what does the error state look like, and how did you decide on that approach?
Test prototype with real users and produce design recommendations
2 weeks (testing + analysis)
Test your final prototype with a minimum of five users in moderated or unmoderated usability sessions using think-aloud protocol for moderated sessions. Record task completion rates for the primary flow. Document findings and produce a design recommendations document (minimum 400 words) identifying three specific design changes the testing revealed.
Proof required
Submit: (1) usability test findings (minimum five participants, task completion rates, observed usability problems with supporting quotes), (2) design recommendations document (minimum 400 words identifying three specific design changes).
What gets checked
- Minimum five participants with task completion rates documented
- Usability problems are supported by observations or quotes — not inferred from completion rates alone
- Design recommendations are specific to interaction design decisions — not general improvements
Common mistakes
- Fewer than five participants — insufficient for pattern identification
- Findings describe what happened rather than identify interaction problems
- Design recommendations are vague — 'make it clearer' without specifying what to change
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Verify minimum five participants with task completion rates documented
- Check usability problems are supported by observations or quotes — ask student to cite one
- Ask student: which design recommendation would you implement first, and how would you test that it worked?
Part of