My progress
Menu

UI/UX Product Designer · Capstone

UX10: Capstone: three design projects for SehatSlot

Goal: bring the whole path together by completing, testing and presenting the three path projects: a usability study reported honestly, a booking journey that works for everyone including errors and empty screens, and a small design system handed over to developers, all in the SehatSlot practice kit.

You'll need: everything from UX1–UX9, the SehatSlot practice kit (download it from this path's Projects page), and Node.js 22 or later. No design-tool licence, cloud account or real patient data is needed.

Where this is used: this mirrors real product design work: taking over a journey people struggle with, finding out why, redesigning it so everyone can finish, and leaving behind a system other designers and developers can build on. A portfolio with these three, backed by evidence and passing checks, shows employers more than a gallery of pretty screens.

How it differs: each earlier module taught one skill. The capstone tests whether you can combine them: the prototype's changes come from the research findings, the prototype depends on the design system's tokens and components, and the case studies need evidence from all three.

Time: reading about 2 hours · practice (the Try it tasks) about 2 hours · projects and capstone about 40 to 50 hours in all.

Lessons

  1. 1Planning the capstoneReading 15–25 minutes, plus practice✓
  2. 2Project 1: a study reported honestlyReading 15–25 minutes, plus practice✓
  3. 3Project 2: a journey that works for everyoneReading 15–25 minutes, plus practice✓
  4. 4Project 3: a system developers can build fromReading 15–25 minutes, plus practice✓
  5. 5Demo, self-review and case studiesReading 15–25 minutes, plus practice✓

🛠️Assignment: Complete and present the capstone

This is the final project of the UI/UX Product Designer path.

  1. Write the capstone plan with acceptance criteria, a timeline and the overview table.
  2. Project 1: complete the study plan and findings until the 8 research tests pass.
  3. Project 2: redesign the journey until the 10 prototype tests pass, and test it with at least one person.
  4. Project 3: complete the design system until the 10 system tests pass.
  5. Run the capstone checks on the Projects page, record the demo, complete the self-review, and write three case studies and the design notes.

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

How do the three capstone projects show you can do professional product design work?

Show a good answer

A good answer mentions: planning with research first and evidence kept; a study with a fair plan, consent, tasks that don't lead, findings whose evidence and counts match the notes, severity and limits; a journey redesigned from the findings that works by keyboard, screen reader and touch, with every state, kept details and masked personal data; a design system with checked tokens, components in every state, documentation, handover and a version; and a demo, self-review and case studies that show errors handled and label every figure.

📚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 learner wants to start the capstone by choosing the new colour palette. What's the best advice?

Why each option is right or wrong

  • “Choose the palette first, as every other decision depends on colour” (Incorrect): Colour depends on findings and contrast needs, not the other way round.
  • “Do all three projects at once and run the tests only at the very end” (Incorrect): Without running tests as you go, you can't tell what each change fixed.
  • “Skip the research, since the session notes are already written” (Incorrect): The notes are evidence; the findings are the analysis you still need to do.
  • “Finish the research first, since its findings decide what to change” is correct.

    The findings point to the slot screen and the form, not the palette, as the main problems.

    • Order: research, then prototype and system together.
    • Kit: 8 research tests.

📖 Revise: Lesson 1: Planning the capstone

Question ID sp-ui-ux-10-q1 · Report a mistake in this question
2. A learner's findings list [error-colour] with evidence "P1, P3". Test 5 fails. What's wrong?

