design-ops

name	design-ops
description	Run design sprints, manage handoff, establish team rituals, documentation standards, and design QA processes. Covers the operational side of design — how teams organize work, collaborate with engineering, and ship quality.

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

Signal	Sprint Is Right	Sprint Is Wrong
Problem clarity	Big problem, unclear solution	Solution already known — just build it
Stakes	High — wrong direction costs months	Low — easy to course-correct later
Team alignment	Disagreement on approach	Team already aligned
Time pressure	Need answers this week	Can run a longer discovery process
Complexity	Cross-functional problem	Single-discipline task

The 5-Day Structure

Day	Focus	Key Activity	Output
Monday	Map	Define the challenge, set a 2-year goal, map the problem space, pick a target	Sprint questions, problem map, target area
Tuesday	Sketch	Review existing solutions, each person sketches solutions individually	Solution sketches (one per person)
Wednesday	Decide	Present sketches, vote (dot voting + decider picks), create storyboard	Storyboard for prototype
Thursday	Prototype	Build a realistic facade — just enough to test	Testable prototype
Friday	Test	5 user interviews, observe together, identify patterns	Go/no-go decision with evidence

Sprint Team

Role	Count	Responsibility
Decider	1	Has authority to make final calls. Usually PM or founder
Facilitator	1	Runs the process, keeps time, manages energy
Designer	1-2	Leads sketching, builds prototype
Engineer	1-2	Feasibility gut-checks, helps prototype
Domain expert	1-2	Customer support, sales, marketing — whoever knows the user
Total	5-7	More than 7 is counterproductive

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

Level	Description	Symptom
1. Screenshot	Designer sends a static image	Engineers guess spacing, states, behavior
2. Annotated mockup	Redlines, spacing callouts	Better, but still missing states and edge cases
3. Interactive spec	Figma/design tool with inspect mode, component links	Engineers can extract values, but behavior is undocumented
4. Full spec	All states, transitions, error handling, responsive behavior, tokens	Engineers build exactly what was designed
5. Integrated	Design and code share a component system; handoff is a conversation, not a document	Minimal spec needed — shared language does the work

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

What a Complete Handoff Includes

Every screen or component handoff must cover:

Category	Required Items
Layout	Spacing (in tokens, not pixels), alignment, responsive breakpoints, container behavior
Content	Final copy (not lorem ipsum), character limits, truncation rules, localization notes
States	Default, hover, focus, active, disabled, loading, empty, error, success — for every interactive element
Behavior	What happens on click/tap, keyboard interaction, drag, swipe. Transition details
Responsive	How the layout adapts at each breakpoint. What reflows, stacks, hides, or changes
Tokens	Color tokens, typography tokens, spacing tokens — never raw hex/px values
Accessibility	Focus order, ARIA roles, screen reader announcements, touch targets, color contrast
Edge cases	Long strings, empty data, error recovery, offline behavior, permissions
Assets	Icons (SVG), images (with alt text), animations (specs or files)

Handoff Anti-Patterns

Anti-Pattern	Problem	Fix
"It's in Figma"	No context, engineer must reverse-engineer intent	Write behavior notes on every frame
Happy path only	Only the ideal flow is designed	Design all states before handoff
Pixel specs	"24px left margin"	Use tokens: spacing-md
Verbal handoff	"I'll explain it in standup"	If it's not written down, it doesn't exist
Big-bang handoff	Entire feature dropped on engineering at once	Hand off in slices that match sprint stories
No error states	"We'll figure out errors later"	Error states are designed first, not last

---

Team Rituals and Cadences

Core Design Rituals

Ritual	Frequency	Duration	Purpose	Who Attends
Design critique	Weekly	45-60 min	Improve work-in-progress through structured feedback	All designers
Design-eng sync	Weekly	30 min	Align on upcoming work, resolve handoff questions	Design lead + eng lead
Design review	Per milestone	30-60 min	Stakeholder sign-off on direction	PM, design, eng leads, stakeholders
Handoff session	Per story/feature	30-45 min	Walk engineering through specs, answer questions	Designer + implementing engineers
Design QA	Per release	60-90 min	Verify implementation matches spec	Designer + engineer
Retro	Bi-weekly or per sprint	45 min	Improve the process	Whole product team
Design sprint	As needed	5 days	Solve big problems, validate risky ideas	Cross-functional team (5-7)

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

