Design Ops

Design Ops & Handoff

Operational processes that make design teams effective — sprints, handoff, rituals, documentation, and quality assurance.

---

Design Sprints

A 5-day process for solving big problems and testing ideas before committing engineering resources. Based on Jake Knapp's Sprint methodology developed at Google Ventures.

When to Sprint

The 5-Day Structure

Sprint Team

Sprint Rules

1. No devices during working sessions — full attention 2. Work alone together — individual sketching, not group brainstorming 3. The Decider decides — democracy is slow; one person breaks ties 4. Prototype, don't build — facade quality, not production quality 5. 5 users is enough — you'll see 85% of usability issues with 5 participants

---

Design-to-Development Handoff

Handoff is the #1 source of quality loss in product teams. The goal: engineers should never have to guess.

Handoff Maturity Levels

Target: Level 4 minimum. Level 5 for mature teams.

What a Complete Handoff Includes

Every screen or component handoff must cover:

Handoff Anti-Patterns

---

Team Rituals and Cadences

Core Design Rituals

Running Effective Design Critiques

Format: Presenter shares context (2 min) → Group reviews silently (3 min) → Structured feedback (15-20 min per piece) → Next steps (2 min)

Critique rules: 1. Presenter states what feedback they want — "I need help with the empty state" not "What do you think?" 2. Feedback references principles, not preferences — "This violates Fitts's Law" not "I don't like the button placement" 3. Describe problems, don't prescribe solutions — "Users might miss this action" not "Make the button bigger" 4. No defending — presenter listens, asks clarifying questions only 5. Written notes — someone captures all feedback items with action owners

Handoff Session Structure

1. Context (5 min) — What problem does this solve? What user story? 2. Walkthrough (10-15 min) — Designer walks through the flow, screen by screen 3. States and edge cases (10 min) — Hover, error, empty, loading, responsive 4. Tokens and components (5 min) — Which design system components to use, which tokens 5. Questions (10 min) — Engineers ask anything unclear 6. Action items — What needs clarification before build starts

---

Documentation Standards

File Organization

project-name/
├── exploration/          # Early concepts, discarded directions
│   └── v1-concepts/
├── current/              # Active, approved designs
│   ├── flows/            # User flows and journey maps
│   ├── screens/          # Screen-level designs
│   └── components/       # Component-level specs
├── assets/               # Production-ready exports
│   ├── icons/
│   └── images/
├── handoff/              # Handoff documentation
│   └── [feature-name]/
└── archive/              # Past versions (never delete, move here)

Naming Conventions

Version Control Rules

1. Never overwrite — create a new version, archive the old one 2. Name the change — "v2.1 — added error states" not just "v2.1" 3. Link to decisions — every major version links to the decision that drove it (Slack thread, meeting note, sprint review) 4. Single source of truth — one canonical file per feature. No "copy of" files 5. Archive, don't delete — move outdated designs to archive with a date stamp

---

Design QA

Design QA is the process of verifying that what was built matches what was designed. Do it before every release.

Design QA Checklist

Filing Design QA Issues

Every issue needs:

**What:** [Element name] on [screen/page]
**Expected:** [What the design spec shows — link to frame]
**Actual:** [What the build shows — screenshot]
**Severity:** [Critical / Major / Minor / Cosmetic]
**Environment:** [Browser, viewport, OS]

Severity scale:

• Critical — Functionality broken. User can't complete the task
• Major — Wrong behavior. User can complete the task but with confusion or errors
• Minor — Visual discrepancy. User isn't affected functionally but quality feels off
• Cosmetic — Nitpick. Pixel-level differences that only designers notice

Acceptance Criteria for Design

Add these to every user story:

Design acceptance criteria:
- [ ] All states match design spec (link to Figma frame)
- [ ] Responsive behavior verified at 320px, 768px, 1024px, 1440px
- [ ] Keyboard navigation works (Tab, Enter, Escape, Arrow keys)
- [ ] Screen reader announces all interactive elements correctly
- [ ] Design tokens used (no hardcoded colors, spacing, or typography)
- [ ] Loading and error states implemented
- [ ] Edge-case content tested (empty, long strings, special characters)

---

Process Metrics

Track these to measure design ops health:

---

Scaled-Down Operations for Lean Teams

The processes above assume a dedicated design team. But many organizations have a single designer — or someone who does design as part of a broader role. The principles still apply; the execution scales down. This section provides adapted methods for resource-constrained teams, drawing on Leah Buley's UX team-of-one framework.

The Core Mindset

1. Focus on small wins. You can't transform the organization overnight. Pick one visible improvement, deliver it, and let the result build momentum for the next 2. Build a user-centered culture, not a UX department. Your goal isn't to own all design work — it's to make everyone on the team think about users 3. Develop a growth mindset. Seek opportunities to expand skills incrementally. You don't need permission to start practicing research or testing

Guerrilla Methods

When you don't have budget, time, or formal research infrastructure:

Building Relationships and Advocacy

As a solo or lean-team designer, your effectiveness depends on relationships more than process.

Earn a seat at the table:

• Start by meeting the team's immediate needs — even grunt work builds goodwill
• Show, don't tell. A quick prototype that surfaces a problem is worth more than a presentation about UX maturity
• Connect UX work to metrics leadership already cares about (conversion, support tickets, retention)

Influence without authority:

• Frame recommendations as experiments, not mandates: "Can we test this with 3 users before committing?"
• Share research findings in the format your audience consumes — Slack summary for engineers, dashboard for leadership, annotated screenshots for PMs
• Present findings with confidence but invite collaboration: "Here's what we learned — what does this mean for your area?"

Adapted Rituals for Solo/Lean Teams

Scaled-Down Handoff

When full specs aren't practical:

1. Annotate in-context. Add behavior notes directly on Figma frames — don't create a separate spec document 2. Prioritize what's ambiguous. Don't spec obvious things. Focus on states, transitions, and edge cases that engineers would have to guess 3. Walk through once, document questions. A 15-minute walkthrough call + a list of engineer questions answered in Figma comments is often enough 4. Build shared vocabulary early. If you and the engineer agree on component names and token usage, you need fewer words in every handoff

The Power of Small Wins

Track and communicate your impact, even informally:

• "We tested the new flow with 3 users — 2 couldn't find the save button. We moved it, and support tickets for that flow dropped 40%"
• "The assumption map revealed we had no data on how users think about billing. Two interviews later, we redesigned the billing page before engineering started"
• "Adding a design QA step to PRs caught 12 visual bugs this quarter that would have shipped"

Small wins compound. Each one makes the next conversation about investing in design easier.

---

Common Mistakes

