← Week 03: Plan: the experience and the system
SESSION 01 · TUESDAY
Design the journey before you design the screens
Tonight your bet becomes something people can try: a journey, a clickable prototype and two honest usability tests.
Journey mapFirst value momentArtifact prototypeUsability testAccessibility
Present slides ▶
Full screen, one slide at a time · 14 slides
Tonight’s outcomes
- Write MVP objectives: what this MVP must prove, with a threshold set before building
- Map today’s and the future journey, and the fewest steps to the first value moment
- Choose the prototype fidelity that answers the question you need answered
- Build a clickable prototype as a Claude Artifact and test it without leading anyone
- Apply five accessibility essentials before anyone tests your prototype
OUTPUT · MVP objectives + journey + prototype + notes from two usability sessions
MVP objectives: what this MVP must prove
- OBJECTIVEOne sentence about behaviour: tutors confirm a first booking without the founder’s help
- METRICWhat you will count: invited tutors who confirm a learner’s request on their own
- THRESHOLD SET FIRSTWritten before building: at least 6 of 10 within 14 days (illustrative)
- IN SCOPEOnly what the proof needs: request a slot, see it, confirm it
- OUT OF SCOPEWritten down so it stays out: payments, reminders, calendar sync, agencies
A threshold set after the result proves nothing. Write it down before you design or build.
The journey: from trigger to return
- TRIGGERSomething makes the problem real right now: a parent needs a lesson this week
- DISCOVERThey find a way to act: a link from the tutor, a recommendation, a search
- TRYThey take the first step and decide whether it is worth the effort
- FIRST VALUEThey get the result they came for, for the first time
- RETURNThey come back unprompted, because it worked last time
Design the whole path. A beautiful screen in the wrong place still loses the user.
TutorDesk today: where tutors lose bookings
Starting point
“Tutors need a nicer calendar, so let’s design a calendar screen.”
Reframed
A parent messages at 21:40 on WhatsApp. The tutor sees it next morning, checks a paper diary, replies at lunch, and the parent has booked elsewhere. The loss is the gap before confirming.
Ask
- Where exactly does the enquiry go cold?
- What does the tutor do today to work around it?
- Which step would TutorDesk remove, not just digitise?
- How could you watch this happen rather than ask about it?
Screens first vs journey first
Screens first
- Starts with a dashboard, settings and a logo
- Designs features nobody needs in the first week
- Debates colours before the path works
- Finds the gaps only when real users get stuck
Journey first
- Starts with the trigger and the outcome the user wants
- Designs only the screens on the path to first value
- Leaves settings and extras for a later version
- Finds the gaps on paper, before anything is built
A screen is one step in a journey. Know the step before you draw the screen.
The first value moment
- DEFINEThe moment the user first gets the result they came for, written as an event
- TUTORDESKThe tutor confirms a requested slot and the learner receives the confirmation
- MEASURECount the steps and minutes from trigger to that moment
- CUTRemove or postpone every step that does not move the user towards it
- PROTECTNothing else in the design may get in its way
If a step does not move the user towards first value, it waits for a later version.
Low fidelity vs high fidelity: when to use each
Low fidelity: sketches, paper
- Answers: are these the right steps in the right order?
- Minutes to make and easy to throw away
- People comment on the idea, not the colours
High fidelity: clickable, real
- Answers: can people complete the task without help?
- Needs realistic words, names and times to be believable
- Risk: polish makes you attached and makes testers polite
Choose fidelity by the question. Tonight’s question: can a tutor confirm a slot unaided?
A clickable prototype as an Artifact
I’m designing TutorDesk, a booking tool for solo tutors who lose lesson requests in WhatsApp and email. I want a clickable prototype so I can test one thing: can a tutor confirm a requested slot without help? <journey>[PASTE FUTURE JOURNEY]</journey> Please build it as an interactive Artifact with three screens only: the learner’s request form, the tutor’s list of pending requests, and the confirmation. Use realistic names and times, plain labels and a visible keyboard focus. If a step in my journey is unclear, ask me before inventing it. Done = I can click from request to confirmation in under a minute.
Check the response
- Only the screens on the path to first value?
- Labels in the words a tutor would actually use?
- Can you complete the task with the keyboard alone?
A five-person usability test
- TASKGive a goal, not instructions: “A parent wants Tuesday at 4pm. Sort it out.”
- OBSERVEAsk them to think aloud; watch where they hesitate, misclick or reread
- STAY QUIETDo not help, explain or defend the design; the silence is where findings appear
- PROBEAfterwards ask “What did you expect to happen there?”, not “Was that easy?”
- RECORDWrite what happened, where, and their words; keep your opinions separate
About five people per user group reveal most big problems. Run two tonight and three more this week.
Accessibility essentials: five checks before anyone tests
Shuts people out
- Hint text inside fields instead of labels; it vanishes as you type
- Only works with a mouse; no visible focus as you tab
- Pale grey text; the layout breaks when text is enlarged
- “Invalid input” in red, with no clue how to fix it
Lets everyone in
- Every field has a visible label that says what to enter
- Every action works by keyboard, with a visible focus outline
- Strong contrast, and the page still works at 200% zoom
- Errors say what went wrong and how to fix it, not by colour alone
Accessible design is clearer design for everyone, including a tired parent on a phone at night.
A neutral test script, then honest findings
I’m about to run two 10-minute usability tests of my TutorDesk prototype. I want a script that doesn’t steer people, so I can trust what I see. <task>[MY TEST TASK]</task> Please write: a 30-second welcome saying we are testing the design, not the person; the task as a realistic scenario that names no buttons or screens; three open follow-up questions. After the sessions I’ll paste <notes>[PASTE SESSION NOTES]</notes>. Then list each problem with where it happened, how many people hit it and a short quote. If the notes don’t show something, write “not in the notes” rather than guessing. Done = a script I can read aloud in two minutes, and a findings table.
Check the response
- Does the task avoid naming buttons or screens?
- Are the questions open, never “Was that easy?”
- Is every finding backed by something observed?
Workshop: journey, prototype and two tests
Say what your MVP must prove, map the path to first value, prototype it, then watch two people try it without help.
- 0–5 min: write MVP objectives: objective, metric, threshold now, what is in and out of scope
- 5–13 min: map today’s and the future journey in five steps; circle the first value moment
- 13–29 min: brief Claude for a prototype of only that path; run the five accessibility checks
- 29–44 min: pair up; each runs two 7-minute tests with your neutral script while the other notes
- 44–49 min: write findings: problem, where, how many, quote, and what you will change
Deliverable
Objectives, journey, prototype in 03-design.md; test notes in product/evidence/
Prototype rubric
- MVP objectives name a metric, a threshold written before building, and scope in and out
- Journey map shows today and the future for one named user, with first value marked as an event
- Prototype covers only the path to first value and can be clicked through end to end
- Passes the five checks: labels, keyboard, contrast, clear errors, 200% zoom
- Test task gives a realistic goal without naming buttons or hinting at the answer
- Notes from two sessions list each problem with where it happened, how many, a quote
HOMEWORK · Three more tests with real target users; change the prototype and log what changed
© 2026 MVP Studios Ltd. MVPAI™ and the MVP Founders Programme materials are original works of MVP Studios Ltd. All rights reserved. No copying, redistribution or commercial use without written permission. Course terms