cuellarfr/design-skills/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: