Unit 5 · Lesson 20 of 20
Capstone: improve a whole experience
Apply diagnosis, design, evaluation, and professional judgment to one connected service.
01 / Learn
The idea
A capstone should integrate methods rather than reward an attractive screen. Begin with the user's outcome and the evidence packet. Make a service map, separate observations from explanations, identify a consequential failure, compare changes, and decide what to test. Explain how you would coordinate the website, kiosk, assistant, and staff without making a channel promise it cannot fulfill.
Treat AI suggestions as proposals whose source, confidence, and limits are visible. The authoritative booking system must confirm availability and completion. Define a human route for unusual accessibility or policy questions. Your recommendation can be staged, but the first stage needs a clear owner, measurement, and stop condition. This exercise assesses a documented decision, not professional certification.
A capstone is a single final mockup. The reviewable result is a chain from evidence to decision, tested states, and a plan to revise.
02 / See the reasoning
Worked example
Fictional scenario
A fictional city library offers room reservations through a website, mobile confirmation, a lobby kiosk, and staff help. A new AI assistant can suggest rooms but cannot finalize a reservation.
A fictional team finds that three of eight observed visitors thought the AI's 'room found' message meant a booking existed; two arrived to find the room unavailable. An expert records those observations without estimating a population rate, checks assistant and booking logs, then proposes 'Suggested room—confirm availability' and a real booking acknowledgment. They test whether visitors can distinguish suggestion from reservation and whether staff can recover conflicts.
Try a decision →03 / Decide
Guided decision
The assistant can suggest a room but the booking service is intermittently unavailable. Which release decision best fits the evidence packet?
Feedback on your choice
What could change the answer: If visitors still interpret provisional suggestions as bookings, change the interaction model or pause suggestions in the affected flow; copy alone may be insufficient.
This feedback helps you examine the decision; it does not grade your written reasoning.
Apply it somewhere new →04 / Apply elsewhere
Independent application
Fictional scenario
A fictional community health center offers class registration through web, phone staff, and an automated chat assistant. Classes have limited seats and eligibility rules.
Evidence and constraints
- Fictional observation: in six moderated sessions, two participants interpreted 'I found a place for you' as confirmed enrollment. Neither had a booking record. This is a failure mode in the observed sample, not a population rate.
- Fictional observation: one participant learned from phone staff that they were ineligible for the suggested class. The assistant had displayed the class before checking eligibility.
- Fictional system detail: the booking service can confirm a seat synchronously when online. During an outage it returns no confirmation; it does not reserve a place for later.
- Fictional operations detail: phone staff use a separate ledger that updates from the booking service about every fifteen minutes. Staff can resolve eligibility questions during staffed hours, but cannot guarantee a seat from the ledger alone.
- Fictional access constraint: some members use phone service because the web form is difficult with a screen reader. The team has not yet tested the assistant with screen-reader users or in languages other than English.
- Fictional policy uncertainty: the center has not supplied a complete list of exception rules or named an owner for assistant advice about eligibility. Do not invent those rules; state what must be verified before release.
- Fictional delivery constraint: the next release can change assistant copy and booking handoff. A shared real-time staff ledger would require a later release.
Recommend a staged change to the registration service. Produce a task and service map, observation-versus-hypothesis list, two design alternatives including failure states, a test plan with tasks and observations, a decision memo, and a revision rule. State what the small sample cannot establish. You may recommend pausing part of the assistant if the evidence warrants it.
Make: A compact case dossier: journey map, finding cards, state model, test plan, decision memo, and revision trigger.
The dossier distinguishes facts from hypotheses; aligns all channels to the actual enrollment state; handles eligibility, access, authority, and recovery; compares alternatives; and uses test tasks that can overturn the recommendation.
- Observation and inference are separated; the six sessions are not used as a population estimate.
- The service map identifies which system can confirm a seat, how the fifteen-minute staff ledger affects claims, and who owns each handoff.
- Alternatives address eligibility, screen-reader access, pending and failure states, and a human recovery route without inventing policy.
- Test tasks and observations could reveal whether people distinguish a suggestion from enrollment and whether the proposed safeguard adds unacceptable friction.
- The memo names release dependencies, decision owners, uncertainty, and a concrete condition for revising or stopping the assistant flow.
Path complete
Keep using what you learned.
You have worked through all five capabilities. Return to these methods as your work changes, and keep testing them in real settings.
05 / Keep working