Design Sprint Walkthrough

Running a 5-day design sprint for a fictional onboarding problem.

---

Context

Product: MealPlan — a meal planning and grocery list app for busy families Challenge: 60% of new users abandon the app before completing onboarding. The team has ideas but no consensus on the right approach. Engineering is about to commit 2 months to building onboarding v2. Why a sprint: High stakes (2 months of engineering), high uncertainty (multiple competing ideas), need evidence before committing.

---

Pre-Sprint

Team Assembled

Logistics

• Room: Conference room B, booked Mon-Fri 10am-5pm
• Materials: 2 whiteboards, 200 stickies, dot stickers, markers, timer, printer paper
• Participants: 5 users recruited for Friday (parents who cook 3+ times/week, installed a cooking or meal app in the past 6 months)
• Prototype tool: Figma

---

Monday: Map

Long-Term Goal

"MealPlan helps busy families eat home-cooked meals every weeknight without the stress of planning."

Sprint Questions

1. Can we get users to their first meal plan in under 3 minutes? 2. Will users provide dietary preferences upfront, or does that feel like too much work? 3. Is the grocery list the hook that makes users come back, or is it the meal suggestions?

Problem Map

[New User Downloads App]
  → Opens app for the first time
    → Sees welcome screen
      → Creates account (email or Google)
        → Dietary preferences screen (6 questions)
          → 🔴 38% drop off here
        → Family size screen
          → Cooking skill screen
            → Generate first meal plan
              → 🔴 22% drop off here (plan feels generic)
            → View grocery list
              → 🔴 Users don't understand how to customize
            → Cook first meal
              → ✅ Users who cook one meal have 4x retention

Expert Interviews

Carlos (Data):

• The 6-question dietary preferences screen is the biggest drop-off. Average completion time for the full onboarding is 4 minutes 20 seconds. Users who complete it rate the app 4.2/5. Users who don't — 2.1/5
• Insight: Users who reach the meal plan like it. The problem is getting them there

Nadia (Support):

• Top complaint: "The meal plan didn't feel personalized." Second: "I don't have time for all these questions." Third: "I couldn't figure out how to change a meal"
• Insight: There's a tension between personalization (needs data) and speed (questions feel like work)

Guest expert — Lisa (Nutritionist):

• Only 2 preferences really matter for a good first plan: allergies and number of servings. Everything else can be refined later
• Insight: We're asking 6 questions when 2 would work for a first plan

How Might We (Top Voted)

1. HMW get users to a personalized plan with only 2 questions? (12 votes) 2. HMW let users customize the plan by doing, not answering questions? (9 votes) 3. HMW show the value of the grocery list before asking users to set preferences? (7 votes) 4. HMW make the first plan feel personal even with minimal data? (6 votes)

Target

We're focusing on: The journey from "open app for the first time" to "see a meal plan that feels personal enough to try." Specifically, reducing the preferences barrier while maintaining plan quality.

---

Tuesday: Sketch

Lightning Demos

Big idea captured: "Show food first, ask questions later" — let users interact with meals and infer preferences from behavior.

Solution Sketches (5 individual sketches)

Jake's sketch: "Swipe to Plan"

• User sees 10 meal photos, swipes right (yes) or left (no) — Tinder-style
• After 10 swipes, app generates a personalized plan
• Allergies asked only if a swiped meal contains common allergens

Priya's sketch: "Quick Start Template"

• User picks one of 4 templates: "Family Favorites," "Quick & Easy," "Healthy," "Budget"
• Plan generates instantly from template. User customizes by swapping meals
• Preferences learned from swaps over the first week

Maria's sketch: "Guided First Meal"

• Skip all preferences. Show one great-looking meal with a recipe
• After cooking it: "Want a full week of meals like this? Let's set up your plan"
• Hook first, setup second

Nadia's sketch: "Visual Preferences"

• Instead of text questions, show grids of food photos
• "Tap meals your family loves" — tap 5-10 photos
• "Any allergies?" — single multi-select
• Plan generated from food photos selected

Carlos's sketch: "Progressive Profile"

• 2 questions only: allergies + household size
• Generate a "starter plan" immediately
• Each day, one optional question appears (cooking time, cuisine preference, budget)
• Plan improves gradually over the first week

Key Ideas Across Sketches

• Everyone favors showing food visually over text-based questions
• 3/5 sketches defer most preferences to after the first plan
• The "meals first, questions later" theme from lightning demos came through strongly

---

Wednesday: Decide

Heat Map

Heaviest dot clusters on:

• Nadia's "Visual Preferences" — the photo grid for food selection got 15+ dots
• Carlos's "Progressive Profile" — the "2 questions + starter plan" got 12+ dots
• Jake's "Swipe to Plan" — the swipe mechanic got 10+ dots, but concerns about being gimmicky

Speed Critique

Decider's Decision

Maria chose: A hybrid of Nadia's Visual Preferences + Carlos's Progressive Profile.

Rationale: "We need the first plan to feel personal — that's what Carlos's data shows. But we need to get there fast — that's what the drop-off data demands. Visual preferences give us rich data in a fun, fast format. Then progressive refinement continues improving without asking users to fill out forms."

Storyboard (10 frames)

1. Open app — Warm welcome screen. "Let's find meals your family will love." One CTA: "Get Started" 2. Allergies — "Any allergies in your household?" Multi-select chips: Dairy, Gluten, Nuts, Eggs, Shellfish, Soy, None. 1 tap to 3 taps 3. Family size — "How many are you feeding?" Stepper: 1-8. Default: 4 4. Photo grid — "Tap meals that look good to you" — Grid of 12 meal photos (diverse cuisines, complexities). User taps 3-5. Each tap adds a subtle heart animation. Progress: "3 of 5 selected" 5. Generating — Brief loading animation: "Creating your meal plan..." with a fun illustration of ingredients assembling 6. Your plan — Weekly view with 5 dinner meals. Each card shows photo, title, time, servings. Header: "Your Starter Plan — swipe any meal to swap it" 7. Swap interaction — User taps a meal they don't like → slides out, 3 alternatives slide in → tap to select. The app learns from swaps 8. Grocery list — "Your grocery list is ready" — organized by store section. Badge shows "23 items for 5 meals" 9. Cook prompt — Next day notification: "Tonight's meal: Chicken Stir Fry. Ready in 25 min." Deep link to recipe 10. Progressive question — After cooking first meal: "How'd it go? Quick question to improve next week's plan" — one refinement question (cooking time preference)

---

Thursday: Prototype

Team Roles

Prototype Details

