Milestone map
Milestone map
3 milestones
Complete end-to-end UX project across all five phases
6–8 weeks (full project)
Select a real design problem from your research, a client engagement, or a substantial speculative project. Apply the full UX design process: discovery research (minimum six participants), synthesis, information architecture or user flow design, interactive prototype, and usability testing (minimum five participants). Document evidence of each phase before moving to the next.
Proof required
Submit evidence of each project phase: (1) research data summary (participant count and methods), (2) synthesis artefact (affinity map or equivalent), (3) architecture or flow diagram, (4) prototype link or export, (5) usability test findings summary (participant count, three tasks, completion rates).
What gets checked
- All five phases are documented — not just the prototype
- Research and testing used real participants, not colleagues or self-test
- Phases are connected — synthesis findings demonstrably informed the prototype direction
Common mistakes
- Project skips or abbreviates phases without documented evidence
- Prototype was not tested with real users
- Synthesis did not inform the design — phases were executed in parallel rather than sequentially
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Verify all five phases are documented with evidence — ask for research participant count and usability test count separately
- Check research used real participants — ask how they were recruited
- Ask student: how did your synthesis findings change your initial design direction?
Write UX case study documenting process and design decisions
2 weeks (writing + editing)
Write a UX case study document (minimum 1500 words) covering your project. Document the process, not just the outcome: include your initial problem framing, what research revealed that changed your thinking, one specific design decision with alternatives considered and reasoning, what usability testing revealed and what you changed, and what you would do differently. Include screenshots or artefact exports.
Proof required
Submit your UX case study document (minimum 1500 words with embedded screenshots or artefact exports as a PDF).
What gets checked
- Case study documents process — design decisions are explained with reasoning and alternatives
- At least one specific design decision is explained with alternatives considered
- Case study honestly addresses what usability testing changed — not only what worked
Common mistakes
- Case study is a portfolio piece describing the final design without process documentation
- Design decisions are stated without alternatives considered or reasoning
- Case study doesn't address what usability testing changed
Resources
Foundationstart here
What a verifier looks for
- Check case study documents process decisions — ask student to identify one specific design decision they nearly made differently
- Verify at least one design decision is explained with alternatives considered
- Ask student: what changed most between your initial design direction and the final prototype, and why?
Present case study for critique and revise with documented changes
1 week
Present your UX case study to a UX practitioner, hiring manager, or design lead in a review session (minimum 25 minutes). The reviewer should challenge your process decisions, research validity, or design reasoning. Document specific challenges and revise the case study incorporating at least two specific changes from the review. Produce a revision note (minimum 200 words) documenting what changed and why.
Proof required
Submit: (1) review session record (date, reviewer, specific challenges — minimum half page), (2) revised case study with tracked changes or explicit revision note (minimum 200 words documenting what changed and why).
What gets checked
- Review record documents specific challenges to process or design decisions
- Revision note identifies at least two specific substantive changes made from review feedback
- Revisions improve the honesty or specificity of the case study — not just polish
Common mistakes
- Revisions are cosmetic — formatting or typo fixes rather than substantive improvements
- Review focused on portfolio presentation rather than process quality
- Revision note describes changes without explaining why they improve the case study
Resources
Foundationstart here
What a verifier looks for
- Confirm review challenged process decisions or design reasoning — not just presentation quality
- Verify revision note identifies at least two substantive changes with reasoning
- Ask student: if you were hiring a UX designer, what would you look for in a case study that this one now demonstrates?
Part of