Usability Test Plan & Findings

What you'll produce

A Usability Test Plan & Findings report for the FreshCart checkout prototype you built in Deliverable 3 — a short, two-part document that first plans a test (a goal, realistic task scenarios, and exactly what you'll watch for) and then reports what happened when ~5 real people tried it: where they hesitated, the issues ranked by severity against named usability heuristics, and the prioritized fixes you actually made to the prototype. This is the deliverable that separates a designer from a decorator. Anyone can draw screens; a UX/UI designer can prove a design works — or honestly admit where it doesn't — by watching real people use it and letting that observation drive the next iteration. "I tested this with five users and here's what I changed" is the single most persuasive sentence in a portfolio review and a design interview, and this report is where you earn the right to say it.

Instructions

1. Write a one-line test goal and your top open question. State what you're trying to learn, framed as a doubt, not a wish — e.g. "Can a first-time FreshCart shopper get from the home screen to a placed order in under 3 minutes without help, and where exactly do they stall?" If you're secretly trying to confirm your design is good, you'll run a bad test. Aim to find problems.

2. Define a success metric per task before you test, so a result can't be argued away later: a target completion rate, a target time, and the number of moments you needed to step in ("assists"). Decide these now — afterward you'll be tempted to move the goalposts.

3. Write 2–4 realistic task scenarios as goals, not instructions. Say "You want fresh ingredients for tonight's dinner delivered — go ahead and place an order" — never "tap the Search icon, then add Bananas, then tap Cart." Naming the buttons tells the user the answer and destroys the test. Each scenario needs a clear, observable success state ("order confirmation screen reached").

4. List exactly what you'll observe. For each task, write the specific signals: completion (yes/no), time on task, number of assists, error paths taken (wrong taps, backtracks), points of hesitation, and verbatim quotes. You can only see what you decide to look for.

5. Recruit ~5 participants who match your persona, not your friends who already know the app. Five is not a budget compromise — it's the number that surfaces the large majority of usability problems. Note one screening fact per person (e.g. "orders groceries online monthly, never used FreshCart"). No user pool and doing this solo at home? You still have four real paths — pick whichever you can finish this week, and write down which one you used. The bar is the same for all of them: 5 people, persona-matched, prototype-blind (they've never seen your design), one screening fact logged each.

   • Unmoderated remote test (fastest; small cost or free tier): Upload the Figma prototype to Maze, UserTesting, Useberry, or Lyssna/UserCrowd, write your tasks once, and use the tool's panel to target the persona ("orders groceries online ≥ monthly, owns a smartphone, ages 25–45"). It records screen + think-aloud audio from 5 strangers and you watch the replays — you don't need to be present, and you never met them, so no one knows the "answer."
   • Post your own screener (free; costs time): Drop a one-paragraph screener in a relevant subreddit, a Discord/Slack community, a neighborhood Facebook group, or a campus board: "Do you order groceries online at least monthly? Never used FreshCart? 15-min video call, I'll send a $5 coffee card." Screen before scheduling — accept only people who match the persona and have never seen your prototype — then run it over Zoom/Meet with screen-share.
   • Acquaintances who genuinely match — and are blind to the design: A cousin, neighbor, or coworker from another team is fine only if they fit the persona, have never opened your Figma file, and you can resist coaching them. The disqualifier isn't "I know them," it's "they already know where to tap." Your roommate who watched you build it is out; an aunt who orders groceries online weekly and has never seen the prototype is a valid participant.
   • In-person intercept (zero cost, in an afternoon): Ask 5 matching strangers in a café, library, or co-working space for 10 minutes each. Hand them your phone with the prototype open and the task on a card, then go quiet.

   Whichever path you pick, name your recruitment method in the report (e.g. "Recruited via a Maze unmoderated test, panel filtered to monthly online-grocery shoppers" or "5 acquaintances screened to the persona, none had seen the prototype"). Stating how you sourced and screened participants is itself a credibility signal — it shows the results came from the right people, not a convenience sample.

6. Run each session the same way: think-aloud, no rescuing. Ask them to narrate their thoughts out loud, give the task, then go quiet. When they get stuck, count to ten in your head and take notes — their struggle is your data. The instant you say "it's the button up top," you've thrown away that finding.

7. Log raw observations per participant in a simple table — task, completed?, time, assists, and where they stalled — before you interpret anything. Keep facts separate from your theories about them.

8. Cluster observations into distinct issues and rank each by severity (a 0–4 scale: 0 = not a problem, 1 = cosmetic, 2 = minor/annoying, 3 = major/blocks many users, 4 = catastrophic/blocks the task). Severity is roughly frequency × impact — an issue 4 of 5 people hit that stops the order outranks one cosmetic gripe.

9. Tag each issue with the usability heuristic it violates (visibility of system status, match to the real world, consistency, error prevention/recovery, recognition over recall). The heuristic names the root cause and points to the fix — "people missed it" is an observation; "no visibility of system status" is a diagnosis.

10. Decide and document a fix for the top issues, then say what you changed in the prototype and what you'd re-test. Fixes are part of the deliverable — a report that finds problems but ships nothing proves you can critique, not design. Close with what you'd verify in a second round.

Rubric

The app's AI scores the learner's submission against these criteria and gives feedback. Levels: Needs work (1) / Solid (2) / Excellent (3). Passing = every criterion at Solid or above.

• Realistic task scenarios (goals, not instructions) — 1: tasks name the buttons/steps or aren't tied to the flow · 2: realistic goal-based tasks with observable success states · 3: tasks read like real first-timer goals, each with a pre-set success metric (rate/time/assists) that makes results undeniable.
• Unbiased test method & recruitment — 1: leading or rescuing the user, no think-aloud, or participants who already know the design · 2: think-aloud with no facilitator help, ~5 persona-matched users, and a stated way they were recruited · 3: clean think-aloud protocol, explicit "what I'll observe" list, and a concrete, prototype-blind recruitment method named (unmoderated panel like Maze/UserTesting, a posted screener, or genuinely-matching acquaintances who've never seen the prototype) — proving the 5 participants were sourced, not assumed.
• Findings grounded in observation — 1: opinions/assumptions about the design, not what users did · 2: concrete observations (stalls, errors, completion, quotes) per participant · 3: a clear facts-then-interpretation log with verbatim quotes and per-task data that visibly drives every issue.
• Severity ranking + heuristic diagnosis — 1: a flat list with no ranking or heuristics · 2: issues ranked by severity and each tagged to a usability heuristic · 3: severity reflects frequency × impact (the order-blocker outranks the cosmetic gripe) and each heuristic names the true root cause, not just the symptom.
• Prioritized fixes that drove iteration — 1: problems found but nothing changed · 2: a fix per top issue, applied to the prototype · 3: fixes clearly matched to the highest-severity issues, what changed in the prototype is specific, and each names what you'd re-test to confirm it worked.
• Coherence with prior deliverables — 1: disconnected from the case study · 2: tests the actual Deliverable 3 prototype and persona · 3: traces cleanly from the persona (D1) and flow (D2) through the prototype (D3), and the fixes set up the high-fidelity UI (D5).