Element	Convention	Example
Files	[project]-[feature]-[variant]	taskpilot-onboarding-v2
Pages/frames	[flow]-[step]-[state]	checkout-payment-error
Components	Match code component names exactly	ButtonPrimary, not Main CTA
Versions	Semantic: v1.0, v1.1, v2.0	Major = new direction, minor = iteration
Layers	Descriptive, no "Group 1" or "Frame 47"	header/nav/menu-trigger

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

Category	Check	Tool
Visual accuracy	Colors match tokens. Spacing matches spec. Typography is correct	Side-by-side comparison, browser dev tools
States	All states render correctly: default, hover, focus, active, disabled, error, loading, empty	Manual testing, Storybook
Responsive	Layout works at all breakpoints. Nothing overflows, truncates wrong, or disappears	Resize browser, test on real devices
Content	Real content fits. Long strings handled. Empty states designed. Truncation works	Test with edge-case content
Interaction	Animations match spec. Transitions are smooth. Timing feels right	Manual testing, slow-motion recording
Accessibility	Focus order correct. Screen reader announces correctly. Contrast passes. Touch targets 44px+	axe, keyboard testing, VoiceOver/NVDA
Cross-browser	Renders correctly in Chrome, Firefox, Safari, Edge	BrowserStack or manual
Performance	Images optimized. No layout shift. Animations don't drop frames	Lighthouse, Core Web Vitals

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:

Metric	What It Measures	Target	How to Measure
Handoff completeness	% of handoffs with all states, tokens, responsive specs	>90%	Audit handoff docs quarterly
Design QA pass rate	% of stories passing design QA on first review	>80%	Track QA issues per story
Rework rate	% of design work that gets redone after handoff	<15%	Count post-handoff design changes
Sprint velocity impact	How often missing specs block engineering	0 blocks/sprint	Track blocker tags in standup
Design debt	Known visual/interaction inconsistencies in production	Decreasing trend	Maintain a design debt backlog
Critique participation	Designers bringing work to critique regularly	100% monthly	Track critique presenters

---

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:

Full Process	Guerrilla Alternative	When It's Enough
Formal usability study (lab, recruiting, 5+ participants)	Hallway testing with 3 people for 15 minutes	Early concepts, internal tools, low-stakes features
Multi-week discovery research	3 customer interviews in one week + support ticket review	You need directional insight, not statistical confidence
Design sprint (5 full days)	Mini-sprint: 2-day version (map + sketch on day 1, prototype + test on day 2)	Smaller problems, aligned team, good prior research
Full journey mapping workshop	Assumption map on a whiteboard (30 min with the team, mark what you know vs. guess)	When you need alignment more than research
Formal design critique (weekly, all designers)	Async critique in Figma comments with one engineer and one PM	Solo designer, no design peers available
Design system with governance	Component inventory + shared Figma library with naming conventions	Small product, 1-3 engineers

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

Full Ritual	Lean Alternative	Cadence
Weekly design critique	Bi-weekly "design lunch" — show WIP to anyone interested, even non-designers	Every 2 weeks
Design-eng sync	15-minute standup addition: "Here's what's coming in design this sprint"	Per sprint
Formal design review	Share a 1-page decision doc with the PM before a milestone. Async approval	Per milestone
Design QA sprint	QA checklist in the PR template — designer reviews before merge	Per story
Retro	Add one design-specific question to the team retro: "Where did design and implementation diverge?"	Per sprint

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

Mistake	Why It Fails	Better Approach
Skipping the sprint map day	Team builds solutions to the wrong problem	Monday's map and target selection is the most valuable day
Designing in isolation	Work handed off doesn't match engineering reality	Daily or weekly design-eng syncs
No design QA process	Visual quality degrades over time	QA every story, not just every release
Over-documenting	30-page spec nobody reads	Spec what's ambiguous. Shared component system handles the rest
Under-documenting	"You can see it in Figma"	If an engineer has to ask, the spec was incomplete
Treating handoff as a one-time event	Throws work over the wall	Handoff is a conversation that continues through implementation
No retros	Same mistakes repeat	Bi-weekly retros with specific action items and owners
Design critique as approval gate	Critique becomes political	Critique is for improving work, not for approving it