whiteport-design-studio 0.2.2 → 0.3.0

package/docs/learn/module-17-usability-testing/lesson-01-spec-verification.md

@@ -0,0 +1,243 @@
+# Module 17: Usability Testing
+
+## Lesson 1: The Test Scenario
+
+**Preparing everything before the user arrives**
+
+---
+
+## Why Planning Matters More Now
+
+When building takes an afternoon, you can't afford to spend a week planning a test. But you also can't afford to waste a test session because you weren't prepared.
+
+The test scenario is your script. It ensures every participant gets the same experience, every task is clear, and you know exactly what to observe. Create it once, use it for every session.
+
+---
+
+## Pick One Flow
+
+Don't test the whole product. Test one flow.
+
+A flow is a complete user journey with a beginning and an end:
+- Creating an account
+- Booking an appointment
+- Finding and purchasing a product
+- Changing account settings
+
+**Good test candidates:**
+- The primary journey (what most users do first)
+- A flow you're uncertain about
+- A flow with many steps or decision points
+- A flow that's critical for business goals
+
+---
+
+## Write the Tasks
+
+Tasks are what you'll ask the participant to do. They describe a goal — not a path.
+
+### Good Tasks
+
+- "You want to try this product. Go ahead and create an account."
+- "You received an email about your upcoming appointment. Find the details."
+- "You want to stop receiving email notifications. See if you can figure out how."
+
+Each task:
+- Describes what the user wants to achieve
+- Doesn't say where to click or what to look for
+- Uses language a real user would think in
+- Is completable in 2-5 minutes
+
+### Bad Tasks
+
+- "Test the signup form" — What should they actually do?
+- "Click the blue button and fill in your email" — You're giving them the answer
+- "Navigate to Settings, then Notifications, then toggle Email off" — Step-by-step instructions aren't a test
+
+3-5 tasks per session is enough. More than that and participants get tired, which affects the quality of later tasks.
+
+---
+
+## Select Participants
+
+### How Many
+
+3-5 people per test round. Research shows 5 users find approximately 85% of usability problems. Three is the minimum for spotting patterns.
+
+### Who
+
+They should match your personas — or at least be reasonably close. If your persona is a dog trainer with moderate tech comfort, don't test on software developers.
+
+**Where to find them:**
+- Existing users of similar products
+- Friends or colleagues who match the persona's profile
+- People from your professional network
+- Community groups related to your product's domain
+
+**Who to avoid:**
+- Yourself (you already know how it works)
+- Other designers on the project (same problem)
+- Anyone who has seen the specifications or design
+- People who will tell you what you want to hear instead of what they actually think
+
+### When to Recruit
+
+**Before you start building.** This is the key insight.
+
+Send a message while the prototype is still being built:
+
+> "Hi! I'm working on a product and would love 20 minutes of your time to try it out sometime this week. No preparation needed. Would you be available?"
+
+When the prototype is ready, they're ready. No delay.
+
+---
+
+## Prepare the Materials
+
+### The Introduction Script
+
+Write it down. Read it the same way to every participant:
+
+```
+"Thanks for helping me with this. A few things before we start:
+
+I'm testing the design, not you. There are no wrong answers
+and you can't do anything wrong.
+
+I'll give you a few tasks to try. Please think out loud as you
+go — tell me what you're looking at, what you're thinking,
+what you expect to happen.
+
+I won't be able to help you during the tasks. If you get stuck,
+that's valuable information for me. Just do what you would do
+if I weren't here.
+
+Any questions before we start?"
+```
+
+Same words, same tone, every time. This removes you as a variable.
+
+### Task Cards
+
+Write each task on a separate card or in a separate message. Present them one at a time. The participant should only see the current task.
+
+```
+Task 1:
+"You've heard about [product name] and want to try it.
+Go ahead and create an account."
+```
+
+### The Observation Sheet
+
+Prepare a simple sheet for each session:
+
+```markdown
+# Usability Test: [Flow Name]
+## Participant: P[#]
+## Date:
+## Location:
+## Device:
+
+### Task 1: [Task name]
+- Started:
+- Completed: Yes / No
+- Time:
+- Notes:
+
+### Task 2: [Task name]
+- Started:
+- Completed: Yes / No
+- Time:
+- Notes:
+
+### Task 3: [Task name]
+- Started:
+- Completed: Yes / No
+- Time:
+- Notes:
+
+### Post-session notes:
+```
+
+### Recording Setup
+
+Decide how you'll record and test it before the session.
+
+**At their location (preferred):**
+- Phone camera capturing screen + hands
+- Screen recording on their device (ask permission first)
+- Both if possible — screen for details, camera for reactions
+
+**Remote (when necessary):**
+- Video call with screen sharing and recording
+- Less ideal than contextual, but far better than no testing
+
+**Always ask permission to record.** Explain that it's for your review only and won't be shared.
+
+---
+
+## The Complete Test Scenario Document
+
+Put it all together:
+
+```markdown
+# Test Scenario: User Registration Flow
+
+## Flow Under Test
+User registration from landing page through account creation
+to welcome dashboard.
+
+## Prototype
+[URL or file path to the prototype]
+
+## Participants
+- 3-5 people matching Felix persona (moderate tech comfort)
+- Recruited: [date]
+- Sessions scheduled: [dates]
+
+## Introduction Script
+[The script above]
+
+## Tasks
+1. "You've heard about [product] and want to try it.
+   Go ahead and create an account."
+
+2. "You just created your account. Take a look around —
+   what can you do here?"
+
+3. "You want to change your email notification preferences.
+   See if you can find where to do that."
+
+## What to Observe
+- Can they find the registration CTA?
+- Do they understand the form fields?
+- Do error messages help them recover?
+- Do they know what to do after registration?
+- Can they navigate to settings?
+
+## Recording Method
+Phone camera + screen recording
+
+## Post-Session Questions
+- What stood out to you?
+- Was anything confusing or unexpected?
+- If you could change one thing, what would it be?
+```
+
+This document is your preparation. When you arrive at the participant's location, you know exactly what to do.
+
+---
+
+## What's Next
+
+The scenario is ready. In the next lesson, you'll learn how to conduct the session — and why not helping is the hardest part of the job.
+
+---
+
+**[Continue to Lesson 2: Conducting the Test →](lesson-02-test-results.md)**
+
+---
+
+[← Back to Module Overview](module-17-usability-testing-overview.md)
+
+*Part of Module 17: Usability Testing*

package/docs/learn/module-17-usability-testing/lesson-02-test-results.md

@@ -0,0 +1,240 @@
+# Module 17: Usability Testing
+
+## Lesson 2: Conducting the Test
+
+**The session, the silence, and the replay**
+
+---
+
+## Consistency Is Everything
+
+Every participant must get the same test. Same introduction. Same tasks. Same conditions.
+
+If you explain the interface to participant 2 but not participant 1, you can't compare their results. If you give participant 3 a hint because they're struggling, their "success" is meaningless.
+
+The test scenario from Lesson 1 is your script. Follow it.
+
+---
+
+## Arrive and Set Up
+
+### At Their Location (Preferred)
+
+You go to them. Their home, their office, their desk. They use their own device, their own browser, their own chair.
+
+Set up your recording before they sit down:
+- Position your phone camera where it captures the screen and their hands
+- Start screen recording on their device (with permission)
+- Make sure everything is working before they start
+
+### Remote (When Necessary)
+
+Start the video call. Ask them to share their screen. Begin recording.
+
+Remote is less ideal — you miss body language, environmental context, and the natural pace of their interaction. But it's infinitely better than not testing.
+
+---
+
+## Read the Introduction
+
+Read your introduction script exactly as written. Same words every time.
+
+```
+"Thanks for helping me with this. A few things before we start:
+
+I'm testing the design, not you. There are no wrong answers
+and you can't do anything wrong.
+
+I'll give you a few tasks to try. Please think out loud as you
+go — tell me what you're looking at, what you're thinking,
+what you expect to happen.
+
+I won't be able to help you during the tasks. If you get stuck,
+that's valuable information for me. Just do what you would do
+if I weren't here.
+
+Any questions before we start?"
+```
+
+Answer any questions about the process. Don't answer questions about the product.
+
+---
+
+## Present the Task
+
+Give them one task at a time. Read it aloud. Hand them the card or send the message.
+
+> "You've heard about [product name] and want to try it. Go ahead and create an account."
+
+Then stop talking.
+
+---
+
+## The Silence
+
+This is the hardest part of usability testing. You must not help.
+
+### Don't Help
+
+The user clicks the wrong thing. You know the right answer. You want to say "try the button on the left." **Don't.**
+
+Their wrong click is your data. It tells you the design failed to guide them. If you help, you lose that information.
+
+### Don't Discuss
+
+They say "is this where I'm supposed to go?" You want to confirm or redirect. **Don't.**
+
+Say: "What do you think?" or "What would you do if I weren't here?"
+
+### Don't Explain
+
+They're confused by a label. You want to explain what it means. **Don't.**
+
+If the label needs explaining, the label is wrong. That's a finding.
+
+### Deflect Questions
+
+They will ask you questions. It's natural. They want to do well. Deflect every one:
+
+| They say | You say |
+|----------|---------|
+| "Is this right?" | "There's no right or wrong. What do you think?" |
+| "Should I click here?" | "Go ahead and do whatever feels natural." |
+| "What does this mean?" | "What do you expect it to mean?" |
+| "Am I doing this correctly?" | "You're doing great. Just keep going." |
+| "I'm stuck, can you help?" | "What would you try if I weren't here?" |
+
+### When It's Painful
+
+You will watch someone struggle for 30 seconds on something that takes 2 seconds if you explain it. It will feel wrong. It will feel rude. Do it anyway.
+
+That 30-second struggle is the most valuable data you'll collect. It reveals exactly where the design fails.
+
+**The only exception:** If the user is genuinely distressed — frustrated to the point of being upset — move to the next task. Say: "Let's skip this one and try the next task." Note it as a critical finding: task abandoned due to user frustration.
+
+---
+
+## What to Observe
+
+While they work, take notes on your observation sheet. Use timestamps.
+
+### Behavioral Signals
+
+- **Hesitation** — They pause before clicking. What are they deciding between?
+- **Scanning** — Their eyes search the page. What are they looking for that isn't obvious?
+- **Backtracking** — They go back. Their expectation didn't match reality.
+- **Misclicks** — They click the wrong element. What did they think it would do?
+- **Speed** — Fast and confident, or slow and uncertain?
+
+### Verbal Signals
+
+Listen for think-aloud comments:
+
+- "Oh, I expected..." — Their mental model doesn't match the design
+- "Where is the..." — Navigation or visual hierarchy problem
+- "What does this mean?" — Label or messaging failure
+- "I think I need to..." — They're guessing, not knowing
+- "Oh!" — Surprise, positive or negative
+
+### Completion
+
+For each task, note:
+- Did they complete it? Yes / No
+- How long did it take?
+- How many wrong paths did they try?
+- Did they seem confident or uncertain at the end?
+
+---
+
+## Between Tasks
+
+Brief pause. "How was that?" Listen to any immediate reaction. Keep it to 30 seconds.
+
+Don't explain what they "should have done." Don't reveal the intended path. Don't discuss the design.
+
+Present the next task card.
+
+---
+
+## After All Tasks
+
+### Quick Debrief (2 minutes)
+
+Ask open questions:
+
+- "What stood out to you?"
+- "Was anything confusing or unexpected?"
+- "If you could change one thing, what would it be?"
+
+These questions sometimes surface things you didn't observe. But keep it brief — the real value was in watching their behavior.
+
+---
+
+## The Retrospective Replay
+
+This is the most powerful part of the session.
+
+### How It Works
+
+After the tasks and debrief, play the recording back to the participant. Watch it together.
+
+At key moments — hesitations, wrong clicks, confusion — pause and ask:
+
+- "What were you thinking here?"
+- "I noticed you paused — what was going on?"
+- "You went back here — what did you expect to find?"
+- "You clicked this — what did you think it would do?"
+
+### Why It Works
+
+During the tasks, the user is focused on performing. They can't fully explain their thinking in the moment, even with think-aloud.
+
+In the replay, the pressure is off. They see their own behavior from the outside and can articulate what was actually happening in their head. This produces insights you can't get any other way.
+
+> "Oh yeah, here I was looking for a 'Sign Up' link in the menu because that's where I usually find it on other sites. I didn't realize the big button was for registration."
+
+That explanation is worth more than 10 minutes of guessing at what went wrong.
+
+### When to Use the Replay
+
+- **Always** for formal sessions on critical flows
+- **Optional** for guerrilla tests or quick checks
+- **Skip** if the participant is short on time — ask if they have 10 more minutes
+
+---
+
+## Close the Session
+
+Thank them sincerely. They gave you their time and their honesty.
+
+A coffee, a gift card, or a genuine thank you — acknowledge their contribution. They helped make the product better.
+
+---
+
+## Guerrilla Testing
+
+Not every test needs the full process.
+
+**The 5-minute test:** Grab someone nearby. Show them the prototype. "Can you sign up for an account?" Watch what happens. No recording, no replay, just observation.
+
+Guerrilla testing is imperfect. The participant probably doesn't match your persona. There's no recording to review. But it catches obvious problems you've become blind to.
+
+**Use it:** During development, between build steps, for quick sanity checks.
+
+**Don't use it:** For critical flows, when persona match matters, when you need evidence for stakeholders.
+
+---
+
+## What's Next
+
+You have recordings and observation notes. In the next lesson, you'll turn them into findings that connect back to your specifications and drive real design improvements.
+
+---
+
+**[Continue to Lesson 3: Acting on Findings →](lesson-03-acting-on-findings.md)**
+
+---
+
+[← Back to Lesson 1](lesson-01-spec-verification.md) | [Back to Module Overview](module-17-usability-testing-overview.md)
+
+*Part of Module 17: Usability Testing*