• Tool: Figma with prototype interactions
• Fidelity: High visual (real photos, real copy, real layout) with simplified interactions (tap targets, not real swiping)
• Scope: Frames 1-8 fully interactive. Frames 9-10 shown as static concept screens
• Meal data: 12 real meals for the photo grid, 5 for the plan, 9 alternatives for swaps. All with real recipe names, times, and photos

End-of-Day Run-Through

• [x] Full flow works: welcome → allergies → family size → photo grid → generating → plan → swap → grocery list
• [x] Real copy throughout (Nadia wrote all of it)
• [x] Meal photos look appetizing and diverse (Carlos sourced 30, selected 26)
• [x] Swap interaction works (tap to reveal alternatives, tap to select)
• [x] One issue found: the "generating" screen felt too fast — couldn't read the text. Added 2-second minimum display time

---

Friday: Test

Participant Profiles

Observation Grid

Patterns

Sprint Decision

Decision: GO — build it.

Reasoning: 5/5 users completed the flow in under 3 minutes (answering sprint question #1). 4/5 felt the plan was personalized enough to try (answering #2). The grocery list emerged as the retention hook (partially answering #3 — it's the list, not the suggestions). Two adjustments needed: make swap discoverable, add prep time to cards.

Sprint questions answered: 1. Can we get users to their first meal plan in under 3 minutes? Yes — average 2:10 2. Will users provide dietary preferences upfront? Yes, when visual. Photo grid averaged 45 seconds and felt fun, not like work 3. Is the grocery list the hook? Yes — 4/5 users called it out as the most valuable part

---

Next Steps

---

Key Takeaways

1. Visual preference selection replaced 6 text questions with a faster, more engaging, and data-richer experience. Users loved it 2. The "2 questions + photo grid" approach proved that minimal upfront effort can produce plans that feel personalized 3. The grocery list was the sleeper hit — the team was focused on the meal plan, but users were most impressed by the automatic grocery list 4. Swap discoverability was the only real miss — easy fix with a tooltip or animation. The sprint caught this before 2 months of engineering 5. The sprint saved the team from building the wrong thing — the original plan was to improve the 6-question form. The sprint showed the form was the problem, not the solution

Handoff Walkthrough

End-to-end handoff of a feature from design to engineering, including preparation, the handoff session, and post-handoff QA.

---

Context

Product: TaskPilot — web-based task management app Feature: Inline task editing — users can edit task title, due date, priority, and assignee directly from the task list without opening the detail panel Designer: Jamie Engineer: Sam (frontend) + Robin (backend) Sprint: Sprint 14

Why this feature: The interaction audit (see interaction-design examples) identified that editing a task required opening a detail panel — 3 extra clicks for a quick change. Users edit tasks 12x/day on average. Reducing this to inline editing saves ~36 unnecessary clicks per day.

---

Step 1: Pre-Handoff Preparation

Jamie's Handoff Checklist

Figma Organization

TaskPilot — Task List Inline Editing v1.0
├── 📄 Cover (status, links, changelog)
├── 📄 User Flow
│   └── Flow diagram: click-to-edit → edit → save/cancel
├── 📄 Task Title — Inline Edit
│   ├── Section: States (default, hover, editing, saving, error)
│   ├── Section: Responsive (desktop, tablet, mobile)
│   └── Section: Edge Cases (long title, empty title)
├── 📄 Due Date — Inline Edit
│   ├── Section: States
│   ├── Section: Responsive
│   └── Section: Edge Cases (past date, no date, date picker overflow)
├── 📄 Priority — Inline Edit
│   ├── Section: States
│   └── Section: Responsive
├── 📄 Assignee — Inline Edit
│   ├── Section: States
│   ├── Section: Responsive
│   └── Section: Edge Cases (unassigned, team > 10 people)
└── 📄 Keyboard Navigation
    └── Full tab order and keyboard interaction diagram

---

Step 2: Behavior Documentation

Jamie writes behavior notes directly on the Figma frames AND in a summary document linked from the ticket.

Task Title — Inline Edit

Trigger: Double-click on task title text, or focus the title with Tab and press Enter.

Sequence: 1. Title text transforms into a TextInput field (200ms crossfade) 2. Input is pre-filled with the current title, all text selected 3. User edits the text 4. Save on: Enter key, click outside (blur), or Tab to next field 5. Cancel on: Escape key (reverts to original title) 6. On save: input transforms back to text (150ms), API call fires 7. If API fails: text reverts, error toast appears

States:

Edge cases:

• Title > 200 characters: TextInput shows character count after 180 characters. Hard limit at 200. "23 characters remaining"
• Empty title: Prevent saving empty. Show inline validation: "Task title is required." Input border changes to color-border-error
• Title with only whitespace: Trim whitespace. If empty after trim, treat as empty
• Concurrent edit: Last write wins. If another user edited the title while this user was editing, show: "This title was just updated by [Name]. Your change will overwrite theirs." with Save/Cancel options

Tokens:

Background (editing): color-bg-input
Border (editing): color-border-focus (2px)
Border (error): color-border-error (2px)
Text: text-primary
Placeholder: text-placeholder
Transition: duration-fast (150ms), easing-standard

Due Date — Inline Edit

Trigger: Click on the due date text, or focus with Tab and press Enter/Space.

Sequence: 1. Date text is replaced by the DatePicker component (200ms, fade in from below) 2. DatePicker opens with current date selected (or today if no date set) 3. User selects a new date 4. On selection: DatePicker closes (150ms), new date displays, API call fires 5. Cancel on: Escape or click outside the DatePicker

Edge cases:

• Past dates: Allowed (tasks may have missed deadlines). Past dates show in color-feedback-error
• No date set: Shows "No due date" in text-tertiary. Click opens DatePicker with today highlighted
• Date picker overflow: On mobile, if the DatePicker would overflow the screen, it opens as a bottom sheet instead of a dropdown
• Relative dates: Display as relative when within 7 days ("Tomorrow," "In 3 days," "Yesterday"). Display as absolute date after 7 days ("Mar 28, 2026")

Priority — Inline Edit

Trigger: Click on the priority indicator, or focus with Tab and press Enter/Space.

Sequence: 1. Priority dropdown opens below the indicator (150ms, slide down) 2. Current priority is highlighted 3. Options: Urgent (red), High (orange), Medium (yellow), Low (gray) — each with color dot AND text label 4. User clicks/selects a priority 5. Dropdown closes (100ms), indicator updates, API call fires

Accessibility note: Priority is communicated by both color AND text label, never color alone. Screen reader announces: "Priority: [level]. Press Enter to change."

Assignee — Inline Edit

Trigger: Click on the assignee avatar, or focus with Tab and press Enter/Space.

Sequence: 1. Assignee popover opens (200ms, fade in) showing team members 2. Current assignee is highlighted with a checkmark 3. Search field at top for teams > 5 people (auto-focused) 4. User clicks a team member 5. Popover closes (150ms), avatar updates, API call fires

Simplified from current design: The current assignee flow requires 4 clicks (click → popover → search → select). The new design: click → popover with team visible → click to select. 2 clicks. Search is available but not required for small teams.

Edge cases:

• Unassigned: Shows a generic avatar placeholder with "+" icon. Click opens the same popover
• Team > 10 people: Search field is visible by default. Type to filter
• Team <= 5 people: No search field. All members visible at once
• Removed team member: If the assigned person left the team, show their avatar grayed out with a tooltip: "[Name] is no longer on this team. Reassign?"

---

Step 3: Keyboard Navigation Spec

Tab order within a task row:
[Checkbox] → [Title] → [Priority] → [Due Date] → [Assignee] → [Next row's Checkbox]

Keyboard interactions:
- Checkbox: Space to toggle
- Title: Enter to start editing, Enter to save, Escape to cancel
- Priority: Enter/Space to open dropdown, Arrow Up/Down to navigate, Enter to select, Escape to close
- Due Date: Enter/Space to open DatePicker, Arrow keys to navigate dates, Enter to select, Escape to close
- Assignee: Enter/Space to open popover, Arrow Up/Down to navigate, Enter to select, Escape to close

Focus management:
- After saving a title edit (Enter): focus moves to Priority (next field in the row)
- After selecting a priority: focus returns to the Priority indicator (stays on the row)
- After Escape from any editor: focus returns to the element that opened the editor
- After Tab from the last field in a row: focus moves to the next row's Checkbox

---

Step 4: Handoff Session

Date: Monday, Sprint 14, Day 1 Attendees: Jamie (designer), Sam (frontend), Robin (backend) Duration: 40 minutes

Walkthrough (15 min)

Jamie screen-shares Figma, walks through: 1. The user flow diagram — entry points, happy path, error paths 2. Each field's inline edit flow — title, due date, priority, assignee 3. Each state — with annotations visible

States and Edge Cases (10 min)

Jamie specifically calls out:

• The concurrent edit handling for titles (Sam asks: "How often does this actually happen?" Robin: "Rare for tasks, but we should handle it")
• The date picker bottom sheet behavior on mobile (Sam: "We already have that pattern for the filter selector, so it's reusable")
• The assignee simplified flow (Robin: "Backend is the same — just a PATCH to the task. No new endpoints needed")

Tokens and Components (5 min)

Jamie confirms:

• All four inline editors use existing components: TextInput, DatePicker, PrioritySelector, AvatarSelector
• No new components needed
• Token list is in the Figma annotations

Questions (10 min)

Action Items

---

Step 5: Implementation

Sam and Robin build over the sprint. Jamie is available for questions.

Mid-sprint check-in (Wednesday):

• Sam shows the title inline edit working in Storybook
• Jamie reviews: "The save animation is slightly too fast — it should be 300ms, looks like 150ms. And the TextInput width should match the original title width, not the full row width"
• Sam adjusts. Jamie confirms in Storybook

---

Step 6: Design QA

When: Thursday, Sprint 14 (before sprint review Friday) Where: Staging environment Method: Jamie reviews each story on staging, files issues

QA Session Notes

Task Title — Inline Edit:

Due Date — Inline Edit:

Priority — Inline Edit:

Assignee — Inline Edit:

Issues Filed

## Design QA: Inline Editing (Sprint 14)

### Task Title — 3 issues
1. [Major] Error toast doesn't appear on save failure.
   Expected: Toast "Couldn't save. Try again." at bottom of screen
   Actual: Error logged to console only. User has no feedback
   Fix: Wire up the error toast component to the save failure handler

2. [Minor] Focus ring clipped on left edge.
   Expected: 2px focus ring with 2px offset, fully visible
   Actual: Ring is clipped by the row's overflow:hidden
   Fix: Add overflow:visible to the task row during focus, or use outline-offset

3. [Major] Screen reader doesn't announce editing mode.
   Expected: "Editing task title" announced when edit mode activates
   Actual: No announcement
   Fix: Add aria-live region or role="status" that announces mode change

### Due Date — 1 issue
4. [Major] DatePicker overflows on mobile viewports.
   Expected: Bottom sheet presentation on viewports <768px
   Actual: Dropdown that overflows off the right edge
   Fix: Use the bottom sheet variant of DatePicker when viewport <768px

### Assignee — 1 issue
5. [Minor] Keyboard navigation uses Tab instead of Arrow keys in popover.
   Expected: Arrow Up/Down navigates between team members
   Actual: Tab navigates between team members
   Fix: Implement roving tabindex pattern (Arrow keys navigate, Tab exits)

QA Results Summary

---

Step 7: Fix and Re-QA

Sam fixes the 3 major issues by Friday morning. Jamie re-verifies:

The 2 minor issues (focus ring clipping, assignee keyboard nav) are added to the Sprint 15 backlog.

Feature ships in Sprint 14 release.

---

Key Takeaways

1. The pre-handoff checklist prevented omissions. Without it, the concurrent edit handling and mobile DatePicker edge case would likely have been discovered in QA or production 2. Behavior annotations on Figma frames answered 80% of engineering questions before the handoff session. The session focused on the genuinely ambiguous parts 3. Mid-sprint check-in caught the animation timing issue early — a 5-minute fix on Wednesday instead of a QA issue on Thursday 4. Design QA found 5 issues, 3 of them major. Without QA, these would have shipped to users — including silent error handling and a screen reader gap 5. The handoff session was 40 minutes (not a thrown-over-the-wall Figma link). That 40-minute investment saved hours of back-and-forth during implementation

Design QA

Deep reference for verifying implementation matches design specs. Design QA is the last line of defense before users see your work.

---

Design QA Process

When to Do Design QA

QA Environment Ladder

Review in this order — catch issues early where they're cheapest to fix:

---

Design QA Checklist (Detailed)

Visual Accuracy

Interactive States

Responsive Behavior

What to verify at each breakpoint:

• Elements reflow, stack, or hide as specified
• Typography scales appropriately (or uses responsive tokens)
• Images resize without distortion
• Navigation adapts (hamburger menu, etc.)
• Touch targets remain accessible on touch devices
• No horizontal scrolling

Content

Interaction and Motion

Accessibility

Cross-Browser

---

Filing QA Issues

Issue Template

## [Component/Screen]: [Brief description]

**Severity:** Critical / Major / Minor / Cosmetic
**Environment:** [Browser], [Viewport], [OS]
**Screen:** [Screen name or URL]

### Expected (Design)
[Screenshot from Figma or link to frame]

### Actual (Implementation)
[Screenshot from browser/staging]

### Details
[Specific description of the discrepancy]

### Suggested Fix
[If applicable: specific CSS property, token, or behavior change]

Severity Guidelines

Batch Reporting

For efficiency, group QA issues by screen or component rather than filing individual tickets:

## Design QA: Checkout Flow (Sprint 14)

### Payment Screen — 3 issues
1. [Minor] Card icon alignment off by 4px. Expected: centered vertically
2. [Major] Error state missing for declined card. No error message shown
3. [Minor] Input focus ring uses blue instead of design system focus token

### Confirmation Screen — 2 issues
1. [Cosmetic] Order summary spacing is 12px instead of 16px between items
2. [Minor] Success animation doesn't play. Static checkmark only

### Cross-cutting — 1 issue
1. [Major] Tab order skips the "Edit" link on the shipping address section

---

Design QA Metrics

Track these to measure and improve QA effectiveness:

Preventing QA Issues Upstream

Most QA issues originate earlier in the process:

---

Automated Design QA

Visual Regression Testing

Tools that automatically compare screenshots of the UI against reference images:

Workflow: 1. Designer approves a Storybook story or page screenshot as the reference baseline 2. Every code change generates new screenshots 3. Tool compares new screenshots against baseline 4. Differences are flagged for review 5. Designer approves or rejects changes

Design Token Linting

Automated checks that enforce design token usage:

Tools: Stylelint with custom rules, or design token-specific linters.

Accessibility Automation

Note: Automated tools catch ~30-50% of accessibility issues. Manual testing (keyboard, screen reader) is still required. Automate what you can, manually test the rest.

Design Sprints

Deep reference for planning and facilitating design sprints. Based on Jake Knapp's Sprint methodology from Google Ventures, adapted with practical variations for different team contexts.

---

Pre-Sprint Preparation

Choosing the Right Challenge

A good sprint challenge is:

• Big enough to matter — solving it would meaningfully move the business or product
• Urgent enough to justify 5 days of focused time from 5-7 people
• Uncertain enough that the team doesn't already know the answer
• Testable within one week — you can build a prototype and get user feedback

Bad sprint challenges:

• "Redesign the homepage" — too broad, no specific problem
• "Fix the button color" — too small, doesn't need a sprint
• "Build the Q3 roadmap" — not a design problem

Good sprint challenges:

• "New users drop off during onboarding — 68% don't complete setup. Why, and what can we do?"
• "Enterprise customers say our reporting is unusable. Can we find an approach that works before committing engineering?"
• "We're entering a new market segment. What should the first experience look like?"

Sprint Logistics

Recruiting Test Participants

Recruit before the sprint. Friday testing can't slip.

Screen for behavior, not demographics. "Have you searched for a recipe online in the past week?" is better than "Are you aged 25-34?"

Schedule 5 participants at 60-minute intervals: 9am, 10am, 11am, 1pm, 2pm. The team watches together.

---

Day-by-Day Deep Dive

Monday: Map

Goal: Agree on the problem worth solving and choose a specific target area for the sprint.

Morning (10am-1pm):

1. Set a long-term goal (20 min)

• Ask: "Why are we doing this sprint? If everything goes perfectly, what's true in 2 years?"
• Write the goal on the whiteboard. It stays there all week
• Example: "Become the go-to tool for small team task management by making setup effortless"

2. List sprint questions (20 min)

• Ask: "What questions do we need to answer this week? What could cause this to fail?"
• Phrase as "Can we...?" or "Will users...?"
• Example: "Can we get a team set up in under 5 minutes?" "Will managers adopt a tool their team chose?"

3. Make a map (60-90 min)

• Draw the user journey from left to right on the whiteboard
• Actors on the left, end goal on the right, key steps in between
• Keep it simple — 5-15 steps. This is a map, not a flowchart
• Include the moments where the sprint questions apply

Afternoon (2pm-5pm):

4. Ask the experts (60-90 min)

• Bring in 2-4 people who aren't in the sprint but have relevant knowledge: customer support lead, sales, data analyst, subject matter expert
• Each expert talks for 10-15 minutes. Team asks questions
• As experts talk, team adds "How Might We" notes on stickies (one idea per sticky)

5. Organize HMW notes (20 min)

• Stick all HMWs on the wall. Silent clustering — group similar themes
• Dot vote: each person gets 2 dots, Decider gets 4

6. Pick a target (15 min)

• Decider chooses one area of the map to focus on for the rest of the week
• The target should align with the highest-voted HMWs and sprint questions
• Announce: "This week, we're solving [target]"

Tuesday: Sketch

Goal: Generate a diverse set of solutions. Individual work, not group brainstorming.

Morning (10am-1pm):

1. Lightning demos (60 min)

• Each person presents 2-3 examples of existing products or solutions that inspire them (3 min each)
• Can be competitors, analogous products, or solutions from unrelated industries
• Capture the big idea from each demo on the whiteboard

2. Divide or swarm (10 min)

• If the target can be split into parts, assign different parts to different people
• If not, everyone tackles the same problem from different angles

Afternoon (2pm-5pm):

3. Four-step sketch process (each person works alone)

Rules for sketching:

• No group brainstorming. Research consistently shows individuals generate more and better ideas when working alone
• Self-explanatory sketches. Include titles, annotations, callouts. Someone should understand it without explanation
• Words matter. Use real headlines and labels, not "lorem ipsum"
• Ugly is fine. Stick figures, boxes, and arrows. The idea matters, not the rendering

Wednesday: Decide

Goal: Choose the best solution without endless debate.

Morning (10am-1pm):

1. Art museum (15 min)

• Tape all solution sketches on the wall. Team walks around silently, reading each one

2. Heat map (15 min)

• Each person gets dot stickers (many — 20+). Place dots on parts of sketches they find interesting
• No discussion. Dots are a signal, not a vote

3. Speed critique (45-60 min)

• For each sketch: facilitator narrates what they see (3 min) → team calls out standout ideas (2 min) → creator clarifies misunderstandings (1 min)
• Capture big ideas on stickies. Stick them above each sketch

4. Straw poll (10 min)

• Each person gets one supervote sticker. Place it on the solution (or part of a solution) they think should be prototyped
• This is advisory — the Decider makes the final call

5. Decider decides (10 min)

• The Decider places their supervote(s). That's the direction
• If two strong solutions conflict: consider a "rumble" — prototype both and test head-to-head

Afternoon (2pm-5pm):

6. Storyboard (2-3 hours)

• Draw the test prototype as a storyboard: ~10-15 frames on the whiteboard
• Start with the "opening scene" — how does the user find this? Google search? Email link? Direct URL?
• Each frame is one step or screen. Include enough detail for Thursday's prototype team
• The storyboard IS the prototype spec

Thursday: Prototype

Goal: Build a realistic facade that can fool a user for 60 minutes.

Principles:

• Goldilocks quality — Real enough to get honest reactions, fake enough to build in one day
• Facade, not product — It looks real but nothing works behind the scenes
• Focus on the test flow — Only build what the user will interact with during Friday's test

Team roles:

Prototype tool selection:

End of day: Full run-through of the prototype. Everyone watches. Fix anything that breaks the illusion.

Friday: Test

Goal: Watch 5 real users interact with the prototype. Identify patterns.

Schedule:

Interview structure (60 min per user):

1. Warm-up (5 min) — Build rapport. Ask about their background and context 2. Context questions (10 min) — How they currently handle the problem the sprint is solving 3. Prototype walkthrough (35 min) — "Think out loud as you go." Minimal guidance from interviewer 4. Debrief (10 min) — Overall impressions, comparisons, final questions

Observation setup:

• Interviewer is alone with participant (in person or video call)
• Rest of the team watches from a separate room via screen share
• Each observer has a note grid: rows = interview sections, columns = participants
• Use stickies: green = positive reaction, red = negative, yellow = neutral/interesting

Identifying patterns (final debrief):

---

Sprint Variations

Mini Sprint (3 Days)

For smaller problems or when you can't block a full week:

Trade-offs: Less divergent thinking, simpler prototype, same quality of testing.

Remote Sprint

Design Sprint for Existing Products

When the product already exists, adapt the sprint:

• Monday mapping uses real analytics data, not assumptions — show the funnel, the drop-offs, the support tickets
• Lightning demos include the current product as one of the examples — what's working and what isn't
• Prototype can be a modified version of the real product, not a from-scratch build
• Friday testing compares the new approach against the existing experience (A/B within the test session)

---

Post-Sprint Actions

The sprint ends Friday, but the work continues:

Sprint Artifacts to Preserve

Documentation Standards

Deep reference for organizing, naming, versioning, and maintaining design files and documentation.

---

File Organization

Project File Structure

Every project should follow a consistent structure regardless of tool:

[Project Name]/
├── 📁 Discovery
│   ├── Research findings
│   ├── Competitive analysis
│   ├── User flows (current state)
│   └── Problem framing artifacts
│
├── 📁 Exploration
│   ├── v1 concepts (discarded)
│   ├── v2 concepts (discarded)
│   └── Sketches and wireframes
│
├── 📁 Design (current, approved)
│   ├── User flows
│   ├── Screens (organized by flow or feature)
│   ├── Component specs (for new components)
│   └── Responsive variants
│
├── 📁 Handoff
│   ├── Sprint [N] handoff
│   ├── Sprint [N+1] handoff
│   └── Change requests
│
├── 📁 Assets
│   ├── Icons (SVG)
│   ├── Images (with alt text notes)
│   └── Animations (Lottie, GIF, or specs)
│
└── 📁 Archive
    ├── v1 (date, reason archived)
    └── v2 (date, reason archived)

Figma File Structure

Figma File: [Project Name]
├── 📄 Cover Page (project name, status, owner, last updated, links)
├── 📄 Flows (user flow diagrams)
├── 📄 [Feature A] — Screens
│   ├── Section: Happy Path
│   ├── Section: Error States
│   ├── Section: Empty States
│   ├── Section: Loading States
│   └── Section: Responsive (Mobile / Tablet)
├── 📄 [Feature B] — Screens
│   └── (same section structure)
├── 📄 Components (feature-specific, not in the design system)
├── 📄 Exploration (discarded concepts — kept for reference)
└── 📄 Archive (previous versions)

Cover Page Standard

Every Figma file should have a cover page with:

---

Naming Conventions

File Naming

Frame Naming

Frames are the most important naming level — they appear in links, handoff tools, and search.

Rules:

• Use / as a separator (Figma auto-nests in the layers panel)
• Use title case: Payment Method not payment method or PAYMENT METHOD
• Use real names: Checkout / Cart Summary not Frame 47 or Screen 3
• Include the state: / Default, / Hover, / Error, / Loading, / Empty
• Include the breakpoint for responsive variants: / Desktop, / Tablet, / Mobile

Layer Naming

Layers inside frames should be descriptive:

Auto-layout frames should be named by their content role, not their layout behavior: navigation not horizontal-frame-1.

Component Naming

Components should match the code component names exactly:

Variant naming uses property=value pairs:

Button
  size=small, variant=primary, state=default
  size=small, variant=primary, state=hover
  size=small, variant=secondary, state=default
  ...

---

Version Control

Versioning Strategy

Use semantic versioning adapted for design:

Version Documentation

Every version milestone should include a changelog entry:

## v2.1 — Added error states for payment flow (2026-03-15)

Changes:
- Added declined card error state with retry flow
- Added network error state with offline fallback
- Updated copy on payment confirmation screen

Reason: User testing revealed confusion when payment failed silently

Approved by: Alex Rivera (PM) in sprint review 2026-03-12
Link: [Sprint review notes]

Figma-Specific Version Control

---

Documentation Types

Design Decision Records

For significant design decisions, capture the reasoning:

## Decision: [Short title]

**Date:** [Date]
**Decider:** [Name]
**Status:** [Proposed / Accepted / Superseded by [link]]

### Context
[What situation prompted this decision?]

### Options Considered
1. [Option A] — [Pros / Cons]
2. [Option B] — [Pros / Cons]
3. [Option C] — [Pros / Cons]

### Decision
[What was decided and why]

### Consequences
[What this decision means for the product, the team, the design system]

Pattern Usage Guidelines

When a new UI pattern is introduced, document how to use it:

## Pattern: [Name]

**When to use:** [Specific scenarios where this pattern applies]
**When NOT to use:** [Scenarios where a different pattern is better]
**Related patterns:** [Patterns that are similar or often confused]

### Example
[Screenshot or Figma link showing correct usage]

### Anti-example
[Screenshot or Figma link showing incorrect usage]

Research Handoff

When research findings inform design work, document the connection:

## Research: [Study name]
**Date:** [Date]
**Method:** [Usability test / Interview / Survey / Analytics]
**Key findings:**
1. [Finding with supporting data]
2. [Finding with supporting data]

**Design implications:**
- [Finding 1] → [Specific design change]
- [Finding 2] → [Specific design change]

**Open questions:**
- [Question that needs further research]

---

Documentation Maintenance

Quarterly Audit

Every quarter, audit design documentation:

Documentation Ownership

When to Delete vs. Archive

Design-to-Development Handoff

Deep reference for preparing, delivering, and following through on design handoff. The goal: engineers should never have to guess.

---

Handoff Preparation

Pre-Handoff Checklist

Before scheduling a handoff session, every design must pass this checklist:

Annotation Standards

Annotations explain what the static design can't show. Every handoff frame should include notes for:

Behavior annotations:

• What happens on click/tap (navigation, state change, API call)
• Keyboard interaction (Tab, Enter, Escape, Arrow keys)
• What triggers loading states and how long they persist
• Transition and animation specifications
• Scroll behavior (sticky headers, infinite scroll, pagination)

Content annotations:

• Maximum character counts for text fields
• Truncation rules (ellipsis, word break, fade)
• Dynamic content sources (what comes from the API vs. what's static)
• Localization notes (text expansion for longer languages — German is ~30% longer than English)
• Pluralization rules ("1 item" vs. "2 items")

Layout annotations:

• Container behavior (fixed width, fluid, max-width)
• What happens when content exceeds the container
• Responsive breakpoint behavior (reflow, stack, hide, change)
• Spacing tokens used (not pixel values)

---

Handoff Documentation Formats

Screen-Level Spec

For each screen in a flow:

Screen: [Screen Name]
Flow: [Flow Name] > Step [#]
Figma: [Link to frame]

## Layout
- Container: max-width [token], centered
- Grid: [columns] at [breakpoint]
- Spacing: [tokens used]

## Interactive Elements
[For each element:]
- Element: [Name]
- Component: [Design system component name]
- States: [List all states with links to frames]
- Behavior: [What it does on interaction]
- Keyboard: [Keyboard interaction]
- ARIA: [Role, label, announcements]

## Content
- [Field]: [Copy] (max [n] characters, truncate with ellipsis)
- [Field]: [Dynamic — from API endpoint [name]]

## Responsive
- Desktop (1440px+): [Description]
- Tablet (768px-1439px): [Description]
- Mobile (320px-767px): [Description]

## Edge Cases
- Empty state: [What shows when there's no data]
- Error state: [What shows when the request fails]
- Loading state: [What shows during data fetch]
- Long content: [How overflow is handled]

Component-Level Spec

For new or modified components:

Component: [Name]
Design system: [New / Modification of existing [name]]
Figma: [Link to component frame]

## Props / Variants
| Prop | Type | Default | Options |
|------|------|---------|---------|
| variant | enum | "primary" | primary, secondary, tertiary |
| size | enum | "medium" | small, medium, large |
| disabled | boolean | false | true, false |
| loading | boolean | false | true, false |

## States
[Frame links for each state]

## Tokens Used
- Background: [token]
- Text: [token]
- Border: [token]
- Spacing: [token]
- Border-radius: [token]
- Typography: [token]

## Behavior
- Click: [What happens]
- Keyboard: [What keys trigger what]
- Focus: [Focus ring style, focus order in parent]

## Accessibility
- Role: [ARIA role]
- Label: [aria-label or aria-labelledby]
- Announcements: [What screen reader announces on state change]

Flow-Level Spec

For multi-step flows:

Flow: [Name]
Entry point: [Where the user comes from]
Exit points: [Where the user can go]
Figma: [Link to flow page]

## Steps
1. [Screen name] → [Action] → [Next screen]
2. [Screen name] → [Action] → [Next screen]
   ↳ Error path: [Screen name] → [Recovery action] → [Resume point]
3. ...

## State Management
- [What data is collected at each step]
- [What data persists if the user navigates back]
- [What happens if the user abandons mid-flow]

## Analytics Events
| Step | Event | Properties |
|------|-------|-----------|
| Step 1 viewed | flow_step_viewed | flow_name, step_number |
| Step 1 completed | flow_step_completed | flow_name, step_number, duration |
| Flow completed | flow_completed | flow_name, total_duration |
| Flow abandoned | flow_abandoned | flow_name, last_step, reason |

---

Handoff Tools and Workflows

Figma-Based Handoff

Storybook Integration

For teams using Storybook:

1. Component spec in Figma → maps to a Storybook story 2. Each variant in the design → maps to a story variant 3. Each state → maps to a story with that state active 4. Design QA compares Storybook rendering against Figma frame side-by-side 5. Figma links embedded in Storybook story descriptions for traceability

Code Connect (Figma)

For mature teams, Code Connect links Figma components directly to code:

• Designer selects a component in Figma → sees the actual code implementation
• Engineer inspects a design → sees which code component to use and how
• Reduces spec ambiguity to near zero for existing components
• New components still need full specs

---

Handoff Workflow by Team Size

Small Team (1 designer, 2-5 engineers)

Medium Team (2-3 designers, 5-15 engineers)

Large Team (4+ designers, 15+ engineers)

---

Handling Handoff Conflicts

Designer-Engineer Disagreements

Post-Handoff Design Changes

Changes after handoff are expensive. Minimize them by:

1. Getting engineering input early — before handoff, not after 2. Using a change request process:

   Change request:
   - What changed: [Description]
   - Why: [New information, user feedback, stakeholder request]
   - Impact: [Which stories/components are affected]
   - Priority: [Must-have for this release / Can wait for next sprint]

3. Tracking change frequency — if changes are frequent, the process upstream is broken (discovery, critique, or review)

Team Rituals and Cadences

Deep reference for design team rituals — critiques, syncs, reviews, retros, and how they fit together into a sustainable cadence.

---

Design Critique

The most important ritual for design quality. Done well, critique raises the bar for everyone. Done poorly, it becomes a political approval gate or an awkward silence.

Critique Format

Duration: 45-60 minutes Frequency: Weekly (same day, same time — never skip) Attendees: All designers. Optional: PM, engineering lead, content strategist

Structure:

Critique Rules

1. Presenter frames the request. "I'm working on the checkout flow. I'm confident about the layout but struggling with the payment method selection. Focus your feedback there." This prevents unfocused scatter-shot feedback 2. Feedback references principles. "Hick's Law suggests fewer options. You have 6 payment methods visible at once — could you group or default?" Not "I think there are too many options" 3. Problems, not solutions. "The hierarchy between the primary and secondary actions is unclear." Not "Make the primary button bigger." The presenter solves the problem 4. No defending. The presenter listens and asks questions. Not "But the stakeholder said..." or "I already tried that" 5. Written capture. Every feedback item is written down with an owner. If it's not captured, it didn't happen 6. Kindness is not silence. Saying nothing about a real issue is not kind — it lets the problem ship. Kind feedback is honest, specific, and constructive

Critique Anti-Patterns

Critique Variations

---

Design-Engineering Sync

The bridge between design and engineering. Prevents surprises.

Sync Structure

Duration: 30 minutes Frequency: Weekly Attendees: Design lead + engineering lead (or tech lead). Full team for complex topics.

Agenda:

What to Cover

• Engineering constraints the designer needs to know: API limitations, performance budgets, platform differences, library capabilities
• Design decisions the engineer needs to know: Why this approach, not that one. What matters most vs. what's flexible
• Component reuse: Is there an existing component? Does a new one need to be built? Does the design system need updating?
• Scope negotiation: What can be simplified without losing the core experience? What can be deferred?

---

Design Review

Stakeholder alignment on design direction. Not a critique — it's a decision point.

Review Structure

Duration: 30-60 minutes Frequency: Per milestone (kickoff, mid-point, pre-handoff) Attendees: PM, design lead, engineering lead, relevant stakeholders

Agenda:

Review Best Practices

1. Present the problem first. Stakeholders who understand the problem give better feedback on the solution 2. Show the exploration. "We considered 3 approaches. Here's why we chose this one." Prevents "Did you think about...?" 3. Show user evidence. "In 5 user tests, 4 found this intuitive." Evidence is more persuasive than argument 4. Be specific about what you need. "I need a go/no-go on this direction" or "I need your input on the pricing display" 5. Timebox questions. Stakeholders can ask endlessly. Facilitator manages time 6. Separate "I don't like it" from "users won't understand it." The first is a preference. The second is a hypothesis to test

---

Retrospectives

Design Team Retro

Duration: 45 minutes Frequency: Bi-weekly or end of each sprint Attendees: Design team + optionally PM and eng lead

Format (Start/Stop/Continue):

Process: 1. Silent brainstorm (5 min) — everyone writes stickies 2. Share and cluster (10 min) — read aloud, group similar themes 3. Dot vote (3 min) — each person gets 3 dots 4. Discuss top items (15 min) — focus on the 2-3 highest-voted topics 5. Action items (5 min) — assign owners and deadlines for improvements

Common Retro Themes and Fixes

---

Ritual Calendar

Weekly Cadence (Example)

Sprint-Level Cadence

Quarterly Cadence

---

Meeting-Free Time

Protect deep work time. Designers need uninterrupted blocks for creative work.

Rules: 1. One meeting-free day per week minimum — Thursday is a common choice 2. No meetings before 10am or after 4pm — protect morning and late-afternoon focus time 3. Maximum 2 hours of meetings per day — anything more cuts into productive design time 4. Batch meetings — stack meetings on 2-3 days, keep other days clear 5. 25/50-minute meetings — end 5-10 minutes early to prevent back-to-back meeting fatigue

Tracking: If designers report spending >40% of their time in meetings, the ritual calendar needs trimming. The most common culprits are redundant syncs and reviews that could be async.

Design Sprint Plan: [Sprint Name]

Challenge: [One sentence describing the problem to solve] Dates: [Monday] — [Friday] Facilitator: [Name] Decider: [Name] Location: [Room / Remote tool]

---

Sprint Team

---

Pre-Sprint Checklist

---

Monday: Map

Long-Term Goal

[If everything goes perfectly, what's true in 2 years?]

Sprint Questions

1. Can we [question]? 2. Will [users] [behavior]? 3. Is [assumption] true?

Problem Map

[Photo of whiteboard map — actors on left, goal on right, steps in between]

Expert Interviews

How Might We Notes (Top Voted)

1. HMW [question]? ([#] votes) 2. HMW [question]? ([#] votes) 3. HMW [question]? ([#] votes)

Target

We're focusing on: [specific area of the map]

---

Tuesday: Sketch

Lightning Demos

Solution Sketches

[Photos of each person's three-panel solution sketch — stored in project folder]

• Sketch 1: [Brief description] by [Name]
• Sketch 2: [Brief description] by [Name]
• Sketch 3: [Brief description] by [Name]
• Sketch 4: [Brief description] by [Name]
• Sketch 5: [Brief description] by [Name]

---

Wednesday: Decide

Heat Map Results

[Photo of sketches with dot stickers — which parts got the most attention?]

Speed Critique Notes

Straw Poll

• [Name]: voted for [Sketch/Part]
• [Name]: voted for [Sketch/Part]
• [Name]: voted for [Sketch/Part]

Decider's Decision

We're prototyping: [Description of chosen direction]

Reason: [Why this direction]

Storyboard

[Photo of storyboard on whiteboard — ~10-15 frames showing the test flow]

---

Thursday: Prototype

Team Roles

Prototype Tool

[Figma / Keynote / HTML / Other]

Prototype Link

[Link to prototype]

End-of-Day Run-Through

• [ ] Full flow works without breaking
• [ ] Copy is realistic (no lorem ipsum)
• [ ] Key decision points are clear
• [ ] Prototype covers the test scenarios

---

Friday: Test

Participant Schedule

Interview Script Outline

1. Warm-up (5 min): [Questions about background] 2. Context (10 min): [Questions about current behavior] 3. Prototype walkthrough (35 min): [Task prompts] 4. Debrief (10 min): [Overall impression questions]

Observation Notes

Use: 🟢 Positive | 🔴 Negative | 🟡 Neutral | Write brief notes in each cell

Patterns Summary

---

Sprint Decision

Decision: [ ] Go — build it | [ ] No-go — pivot | [ ] Go with changes

Reasoning:

[Why this decision, based on what was observed]

Sprint Questions Answered: 1. [Question] → [Answer from testing] 2. [Question] → [Answer from testing] 3. [Question] → [Still unclear — needs more research]

---

Next Steps

Handoff Checklist: [Feature Name]

Designer: [Name] Engineer(s): [Names] Sprint: [Sprint number or date range] Figma: [Link to handoff frames] Ticket: [Link to user story / issue]

---

Pre-Handoff Verification

Completeness

States Coverage

For each interactive element, verify these states exist:

Responsive

Design System

Content

Accessibility

Assets

---

Behavior Documentation

User Flow

[Entry point] → [Screen 1] → [Action] → [Screen 2] → ... → [End state]
                                ↳ [Error] → [Error screen] → [Recovery]

Interactions

API Dependencies

---

Handoff Session

Date: [Date] Attendees: [Names] Duration: [Time]

Questions from Engineering

Open Items

---

Post-Handoff

Design QA

Change Requests (Post-Handoff)

---

Sign-Off