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

Copy code
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:

Copy code
**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:

Copy code
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