My progress
Menu

UI/UX Product Designer · Focus area 3: Interactive prototypes

UX8: Interactive prototypes

Goal: choose the right fidelity for a question, build a clickable prototype of a whole journey, design every state of every screen, test the prototype with people and with automated checks, and keep the design honest.

You'll need: UX5 to UX7, Module 17 (JavaScript Basics) and Module 19 (Browser Interactions) for the HTML prototype, and the SehatSlot practice kit (prototype/). Figma or Penpot is optional.

Where this is used: before a bank builds a new payment flow, it tests a prototype with customers. A prototype that looks and behaves like the real thing shows problems that a static picture hides: what happens after a tap, when the form is wrong, when there are no results.

How it differs: wireframes and visual design describe screens. A prototype describes behaviour, so it can be tested the way people will really use the product.

Time: reading about 2 hours · practice (the Try it tasks) about 3 hours · assignment about 4 hours.

Lessons

  1. 1Fidelity: how real a prototype needs to beReading 15–25 minutes, plus practice✓
  2. 2Building a clickable journeyReading 15–25 minutes, plus practice✓
  3. 3Designing every stateReading 15–25 minutes, plus practice✓
  4. 4Testing prototypes, with people and with toolsReading 15–25 minutes, plus practice✓
  5. 5Ethical design and dark patternsReading 15–25 minutes, plus practice✓

🛠️Assignment: Prototype and test SehatSlot's booking journey

  1. Write the questions your prototype must answer and choose its fidelity.
  2. Build the whole journey in the kit's prototype/: search, choose a time, details, confirmation, with real data and stored choices.
  3. Make a state inventory and design every state: empty search, worded errors, selected slots, loading button, success.
  4. Run npm run test:prototype until all 10 pass, without changing any test.
  5. Test the journey with at least one person and note what the tests didn't show.
  6. Review your design for dark patterns and pre-ticked consent.

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

How do you build and test a prototype that shows how a journey really behaves?

Show a good answer

A good answer mentions: fidelity chosen to match the question, with coded prototypes for behaviour and accessibility; a whole journey linked with real data and choices carried forward; a state inventory covering focus, selected, disabled, loading, empty, error and success; testing with people and automated checks together, without changing tests to pass; and ethical design without dark patterns, with consent that is a real choice and personal data shown only where needed.

📚Official references

Official documentation and guidance for this module's topics, chosen on 2 November 2026. Tools, laws and standards change, so check the current version before you rely on a detail. If a link has moved, search the same site.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. A team wants to know whether screen reader users can choose a time. Which prototype fits?

Why each option is right or wrong

  • “A paper prototype with one sheet of paper for each screen” (Incorrect): Paper can't show what a screen reader announces.
  • “A static image of the slot screen, shown full-size on a phone” (Incorrect): Images have no controls to announce.
  • “A high-fidelity Figma prototype with polished visual design” (Incorrect): It shows looks, not what a screen reader hears.
  • “A coded prototype, with real buttons and the announcements they make” is correct.

    Only real controls show what assistive technology will do.

    • Kit: prototype/slot.html with aria-pressed.
    • Test: with screen reader users too.

📖 Revise: Lesson 1: Fidelity: how real a prototype needs to be

Question ID sp-ui-ux-08-q1 · Report a mistake in this question
2. A prototype shows the same clinic on every later screen, whatever participants chose. What's the likely effect?

Why each option is right or wrong

  • “None, because participants know a prototype isn't the real thing” (Incorrect): They still notice, and stop trusting what they see.
  • “It makes the test quicker, since there's less to look at on each screen” (Incorrect): It doesn't save time, and it spoils the evidence.
  • “It's better, as it keeps every session identical for comparison” (Incorrect): Sessions need the same tasks, not the same wrong details.
  • “Participants lose trust and the session turns to the prototype's bugs” is correct.

    Choices should carry forward, so the test is about the design, not its flaws.

    • Kit: sessionStorage carries the clinic and time.
    • Data: realistic and changing with choices.

📖 Revise: Lesson 2: Building a clickable journey

Question ID sp-ui-ux-08-q2 · Report a mistake in this question
3. A payment button has no loading state. On slow connections people press it twice. What should the design add?

Why each option is right or wrong

  • “A larger button that's easier to press once on the first attempt” (Incorrect): Size doesn't tell people something is happening.
  • “A warning above the button: "Press only once, please"” (Incorrect): People still can't tell whether the first press worked.
  • “A sound when the button is pressed, to confirm the tap” (Incorrect): Sound may not be heard, and doesn't stop a second press.
  • “A loading state that disables the button and says "Paying…"” is correct.

    It shows progress and prevents a second press.

    • Also: aria-busy="true".
    • Server: checks for duplicates too.

📖 Revise: Lesson 3: Designing every state

Question ID sp-ui-ux-08-q3 · Report a mistake in this question
4. A redesign passes every automated check. What else should happen before release?

