Skills

Interaction Design Prototype

10 weeks · 0 milestones

High-fidelity interactive prototype addressing a problem identified through real user research. Triad: concept/ideation artifact (design rationale document: how each key interaction decision — navigation structure, primary actions, information hierarchy, affordances — traces back to a specific research finding or insight; this is a research-grounded design argument, not a visual style rationale), technical execution artifact (high-fidelity interactive prototype — minimum 10 linked screens or states demonstrating the core user journey — with documented minimum 3 iteration rounds), documentation/critique artifact (iteration record: for each round, what the starting state was, what usability test finding or design critique prompted the change, and what changed — with before/after screenshots or Figma version history). Proof Accessibility Rule applies: Figma (free tier), Penpot (open source and free), and Adobe XD (free starter plan) are all valid free-tier prototyping tools. Studio critique: UX practitioner with design research experience reviews interaction design decisions and challenges the research-to-design traceability — 'this looks good' is not a valid critique response for a UX MSc standard. Proof: design rationale document, prototype link, iteration documentation, critique notes. Verifier: UX practitioner (minimum 3 years), product designer with UX research background, or design research academic.

Part of: Creative & Design · Proves for: PG

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?

You'll sign in first, then come straight back here.

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?

You'll sign in first, then come straight back here.

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?

You'll sign in first, then come straight back here.

Part of

UX Research & Design →

Related outcomes

Milestone map

3 milestones

Define interaction problem and produce design brief

1 week (1–2 hrs/day)

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?

You'll sign in first, then come straight back here.

Produce interactive prototype through minimum two documented iterations

3–4 weeks (2–3 hrs/day)

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?

You'll sign in first, then come straight back here.

Test prototype with real users and produce design recommendations

2 weeks (testing + analysis)

Proof required

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?

You'll sign in first, then come straight back here.