Why each option is right or wrong

  • “The test is too strict and should allow one participant to be missing” (Incorrect): The test checks honesty; changing it isn't allowed.
  • “Severity should be "minor", since only two participants are listed” (Incorrect): Severity is a separate column, and the evidence is still wrong.
  • “The tag should be renamed so that it doesn't match the notes” (Incorrect): That would break the link between findings and evidence.
  • “P5's notes also carry the tag, so the evidence is incomplete without them” is correct.

    Evidence must list every participant whose notes carry the tag, and only those.

    • Check: grep -l 'error-colour' research/sessions/*.md.
    • Then: update the summary's counts.

📖 Revise: Lesson 2: Project 1: a study reported honestly

Question ID sp-ui-ux-10-q2 · Report a mistake in this question
3. A learner's prototype fails test 10: the name is empty after "Change time". What's the most likely cause?

Why each option is right or wrong

  • “The test browser blocks sessionStorage, so nothing can be saved” (Incorrect): The reference passes in the same browser.
  • “The slot screen is too slow to load before the test checks the field” (Incorrect): The test waits for each page; the details simply weren't saved.
  • “The name field is too short for "Test Patient", so it's cut off” (Incorrect): Field width doesn't remove the value.
  • “Details are saved only on submit, not while people are typing them” is correct.

    Saving on every input keeps details when people go back to change the time.

    • Reference: saves to sessionStorage on input.
    • Finding: F3 (no-back).

📖 Revise: Lesson 3: Project 2: a journey that works for everyone

Question ID sp-ui-ux-10-q3 · Report a mistake in this question
4. After restyling buttons, test 7 starts failing. What does that most likely mean?

Why each option is right or wrong

  • “The test is broken by the new styles and should be skipped for now” (Incorrect): Skipping hides a real problem.
  • “The page is now too wide and scrolls sideways at 320 pixels” (Incorrect): That's test 8.
  • “The buttons no longer use the btn class from the system” (Incorrect): That's system test 9; test 7 measures size.
  • “Some buttons or links are now smaller than 44 by 44 pixels” is correct.

    Restyling can remove minimum sizes; run the whole file after each change.

    • Fix: min-height and min-width on .btn.
    • Then: re-run all ten tests.

📖 Revise: Lesson 3: Project 2: a journey that works for everyone

Question ID sp-ui-ux-10-q4 · Report a mistake in this question
5. Test 5 of the system tests fails because styles.css contains #0b5d7a. What's the right fix?

Why each option is right or wrong

  • “Add a comment next to the colour explaining why it's needed” (Incorrect): A comment doesn't connect it to the tokens.
  • “Change the test so that it allows the brand colour as an exception” (Incorrect): Tests aren't changed to pass.
  • “Move the colour into an inline style attribute in the HTML” (Incorrect): Test 5 also fails on inline styles.
  • “Replace it with var(--color-primary)” is correct.

    The prototype should use tokens, so colour changes reach every screen.

    • If new: add a token to tokens.json, then rebuild.
    • Run: npm run tokens.

📖 Revise: Lesson 4: Project 3: a system developers can build from

Question ID sp-ui-ux-10-q5 · Report a mistake in this question
6. A learner's self-review says "Accessibility: done." What would make it useful?

Why each option is right or wrong

  • “Adding "definitely" to make the claim sound more confident” (Incorrect): Confidence isn't evidence.
  • “Removing it, since accessibility is checked by the tests anyway” (Incorrect): Tests cover some of it; the review should say what else was checked.
  • “A screenshot of the confirmation page to show how it looks” (Incorrect): Looks don't show accessibility.
  • “Evidence, what wasn't verified, and the next step to take” is correct.

    A rating with evidence and gaps can be trusted and acted on.

    • Example: "VoiceOver on iPhone not verified."
    • Style: rating, evidence, gap, plan.

📖 Revise: Lesson 5: Demo, self-review and case studies

Question ID sp-ui-ux-10-q6 · Report a mistake in this question
7. Which demo plan is strongest?

Why each option is right or wrong

  • “A smooth booking from start to finish, with no mistakes at all” (Incorrect): The happy path shows little about how the design handles trouble.
  • “A slideshow of the final screens with background music” (Incorrect): It shows looks, not behaviour.
  • “A long walk through every line of the prototype's code” (Incorrect): The demo is about the design and its evidence.
  • “A keyboard booking with a deliberate error, an empty search and the masked number” is correct.

    Showing problems handled well is stronger evidence than a perfect run.

    • Plus: findings, the system and npm test.
    • Data: invented only.

📖 Revise: Lesson 5: Demo, self-review and case studies

Question ID sp-ui-ux-10-q7 · Report a mistake in this question
8. A case study says "task success went up 60%". What should it say instead?

Why each option is right or wrong

  • “"Task success improved a lot", without numbers that might confuse” (Incorrect): Vaguer, and still unsupported.
  • “"Task success went up 60%, which is better than most redesigns"” (Incorrect): Comparisons with other projects aren't supported.
  • “Nothing, as figures in case studies are only illustrations anyway” (Incorrect): Figures need to be labelled and accurate.
  • “"T1 without help: 2 of 5 to 5 of 5, practice kit, with the date"” is correct.

    Counts, the task, the data set and the date make the figure honest.

    • Add: the limits of five sessions.
    • Label: practice-kit data.

📖 Revise: Lesson 5: Demo, self-review and case studies

Question ID sp-ui-ux-10-q8 · Report a mistake in this question
9. Why are Projects 2 and 3 built together?

Why each option is right or wrong

  • “Because both of them have exactly ten tests in the kit” (Incorrect): The test count isn't the reason.
  • “Because the research project is optional for most learners” (Incorrect): All three are required.
  • “Because developers usually need them on the same day” (Incorrect): Timing isn't the reason in the kit.
  • “Because the prototype uses the system's tokens and components” is correct.

    Changes to tokens and components show up in the prototype, and both sets of tests check that link.

    • Example: system test 5 checks styles.css.
    • Example: system test 9 checks buttons.

📖 Revise: Lesson 1: Planning the capstone

Question ID sp-ui-ux-10-q9 · Report a mistake in this question
10. The starter passes 3 of 28 tests. What's the right way to read that?

Why each option is right or wrong

  • “The kit is broken and needs to be downloaded again from the site” (Incorrect): The kit is deliberately unfinished.
  • “The 3 passing tests can be deleted, as they're already done” (Incorrect): Passing tests keep checking that nothing breaks.
  • “The 25 failing tests should be fixed by editing the test files” (Incorrect): Tests aren't changed to pass.
  • “It's expected, because the tests describe the finished kit” is correct.

    The projects turn the failing tests green one by one.

    • Starter: prototype 8 and 9, system 1.
    • Goal: 28 of 28 in one run.

📖 Revise: Lesson 1: Planning the capstone

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

ProLearners Assist