Map the complete design-to-deployment pipeline with quality gates, handoff protocols, and feedback loops — from initial brief through design, implementation, QA, and production release.
The design-to-deployment pipeline has a predictable set of stages, each with potential failure modes that slow delivery or reduce quality. Without explicit pipeline definition, teams operate on implicit assumptions — designers assume developers read designs thoroughly, developers assume designs are final when they are not, and QA assumes everything is verified before it arrives.
This lesson defines the complete pipeline explicitly, with quality gates at every stage transition, responsible parties for each activity, and feedback loops that improve the pipeline over time.
The pipeline has seven stages, each with a clear definition of done before the next stage begins.
Stage 1: Brief and Requirements
Responsible: PM + Designer
Inputs: product requirements, user research, analytics data
Activities:
Quality gate: Designer and PM agree on scope before design begins
Stage 2: Design Exploration
Responsible: Designer (with developer consult on complexity)
Inputs: design brief, design system, user research
Activities:
Quality gate: Exploration reviewed, direction selected, developer flagged concerns
Stage 3: Design Production
Responsible: Designer
Inputs: approved direction, design system
Activities:
Quality gate: Design checklist complete (all states, all breakpoints, all tokens)
Stage 4: Handoff
Responsible: Designer → Developer
Inputs: Figma named version, component specs, Loom walkthrough
Activities:
Quality gate: All developer questions answered before implementation starts
Stage 5: Implementation
Responsible: Developer (with Designer available for questions)
Inputs: Figma specs, component documentation, design tokens
Activities:
Quality gate: Developer self-QA passed
Stage 6: Design QA
Responsible: Designer
Inputs: staging URL, Figma named version
Activities:
Quality gate: Zero Critical, Zero High findings in GitHub
Stage 7: Release
Responsible: Developer + PM
Inputs: QA-signed-off implementation
Activities:
Quality gate: Chromatic passes, PM sign-off
A design brief answers the questions a designer must understand before opening Figma. Without a brief, design starts with the solution instead of the problem.
Design brief template:
1## Design Brief: [Feature Name]
2**Sprint**: N
3**Designer**: [name]
4**Date**: YYYY-MM-DD
5**Figma branch**: feat/sprint-N/[feature]
6
7### Problem Statement
8[1-2 sentences: what user problem are we solving?]
9
10### User
11[Who is using this? What do they know? What are they trying to do?]
12
13### Success Metrics
14[How will we know this worked? Quantitative if possible.]
15[Example: 'Enrollment conversion on mobile improves from 23% to 30%']
16
17### Constraints
18[Technical: framework, performance budget, accessibility requirements]
19[Timeline: must ship by sprint N]
20[Scope: in-scope and explicitly out-of-scope]
21
22### User Research
23[Links to interview notes, analytics, or usability test results]
24
25### Design Decisions Already Made
26[Decisions from PM or stakeholders that are not open for design exploration]
27
28### Open Questions for Design to Answer
29[Specific questions the design must resolve]Design brief example:
1## Design Brief: Course Enrollment Conversion Improvement
2**Sprint**: 3
3**Designer**: @sara
4
5### Problem
6Mobile enrollment conversion is 23% vs 56% desktop. Users on mobile
7scroll past the enrollment CTA and abandon.
8
9### User
10Learner who has read course details and wants to enroll.
11Has scroll past 2 screens of content. Ready to act.
12
13### Success Metrics
14Mobile enrollment conversion: 23% → target 30% in 4 weeks post-launch.
15
16### Constraints
17- iOS Safari: no position:fixed inside overflow:scroll containers
18- Bundle budget: no new JS libraries (CSS-only sticky preferred)
19- Accessibility: WCAG 2.1 AA minimum
20- Timeline: Sprint 3, 2-week implementation
21
22### Research
23- Heatmaps show 60% of mobile users scroll past the enrollment button
24- User interview: 'I could not find the price when I was ready to buy'
25
26### Open Questions
27- Does sticky bar work or does user need full checkout in view?
28- Should price be shown in sticky bar?Retrospectives happen every two weeks — but learnings from implementation happen daily. Fast feedback loops capture these insights before they are forgotten.
Micro-retrospective (15 minutes, end of implementation):
Triggered when: developer finishes implementing a feature
Format: 3 questions in Notion:
Example micro-retrospective:
1Feature: Lesson Item component
2Completed: 2026-06-05
3
4Unclear from design:
5 - The 'completed' state vs 'in-progress' state looked identical in Figma
6 at small sizes. Needed a Figma annotation or a clear distinction.
7
8Assumed but different:
9 - Design showed hover with background change — but Figma did not specify
10 the exact timing. I used 150ms; not sure if designer intended faster.
11
12Would have saved time:
13 - A prototype showing the hover-to-active transition timing.
14 - The exact CSS for the progress bar would have saved 20 min of extraction.Feedback loop for designers:
Common feedback patterns and their fixes:
1Pattern: Transitions always unclear
2 Fix: Designer adds timing annotations to all interactive components
3
4Pattern: Error states always missing
5 Fix: Add error state to component spec template as required field
6
7Pattern: Mobile states need more detail
8 Fix: Designer creates separate mobile artboard for every component
9
10Pattern: Token names unclear
11 Fix: Designer adds token name to Inspect panel annotations in FigmaDesign system improvement from feedback:
template for all interactive components → automatically includes timing
Cycle time — the time from work starting to work shipping — is the primary measure of pipeline efficiency. Tracking where time is spent reveals which stage to improve first.
Cycle time measurement framework:
1Stage Measure from To
2-------------- -------------- ---
3Brief to design start Brief created First Figma artboard
4Design to handoff Design start Figma handoff announcement
5Handoff to impl start Handoff announcement First git commit on feature
6Impl to PR First commit PR opened
7PR to QA sign-off PR opened Designer QA resolved
8QA to release QA sign-off Deployed to production
9Total cycle time Brief created Deployed to productionTracking in Notion (or Linear/Jira):
1Feature | Brief | Design | Handoff | Impl start | PR | QA | Released | Total
2----------------|-------|--------|---------|------------|----|----|----------|-------
3Lesson Item | 6/1 | 6/2 | 6/2 | 6/3 | 6/5| 6/6| 6/7 | 6 days
4Enrollment Bar | 6/1 | 6/3 | 6/4 | 6/5 | 6/6| 6/7| 6/7 | 6 days
5Course Header | 5/28 | 6/1 | 6/2 | 6/3 | 6/4| 6/5| 6/6 | 9 days*
6
7* Course Header: 3 days spent in 'design to handoff' — complex component,
8 needed additional stakeholder reviewCycle time benchmarks:
1Excellent: < 5 days (brief to production, simple component)
2Good: 5-10 days (brief to production, medium complexity)
3Acceptable: 10-15 days (brief to production, complex feature)
4Investigate: > 15 days (likely stuck at a specific stage)Identifying bottlenecks:
1If most time is in 'Brief to design start':
2 Problem: design backlog, not enough designers
3 Solution: reduce scope, add designer, improve brief quality
4
5If most time is in 'Handoff to implementation start':
6 Problem: unclear handoff, too many questions
7 Solution: improve component spec docs, add Loom walkthroughs
8
9If most time is in 'QA to release':
10 Problem: too many QA findings, long fix cycle
11 Solution: developer self-QA, Chromatic automated regressionA complete pipeline view of Sprint 3 feature delivery with cycle times, stage durations, and identified bottlenecks.
1/* SPRINT 3 PIPELINE DASHBOARD
2 Tracked in Notion: Design System > Sprints > Sprint 3
3
4=== FEATURE: Lesson Item Component ===
5
6Brief created: 2026-06-01 (PM: scope confirmed)
7Design started: 2026-06-02 (wireframe phase)
8Handoff announced: 2026-06-02 (same day — quick component)
9Impl started: 2026-06-03 (developer reviewed Loom)
10PR opened: 2026-06-05 (self-QA done, 2 findings fixed)
11QA sign-off: 2026-06-06 (1 Low finding, fixed same day)
12Deployed: 2026-06-07
13
14Total cycle: 6 days
15Stage breakdown:
16 Brief → design: 1 day
17 Design → handoff: 0 days (same day)
18 Handoff → impl: 1 day (developer review time)
19 Impl → PR: 2 days (implementation)
20 PR → QA: 1 day (QA session + fix)
21 QA → deploy: 1 day
22
23Bottleneck: None significant
24Note: Fastest component in sprint — used existing design system patterns
25
26=== FEATURE: Enrollment Bar (Sticky CTA) ===
27
28Brief created: 2026-06-01
29Design started: 2026-06-02
30Handoff announced: 2026-06-04 (2 extra days: iOS Safari complexity)
31Impl started: 2026-06-04 (developer started same day)
32PR opened: 2026-06-07 (extra day: iOS prototype testing)
33QA sign-off: 2026-06-09 (2 findings: shadow + bar height)
34Deployed: 2026-06-10
35
36Total cycle: 9 days
37Stage breakdown:
38 Brief → design: 1 day
39 Design → handoff: 2 days (iOS complexity exploration)
40 Handoff → impl: 0 days
41 Impl → PR: 3 days (iOS prototype + main implementation)
42 PR → QA: 2 days (2 QA sessions for 2 findings)
43 QA → deploy: 1 day
44
45Bottleneck: Implementation (3 days)
46Reason: iOS Safari position:fixed bug required a day of exploration
47Fix for next time: Identify iOS-specific patterns in brief/design stage
48 (not discovered in implementation stage)
49
50=== SPRINT 3 AGGREGATE METRICS ===
51
52Average cycle time: 7.5 days
53Fastest: 6 days (Lesson Item)
54Slowest: 9 days (Enrollment Bar)
55
56Stage time distribution:
57 Design: 25% of total time
58 Implementation: 40% of total time ← Longest stage
59 QA: 20% of total time
60 Handoff/Deploy: 15% of total time
61
62QA findings per component:
63 Lesson Item: 3 (2 self-QA, 1 designer)
64 Enrollment Bar: 2 (0 self-QA, 2 designer)
65Note: Enrollment Bar had no self-QA findings (zero iOS browser testing)
66
67Retro actions from cycle time review:
68 1. iOS Safari testing added to developer self-QA checklist
69 Action: @developer updates checklist by Sprint 4 start
70 2. Complex components (like sticky bars) get a prototype in design stage
71 Action: @designer adds 'complexity flag' to design brief template
72 3. QA session increased from 30 to 60 min for complex components
73 Action: @designer reserves longer slots for Sprint 4 QA
74
75=== SPRINT 4 TARGETS (based on Sprint 3 learnings) ===
76
77Target average cycle: 7 days (-0.5 days improvement)
78Target QA findings: <3 total across all features
79New process: iOS Safari test in self-QA (prevents 1 day blocker)
80New process: Prototype for sticky/fixed elements before handoff
81*/The pipeline dashboard reveals the Enrollment Bar's implementation stage was the bottleneck (3 days instead of 2) because the iOS Safari issue was not discovered until the developer started implementing. The retrospective action item (add iOS testing to self-QA checklist) directly addresses this root cause. The sprint 4 targets are specific and measurable — not 'be better' but 'average 7 days and <3 QA findings.' This data-driven approach to pipeline improvement is what separates teams that steadily improve from teams that repeat the same delays every sprint.
The next lesson covers Design Documentation — how to write, organize, and maintain design system documentation that stays current as the system evolves, and how to use Storybook MDX for living documentation.
Your progress is saved in this browser, on this device only.