Design-Development Integration | Seamless Handoffs
Bridge design and development workflows with seamless handoffs, design QA, and continuous collaboration. GitScrum links design specs to development tasks.
15 min read
Design and development integration eliminates costly rework, speeds delivery, and improves product quality. The key is breaking down silos through shared tools, overlapping processes, and continuous collaboration rather than sequential handoffs. GitScrum provides the collaborative infrastructure to unite design and development workflows.
The Integration Challenge
Common problems with separated workflows:
| Design Silo | Development Silo |
|---|---|
| Design in isolation | Build what specs say |
| Surprise constraints | Surprise requirements |
| Finished designs modified | "Not what I designed" |
| Late feasibility discoveries | Late design changes |
| Rework cycles | Rework cycles |
Workflow Integration Models
Collaboration Levels
DESIGN-DEV INTEGRATION MATURITY:
┌─────────────────────────────────────────────────────────────┐
│ INTEGRATION SPECTRUM │
├─────────────────────────────────────────────────────────────┤
│ │
│ LEVEL 1: WATERFALL HANDOFF (Most Friction) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ Design Phase ──────────→ Handoff ──────→ Build Phase ││
│ │ (Weeks) (Specs) (Weeks) ││
│ │ ││
│ │ ❌ No overlap, maximum rework ││
│ │ ❌ Feasibility issues found late ││
│ │ ❌ Design changes are expensive ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ LEVEL 2: PARALLEL SPRINTS (Better) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ Sprint N: Design works on Sprint N+1 features ││
│ │ Dev builds Sprint N designs ││
│ │ ││
│ │ ✓ Design stays 1 sprint ahead ││
│ │ ✓ Regular sync points ││
│ │ ✗ Still handoff-based ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ LEVEL 3: SAME SPRINT, PHASES (Good) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ Sprint Week 1: Design + Dev collaborate on concepts ││
│ │ Sprint Week 2: Dev builds while Design refines ││
│ │ ││
│ │ ✓ Faster feedback ││
│ │ ✓ Shared understanding ││
│ │ ✗ Still some sequential work ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ LEVEL 4: CONTINUOUS PAIRING (Best) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ Design + Dev work together throughout: ││
│ │ ├── Designer on dev team (or embedded) ││
│ │ ├── Pair on complex interactions ││
│ │ ├── Prototype in code early ││
│ │ └── Design evolves with build ││
│ │ ││
│ │ ✓ Minimal rework ││
│ │ ✓ Technical constraints inform design ││
│ │ ✓ Real product testing ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Task Structure for Design Work
Design Task Types
DESIGN WORK IN GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ DESIGN TASK TAXONOMY │
├─────────────────────────────────────────────────────────────┤
│ │
│ DISCOVERY TASKS (Pre-Sprint): │
│ ├── Label: "design:discovery" │
│ ├── Purpose: Research, understand problem │
│ └── Output: Problem definition, user insights │
│ │
│ EXPLORATION TASKS: │
│ ├── Label: "design:exploration" │
│ ├── Purpose: Multiple solution concepts │
│ └── Output: Concept options for review │
│ │
│ DESIGN SPEC TASKS: │
│ ├── Label: "design:spec" │
│ ├── Purpose: Final designs ready for dev │
│ └── Output: Figma/Sketch files, specs, assets │
│ │
│ REVIEW TASKS: │
│ ├── Label: "design:review" │
│ ├── Purpose: QA implementation matches design │
│ └── Output: Approval or feedback │
│ │
│ SYSTEM TASKS: │
│ ├── Label: "design:system" │
│ ├── Purpose: Design system components │
│ └── Output: Component library updates │
│ │
│ GITSCRUM WORKFLOW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ To Do → In Design → Design Review → Ready for Dev → ││
│ │ In Progress → Code Review → Design QA → Done ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Linking Design and Dev Tasks
CONNECTED TASK STRUCTURE:
┌─────────────────────────────────────────────────────────────┐
│ FEATURE: User Profile Editing │
├─────────────────────────────────────────────────────────────┤
│ │
│ DESIGN TASK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Title: Design profile edit flow ││
│ │ Type: design:spec ││
│ │ Assignee: @designer ││
│ │ Status: Done ✓ ││
│ │ ││
│ │ Description: ││
│ │ Create designs for profile editing including: ││
│ │ - Edit form layout ││
│ │ - Validation states ││
│ │ - Avatar upload ││
│ │ - Success/error feedback ││
│ │ ││
│ │ Attachments: ││
│ │ └── 🔗 Figma: Profile Edit Designs ││
│ │ ││
│ │ Linked Tasks: ││
│ │ └── → Blocks: "Implement profile edit" (DEV-234) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DEVELOPMENT TASK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Title: Implement profile edit ││
│ │ Type: feature ││
│ │ Assignee: @developer ││
│ │ Status: In Progress ││
│ │ ││
│ │ Description: ││
│ │ Build profile editing per designs: ││
│ │ 🔗 Design specs: [Figma link] ││
│ │ ││
│ │ Acceptance Criteria: ││
│ │ - [ ] Form matches Figma layout ││
│ │ - [ ] Validation per design states ││
│ │ - [ ] Avatar upload with preview ││
│ │ - [ ] Success toast on save ││
│ │ - [ ] @designer QA approval ││
│ │ ││
│ │ Linked Tasks: ││
│ │ ├── ← Depends on: "Design profile edit" (DES-123) ✓ ││
│ │ └── → Triggers: "Design QA: Profile edit" (DES-124) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Handoff Best Practices
Effective Design Specs
DESIGN HANDOFF CHECKLIST:
┌─────────────────────────────────────────────────────────────┐
│ WHAT DEVELOPERS NEED FROM DESIGNERS │
├─────────────────────────────────────────────────────────────┤
│ │
│ VISUAL SPECIFICATIONS: │
│ ├── [ ] Spacing and dimensions (pixels or design tokens) │
│ ├── [ ] Colors (hex codes or design token names) │
│ ├── [ ] Typography (font, size, weight, line height) │
│ ├── [ ] Shadows, borders, radius │
│ └── [ ] Responsive breakpoints │
│ │
│ COMPONENT STATES: │
│ ├── [ ] Default state │
│ ├── [ ] Hover state │
│ ├── [ ] Active/pressed state │
│ ├── [ ] Focus state (accessibility) │
│ ├── [ ] Disabled state │
│ ├── [ ] Loading state │
│ └── [ ] Error state │
│ │
│ CONTENT VARIATIONS: │
│ ├── [ ] Minimum content (empty states) │
│ ├── [ ] Maximum content (truncation rules) │
│ ├── [ ] Edge cases (long names, missing data) │
│ └── [ ] Different languages (text expansion) │
│ │
│ INTERACTION BEHAVIOR: │
│ ├── [ ] Transitions and animations │
│ ├── [ ] Gesture behavior (mobile) │
│ ├── [ ] Keyboard navigation │
│ └── [ ] Scroll behavior │
│ │
│ ASSETS: │
│ ├── [ ] Icons (SVG preferred) │
│ ├── [ ] Images (resolution, format) │
│ └── [ ] Export settings documented │
│ │
│ CONTEXT: │
│ ├── [ ] Why this design (user need) │
│ ├── [ ] What's flexible vs. fixed │
│ └── [ ] Known technical constraints │
│ │
└─────────────────────────────────────────────────────────────┘
Avoiding Handoff Friction
COMMON HANDOFF PROBLEMS AND SOLUTIONS:
┌─────────────────────────────────────────────────────────────┐
│ FRICTION POINTS │
├─────────────────────────────────────────────────────────────┤
│ │
│ ❌ PROBLEM: "Where are the designs?" │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Designer emails file → Gets lost → Dev asks again ││
│ │ ││
│ │ ✓ SOLUTION: Single source of truth ││
│ │ ├── Figma link always in task description ││
│ │ ├── Design file linked before dev starts ││
│ │ └── Updates announced in task comments ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ❌ PROBLEM: "Design changed, I already built it" │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Designer updates Figma → Dev doesn't notice → Rework ││
│ │ ││
│ │ ✓ SOLUTION: Change notification process ││
│ │ ├── Comment on task when design updates ││
│ │ ├── Tag affected developers ││
│ │ └── Use GitScrum Discussions for design changes ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ❌ PROBLEM: "This is technically impossible" │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Design finalized → Dev finds constraint → Redesign ││
│ │ ││
│ │ ✓ SOLUTION: Early dev involvement ││
│ │ ├── Dev reviews concepts before finalizing ││
│ │ ├── Feasibility check as design gate ││
│ │ └── Prototype complex interactions in code ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ❌ PROBLEM: "It doesn't match the design" │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Dev builds → Design QA fails → Back and forth ││
│ │ ││
│ │ ✓ SOLUTION: Incremental review ││
│ │ ├── Daily design check-in during build ││
│ │ ├── Share WIP screenshots in task comments ││
│ │ └── Address issues as they emerge ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Continuous Collaboration
Design in Sprint Ceremonies
DESIGNER PARTICIPATION IN SCRUM:
┌─────────────────────────────────────────────────────────────┐
│ CEREMONIES WITH DESIGN INTEGRATION │
├─────────────────────────────────────────────────────────────┤
│ │
│ SPRINT PLANNING: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Designer Role: ││
│ │ ├── Present designs for sprint items ││
│ │ ├── Answer dev questions on specs ││
│ │ ├── Commit to design work in sprint ││
│ │ └── Identify design dependencies ││
│ │ ││
│ │ Timing: Design work for Sprint N should be done ││
│ │ before Sprint N planning (design 1 sprint ahead) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DAILY STANDUP: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Designer Reports: ││
│ │ ├── Design tasks in progress ││
│ │ ├── Blockers needing dev input ││
│ │ ├── Design review capacity ││
│ │ └── Design changes affecting in-progress work ││
│ │ ││
│ │ Avoid: Long design discussions in standup ││
│ │ Do: Schedule separate sync if needed ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SPRINT REVIEW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Design Involvement: ││
│ │ ├── Present design decisions ││
│ │ ├── Compare implementation to design ││
│ │ ├── Gather stakeholder design feedback ││
│ │ └── Celebrate design-dev collaboration wins ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RETROSPECTIVE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Design Topics: ││
│ │ ├── Handoff process effectiveness ││
│ │ ├── Communication gaps ││
│ │ ├── Design-dev sync timing ││
│ │ └── Design tool/process improvements ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Pairing Practices
DESIGN-DEV COLLABORATION SESSIONS:
┌─────────────────────────────────────────────────────────────┐
│ WHEN TO PAIR │
├─────────────────────────────────────────────────────────────┤
│ │
│ DESIGN REVIEW PAIRING (30 min): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ When: Before dev starts a task ││
│ │ Who: Designer + Developer ││
│ │ What: ││
│ │ ├── Walk through designs together ││
│ │ ├── Discuss implementation approach ││
│ │ ├── Identify edge cases ││
│ │ └── Agree on what's flexible ││
│ │ ││
│ │ Output: Shared understanding, annotated designs ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PROTOTYPE PAIRING (1-2 hrs): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ When: Complex interactions, unclear feasibility ││
│ │ Who: Designer + Developer ││
│ │ What: ││
│ │ ├── Designer describes interaction intent ││
│ │ ├── Developer codes rough prototype ││
│ │ ├── Iterate together in real-time ││
│ │ └── Discover constraints together ││
│ │ ││
│ │ Output: Working prototype, validated design ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ IMPLEMENTATION CHECK (15 min): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ When: Mid-build, before code review ││
│ │ Who: Designer + Developer ││
│ │ What: ││
│ │ ├── Quick visual comparison ││
│ │ ├── Catch issues early ││
│ │ └── Adjust before too late ││
│ │ ││
│ │ Output: Early feedback, prevent rework ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Design QA Process
Quality Assurance Workflow
DESIGN QA IN GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ DESIGN QA WORKFLOW │
├─────────────────────────────────────────────────────────────┤
│ │
│ STEP 1: DEV REQUESTS DESIGN QA │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Developer: ││
│ │ ├── Moves task to "Design QA" column ││
│ │ ├── Adds comment: "Ready for design review" ││
│ │ ├── Links to staging/preview URL ││
│ │ └── @mentions designer ││
│ │ ││
│ │ GitScrum Task Comment: ││
│ │ "@designer Ready for design QA ││
│ │ Preview: https://staging.app.com/feature ││
│ │ Test account: test@example.com / password123" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ STEP 2: DESIGNER REVIEWS │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Designer Checks: ││
│ │ ├── [ ] Visual accuracy vs. designs ││
│ │ ├── [ ] All states implemented ││
│ │ ├── [ ] Responsive behavior ││
│ │ ├── [ ] Animations/transitions ││
│ │ ├── [ ] Edge cases handled ││
│ │ └── [ ] Accessibility basics ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ STEP 3: FEEDBACK │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ If Issues Found: ││
│ │ ├── Screenshot with annotations ││
│ │ ├── Compare to Figma (side-by-side) ││
│ │ ├── Severity: Critical / Major / Minor ││
│ │ └── Move task back to "In Progress" ││
│ │ ││
│ │ If Approved: ││
│ │ ├── Comment: "Design QA ✓" ││
│ │ └── Move task to "Done" or next stage ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FEEDBACK TEMPLATE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Design QA Feedback: ││
│ │ ││
│ │ 🔴 Critical (blocks release): ││
│ │ - Button color wrong (#FF0000 should be #E53935) ││
│ │ ││
│ │ 🟡 Major (needs fix this sprint): ││
│ │ - Spacing below header is 16px, should be 24px ││
│ │ [Screenshot attached] ││
│ │ ││
│ │ 🟢 Minor (can fix later): ││
│ │ - Font weight on helper text slightly off ││
│ │ ││
│ │ ✓ Great: Animation on submit button is perfect! ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Design System Integration
Shared Component Language
DESIGN SYSTEM AS BRIDGE:
┌─────────────────────────────────────────────────────────────┐
│ UNIFIED COMPONENT SYSTEM │
├─────────────────────────────────────────────────────────────┤
│ │
│ DESIGN TOKENS (Shared Language): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ FIGMA (Design) CODE (Dev) ││
│ │ ────────────── ───────── ││
│ │ color/primary/500 ↔ --color-primary-500 ││
│ │ spacing/lg ↔ --spacing-lg (24px) ││
│ │ radius/md ↔ --radius-md (8px) ││
│ │ shadow/card ↔ --shadow-card ││
│ │ ││
│ │ BENEFIT: Same names = no translation needed ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ COMPONENT MAPPING: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Figma Component → Code Component ││
│ │ ─────────────── ────────────── ││
│ │ Button/Primary/Large → <Button variant="primary" ││
│ │ size="lg" /> ││
│ │ ││
│ │ Card/Elevated → <Card elevation="high" /> ││
│ │ ││
│ │ Input/Error → <Input state="error" /> ││
│ │ ││
│ │ BENEFIT: Designers use component names from code ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DESIGN SYSTEM TASKS IN GITSCRUM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ When designer creates new pattern: ││
│ │ ││
│ │ Task 1: Design new Alert component (design:system) ││
│ │ ├── Create in Figma component library ││
│ │ ├── Document variants and states ││
│ │ └── Link to: Task 2 ││
│ │ ││
│ │ Task 2: Implement Alert component (frontend) ││
│ │ ├── Build React/Vue component ││
│ │ ├── Add to Storybook ││
│ │ └── Depends on: Task 1 ││
│ │ ││
│ │ Task 3: Document Alert (documentation) ││
│ │ ├── Usage guidelines ││
│ │ └── Code examples ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Communication Channels
Discussion Organization
DESIGN-DEV COMMUNICATION IN GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ COMMUNICATION CHANNELS │
├─────────────────────────────────────────────────────────────┤
│ │
│ TASK COMMENTS (Specific Decisions): │
│ ├── Design clarifications for that task │
│ ├── Implementation questions │
│ ├── Design change notifications │
│ └── QA feedback │
│ │
│ DISCUSSIONS (Broader Topics): │
│ ├── Category: "Design" │
│ ├── Topics: │
│ │ ├── Design system proposals │
│ │ ├── Pattern library additions │
│ │ ├── Cross-feature design consistency │
│ │ └── Tool/process changes │
│ └── Long-term reference for decisions │
│ │
│ NOTEVAULT (Documentation): │
│ ├── Design principles │
│ ├── Brand guidelines │
│ ├── Component documentation │
│ ├── Handoff process guide │
│ └── Design-dev agreement/contract │
│ │
│ REAL-TIME (Quick Sync): │
│ ├── Slack/Teams for immediate questions │
│ └── Pairing sessions for complex work │
│ │
└─────────────────────────────────────────────────────────────┘
Best Practices
Do's
DESIGN-DEV INTEGRATION SUCCESS:
✓ DESIGNERS ON TEAM
Embed designers in development teams
✓ EARLY INVOLVEMENT
Include devs in design exploration
✓ SINGLE SOURCE
Figma links always in task descriptions
✓ DESIGN QA AS GATE
Required step before task completion
✓ COMPONENT THINKING
Shared design system language
✓ CONTINUOUS FEEDBACK
Daily touchpoints, not handoff-based
Don'ts
INTEGRATION ANTI-PATTERNS:
✗ WATERFALL HANDOFFS
Completed designs thrown over wall
✗ DESIGN CHANGES UNANNOUNCED
Updates without developer notification
✗ PIXEL-PERFECT OBSESSION
Blocking release for minor differences
✗ SEPARATE TOOLS
Designers can't see dev progress and vice versa
✗ NO DESIGN QA
Assuming implementation matches design