Why each option is right or wrong

  • “Nothing, since passing every check means the design is ready to ship” (Incorrect): Checks can't tell you whether people notice or trust the design.
  • “A second run of the same automated checks, to make sure they still pass” (Incorrect): Re-running the same checks adds nothing new.
  • “A survey asking staff whether they like the new design better” (Incorrect): Staff opinion isn't evidence about users.
  • “A usability test with a few people on the main tasks, as well as the tools” is correct.

    Tools check rules; people show whether the design is noticed, understood and trusted.

    • Compare: with the starter's results, as counts.
    • Include: disabled participants where possible.

📖 Revise: Lesson 4: Testing prototypes, with people and with tools

Question ID sp-ui-ux-08-q4 · Report a mistake in this question
5. A test fails because the confirmation page shows the full phone number. A teammate suggests editing the test. What's the right call?

Why each option is right or wrong

  • “Edit the test, since the phone number is the patient's own anyway” (Incorrect): The test protects privacy on a shared screen; changing it removes that.
  • “Skip the test for now and come back to it after the launch date” (Incorrect): The problem stays, and the test is part of the brief.
  • “Remove the phone number from the booking form entirely” (Incorrect): The clinic needs it for reminders; masking is enough.
  • “Change the design so that it shows only the last four digits” is correct.

    Tests describe what the design must do; the design changes, not the test.

    • Reference: "Ending in 4321".
    • Marking guide: no test changed to pass.

📖 Revise: Lesson 4: Testing prototypes, with people and with tools

Question ID sp-ui-ux-08-q5 · Report a mistake in this question
6. A booking form has a pre-ticked box: "Share my number with partner pharmacies". What's the problem?

Why each option is right or wrong

  • “The box is too small to tap easily on a phone screen” (Incorrect): Possibly, but the main issue is consent.
  • “The wording is too long and should be cut to two words” (Incorrect): Shorter wording doesn't fix the pre-tick.
  • “Pharmacies should be listed by name so the box makes sense” (Incorrect): Listing them helps, but the pre-tick is still the problem.
  • “Pre-ticked boxes aren't real consent; people may not notice it” is correct.

    Consent should be an active, informed choice, with a clear purpose.

    • Fair: unticked, or removed if not needed.
    • India: CCPA guidelines, 2023.

📖 Revise: Lesson 5: Ethical design and dark patterns

Question ID sp-ui-ux-08-q6 · Report a mistake in this question
7. Which "no" option on a reminder offer is fair?

Why each option is right or wrong

  • “"No, I'll risk missing my appointment"” (Incorrect): That's confirmshaming.
  • “"Maybe later" with no way to say no for good” (Incorrect): It leads to nagging.
  • “A tiny grey link far below a large bright "Yes" button” (Incorrect): It hides the choice.
  • “"No reminders, thanks"” is correct.

    It's neutral and as easy to choose as yes.

    • Equal: weight and size for both choices.
    • Respect: the answer, without asking again.

📖 Revise: Lesson 5: Ethical design and dark patterns

Question ID sp-ui-ux-08-q7 · Report a mistake in this question
8. A team's state inventory has hover styles for every button but no focus styles. Who is affected?

Why each option is right or wrong

  • “Nobody, as hover and focus are the same thing in browsers” (Incorrect): They're different: hover is for pointers, focus for keyboards.
  • “Mouse users, who'll see the focus outline by mistake on every click” (Incorrect): :focus-visible shows it for keyboard use without affecting clicks.
  • “Only people using very old browsers that don't support hover” (Incorrect): Old browsers aren't the issue.
  • “Keyboard users, who can't see where they are on the page” is correct.

    Focus is its own state and needs its own visible design.

    • WCAG: 2.4.7 Focus Visible.
    • Kit: focus states on the component page.

📖 Revise: Lesson 3: Designing every state

Question ID sp-ui-ux-08-q8 · Report a mistake in this question
9. What is the main reason to keep a prototype disposable?

Why each option is right or wrong

  • “Prototypes are illegal to ship to real users in most countries” (Incorrect): There's no such rule.
  • “Developers aren't allowed to read prototype code at all” (Incorrect): They can read it; it just shouldn't be copied without review.
  • “Design tools delete prototypes automatically after one month” (Incorrect): They don't.
  • “It's for learning, so effort goes only to what the test needs” is correct.

    Over-building slows learning and makes teams reluctant to change.

    • Do: build what the questions need.
    • Agree: what developers may reuse.

📖 Revise: Lesson 1: Fidelity: how real a prototype needs to be

Question ID sp-ui-ux-08-q9 · Report a mistake in this question
10. A screen offers "Only 1 slot left!" on every clinic, even when there are many. What is this?

Why each option is right or wrong

  • “Good marketing, since it helps people decide quickly and easily” (Incorrect): Pressure based on a false claim harms trust.
  • “A harmless default text that no patient would really notice” (Incorrect): The point of it is to be noticed.
  • “Fine, as long as the clinic agrees to the message beforehand” (Incorrect): Agreement doesn't make a false claim fair.
  • “False urgency: a dark pattern that pressures people with a false claim” is correct.

    It pushes decisions with a claim that isn't true.

    • Fair: show the real number of free times.
    • India: listed in the CCPA's 2023 guidelines.

📖 Revise: Lesson 5: Ethical design and dark patterns

Question ID sp-ui-ux-08-q10 · Report a mistake in this question

ProLearners Assist