← back to case study · live prototype (parent project) →

Usability testing plan

Two moderated rounds on the v3.1 prototype (phone-sized browser window or device). Round 1 pressure-tests the general discovery assumptions on the wireflow — info scent, trust comprehension, recovery. Round 2 is a dedicated safety round on the dietary model, with participants who live with food allergies and a domain reviewer. Neither round has been run — all findings tables are intentionally empty.

Round 1 — general discovery

Participants — 5 sessions, ~30 min each

5 participants who order out or eat out ≥2× a week and decide from photos (screener: "show me the last food photo that made you order something"). The "urban, 22–35" framing is a recruitment hypothesis, not an established segment.
Mix: ≥2 who primarily use delivery apps, ≥2 who primarily walk in.
Exclude: food-industry professionals, UX designers.
Device: their own phone if possible (mirrors real grip + text size), else provided device.

Moderator script

"Thanks for making time. This is an early prototype of a food-discovery app I designed — some data is fake and some buttons are intentionally limited; none of that reflects on you. I'll ask you to do a few things and think out loud. There are no wrong answers: if something is confusing, that's the design failing, not you. You won't hurt my feelings — blunt is the most useful thing you can be."

Warm-up (3 min): "Walk me through how you picked the last place you ate that wasn't routine."
Core tasks 1–6 below, in order. Task 6 has two variants; alternate them across sessions.
Wrap (3 min): "If this existed tomorrow, when would you actually open it? What would make you delete it?"

#	Task (read aloud)	Tests	Success criteria
1	"You have 20 minutes to decide on dinner. Use the app to pick something."feed	Photo-only info scent (Exploration A)	Reaches a decision ≤5 min; note every detail-open made only to check price/distance
2	"What made you choose that one? What information did you use?"	Decision drivers	Articulates photo + at least one non-photo signal without prompting
3	"Save that dish to your Date night list."save flow	Instant save + opt-in collection model	Completes via toast or detail heart ≤3 taps after save; no hunting for the sheet
4	"Find ramen near you."search	Search entry + labeled results	Uses search chip (not scrolling); interprets result labels correctly
5	"This dish says 90% would order again. What do you think that means — who counted that?"trust	Trust-signal comprehension (Exploration C)	Describes repeat orders / verified diners, not star-like satisfaction; bonus if they find "how we know"
6a	"Set the price filter to $ and distance to 'Steps away'. What happened, and how do you get dishes back?"recovery	Zero-result recovery	Identifies which limits caused it; uses the correct button to recover
6b	"You're visiting Los Angeles next week. Point the app there."location	No-coverage honesty	Understands why the feed is empty; finds the way back; no belief that the app is broken

Follow-ups — always non-leading: "What did you expect to happen?" · "What would you do next?" · "You hesitated there — what were you weighing?" · "Say more about that face you made." Never: "Did you like…", "Wasn't that easy?"

Round 2 — dedicated safety round

Participants — 4 sessions + 1 domain review

4 participants who manage a real food allergy — their own or a household member's. Recruited separately from Round 1; the allergy model must be tested by the people it exists for, not simulated by proxies.
1 domain review session with a food-allergy professional (registered dietitian, allergy nurse/educator, or a food-service allergen-compliance manager): walk the full allergy path and the copy, and ask where the design overstates what it can promise.
Same moderator script as Round 1, plus: "This app can flag allergens in its data, but it can never guarantee a kitchen is safe — I want to know if the design makes that clear or blurs it."

#	Task (read aloud)	Tests	Success criteria
S1	"Set up the app the way you would for your own allergy, then tell me what you expect it to do from now on."setup	Three-tier dietary model comprehension	Finds setup; expectation matches the promise: excluded from feed/search, saved dishes kept + warned — and not "the app keeps me safe"
S2	"Open the dan dan noodles you saved earlier." (conflicting save present)retained save	Conflict warning on retained saves	Notices the warn chip and banner; explains why it's still visible in their saves
S3	"A friend sends you this dish. What is the app telling you?" (direct-open conflict)direct open	Direct-open warning comprehension	Reads contains-X + why-visible + confirm-with-kitchen as three distinct facts
S4	"Go ahead and order it anyway."gated handoff	Acknowledgement-gated order sheet	Understands why providers are locked; the acknowledgement reads as a deliberate safety step, not a nag; warning persists after unlock
S5	"Search for that dish by name. What is the app telling you now?"search	Diet-aware empty state	Distinguishes "doesn't exist here" from "excluded by my settings"; knows allergy rules are edited deliberately, never by "clear filters"

Any misreading of the allergy promise in Round 2 is S1 by default. The prototype's own framing under test: Morsel is allergy-aware, never allergy-safe — diners must confirm ingredients and preparation with the restaurant.

Observation table

One row per participant × task. Print or duplicate per session.

Task	Completion	Misclicks	Confidence (1–5, self-report)	Quotes / behavior	Severity
1	✓ / partial / ✗	count + where	"How sure are you that was a good pick?"
…

Severity scale

S1 — safety/trust breach: user misunderstands the allergy promise or the trust metric in a way that could cause harm or distrust. Fix before any release.
S2 — task blocker: cannot complete a core task (choose, save, order handoff) without moderator help.
S3 — friction: completes with detours, misclicks, or visible hesitation.
S4 — polish: cosmetic or preference-level.

Findings → iteration matrix

Finding (evidence)	Sessions	Severity	Hypothesis	Design response	Owner / status
Fill after sessions — one row per distinct finding, merged across participants.

Before / after template

For each S1–S2 finding that changes the design, produce one before/after pair for the case study:

Before: screenshot of the v3.1 state + one-line finding ("4/5 read 90% as a satisfaction score").
After: screenshot of the revised state + what changed and why it addresses the evidence.
Verdict line: how you'll know it worked (re-test criterion or metric).

Keep pairs at identical crop/zoom so the change reads instantly (template: two phone frames side by side, finding above, response below).

This plan is ready to run but has not been run — all findings tables are intentionally empty. Any populated example content elsewhere in the case-study package is labeled illustrative.