Working with Design¶

Design and engineering share a goal: ship products that users love and that actually work. But the path to that goal looks different from each perspective. Designers optimize for user experience, clarity, and delight. Engineers optimize for feasibility, maintainability, and performance. When these perspectives collide without structure, you get either pixel-perfect designs that can't be built, or technically elegant solutions that nobody wants to use.

This page is about making design-engineering collaboration generative rather than adversarial—not through hand-waving about "respect" or "empathy," but through clear processes, explicit ownership, and communication patterns that work across time zones.

What Problem This Solves¶

The most common design-engineering failures fall into predictable patterns:

The unbuildable design. Design delivers a beautiful mockup. Engineering looks at it and says "we can't do that." The design is either scrapped or built poorly. Weeks of design work wasted.

The implemented-but-wrong execution. Engineering builds what was in the Figma file, but misses the intent. Spacing is off. Interactions feel wrong. States are missing. Design is frustrated. Engineering is frustrated. Users notice.

The late integration. Design and engineering work in parallel but don't sync until the end. When they finally integrate, nothing fits. Rework ensues.

The design system gap. Engineering builds components that don't match the design system, or design creates new patterns without considering reusability. The product becomes inconsistent.

This page provides the structure to prevent these failures.

Ownership Model: Who Decides What¶

Clear ownership prevents conflict. Here's the model I recommend:

Decision	Owner	Contributors
User needs and problems	Design + Product	Engineering (context)
Visual design and aesthetics	Design	Engineering (constraints)
Interaction patterns	Design	Engineering (feasibility)
Technical implementation	Engineering	Design (intent)
Accessibility requirements	Design + Engineering (jointly)	QA
Performance trade-offs	Engineering	Design (impact on UX)
Design system decisions	Design + Engineering (jointly)	N/A
When to ship	Engineering	Product, Design (awareness)

The key insight: most good decisions happen in the middle columns. Design owns the "what the user sees," Engineering owns the "how it's built," but the quality of the product depends on how well these perspectives inform each other.

The feasibility conversation

The best time to discuss feasibility is before design is finalized. If Engineering first sees a design when it's "ready for handoff," you've already lost. Build the habit of early, informal feasibility checks.

When to Use This Framework¶

Use this framework when:

Your team ships user-facing products where design quality matters
You have dedicated designers working with your engineering team
You're experiencing friction, rework, or misalignment between design and engineering
You're setting up a new product squad with cross-functional collaboration

Don't use this framework when:

You're building internal tools where design investment is minimal
There's no dedicated designer (engineers make design decisions)
The relationship is already high-trust and these patterns are implicit

The Collaboration Cycle¶

Design-engineering collaboration is not a handoff. It's a continuous loop with multiple touchpoints through the lifecycle of a feature.

Phase 1: Discovery and Exploration¶

Design explores the problem space. Engineering should be involved—not to constrain ideas, but to provide context.

What Design does:

Researches user needs through interviews, data, and observation
Explores multiple solution directions through sketches and low-fidelity concepts
Identifies key user flows and decision points

What Engineering contributes:

Technical context that might influence solutions (existing patterns, system constraints, data availability)
Early feasibility signals: "that's straightforward" vs. "that would require significant infrastructure work"
Questions that surface hidden assumptions

Format: Informal sync (30 min) or async review of early concepts. The goal is divergent thinking, not convergence.

Pitfall to avoid: Engineering killing ideas too early with "we can't do that." At this stage, the goal is understanding the full solution space. Feasibility filters come later.

Phase 2: Design Iteration¶

Design develops solutions based on discovery insights. Engineering provides ongoing feasibility feedback.

What Design does:

Creates medium-fidelity mockups for key flows
Documents interaction patterns and states
Identifies edge cases and error states

What Engineering provides:

Feasibility reviews at key checkpoints (not just at the end)
Alternative approaches when designs hit technical constraints
Questions about states, loading, errors, and empty states—the things designers sometimes overlook

Format: Design review sessions (45-60 min) at 2-3 checkpoints during iteration. Async review works for smaller changes.

Key practice: The "spike before spec" approach. For novel interactions or technically uncertain features, Engineering runs a short technical spike in parallel with design iteration. This surfaces real constraints before design is finalized.

Phase 3: Detailed Design and Handoff¶

Design finalizes specifications for implementation. This is where precision matters.

What a good handoff includes:

Visual specs: Exact spacing, colors, typography, sizing (ideally linked to design system tokens)
Interaction specs: How elements respond to user input, transitions, animations
State specs: Default, hover, active, disabled, loading, error, empty states
Responsive behavior: How the design adapts across breakpoints
Accessibility specs: Focus order, screen reader labels, keyboard interactions
Edge cases: What happens with long text, missing data, failed loads

Format: Figma (or equivalent) with detailed annotations. A handoff meeting (30-45 min) walks through the design to surface questions.

The Figma file is not the spec

A Figma file shows what something looks like, but not always how it should behave. The handoff meeting is where Engineering asks questions about behavior, states, and edge cases. Never skip this.

Phase 4: Implementation¶

Engineering builds. Design reviews incrementally, not just at the end.

What happens:

Engineering implements in vertical slices (one flow at a time, not all components first)
Design reviews each slice before moving to the next
Issues are caught early, not accumulated until the end

Checkpoint cadence: For significant features, design review should happen at least twice: at a "50% done" point and before final QA.

How to structure reviews:

Engineering deploys to a staging environment or shares a Loom walkthrough
Design reviews against the spec and provides feedback
Feedback is categorized: "must fix" vs. "nice to have" vs. "future improvement"

Key practice: Don't let perfect be the enemy of shipped. Not every pixel needs to match. Focus on things that affect user experience—misaligned interactions, missing states, accessibility issues. Minor spacing tweaks can be follow-up tasks.

Phase 5: Iteration After Ship¶

Good products improve after launch. Design and Engineering continue collaborating based on user feedback.

What happens:

Team monitors how users interact with the shipped feature
Design identifies opportunities for refinement
Engineering provides input on quick wins vs. larger efforts
Iteration is planned alongside new work, not as an afterthought

What Good Looks Like¶

The partnership is working when you observe:

Signal	What it looks like
Early involvement	Engineering sees designs before they're "done," not just at handoff
Feasibility informs design	Design adapts to technical constraints without losing user value
Intent survives implementation	What ships feels like what was designed, even if details changed
Incremental review	Design feedback happens during build, not just at the end
Shared ownership of quality	Neither discipline blames the other when something doesn't work
Design system health	Components are reusable, documented, and jointly maintained
Trust	Design trusts Engineering to preserve intent; Engineering trusts Design to be flexible on details

Failure Modes and Mitigations¶

The Waterfall Handoff¶

Symptom: Design works in isolation for weeks, then delivers a complete spec. Engineering implements in isolation for weeks, then delivers a built feature. Neither sees the other's work until the end.

Root cause: Treating design and engineering as sequential phases rather than parallel collaborators.

Mitigation: Build in checkpoints. Design review at 30%, 60%, and 90%. Engineering feasibility checks during design iteration. No phase should last more than 1-2 weeks without cross-functional sync.

The Pixel Police¶

Symptom: Design sends back endless rounds of feedback on minor visual details. Engineering spends more time on tweaks than on functionality. Morale drops.

Root cause: Lack of shared definition of "done" and unclear prioritization of feedback.

Mitigation: Categorize feedback explicitly: P1 (must fix before ship), P2 (should fix soon), P3 (future improvement). Agree that P3 items can be logged and addressed later. Set a time-box for polish: "We have 2 days for polish. What's most important?"

The "We Can't Do That" Reflex¶

Symptom: Engineering rejects design ideas without exploring alternatives. Design feels unheard. The product becomes technically conservative and boring.

Root cause: Engineers see their role as gatekeeping rather than enabling. Or, previous bad experiences where saying "yes" led to pain.

Mitigation: Reframe the conversation. Instead of "we can't do that," say "that would be hard because X—but we could do Y, which gets most of the value." Always offer an alternative. Invest in the relationship so Design trusts that "hard" means hard, not "I don't want to."

The Missing States¶

Symptom: Design delivers happy-path mockups. Engineering implements them. In production, users encounter loading states, errors, and edge cases that nobody designed. The experience is inconsistent.

Root cause: Design focuses on the ideal flow; Engineering doesn't push back until implementation.

Mitigation: Make states a checklist. Before handoff, both Design and Engineering walk through: default, loading, error, empty, disabled, hover, focus, edge cases. If it's not designed, it's not ready for handoff.

The Design System Drift¶

Symptom: Every feature introduces new components. The codebase has multiple versions of buttons, modals, and forms. Designers create variations instead of reusing patterns.

Root cause: Design system is incomplete, hard to use, or not maintained. Or, there's no shared ownership.

Mitigation: Invest in the design system as infrastructure. Joint ownership between Design and Engineering. Regular sync (monthly) to review new patterns and decide what should be systematized. Make it easier to use the system than to create new components.

Remote-First Adaptations¶

Design collaboration is harder remote because you lose the ability to point at a screen together. Here are specific adaptations:

Loom for async reviews. A 5-minute Loom video walking through a design or implementation is worth more than a dozen comments. Use it for both design walkthroughs and engineering demonstrations.

Figma comments for small feedback. Minor issues can be flagged directly in Figma. Reserve meetings for discussions that require back-and-forth.

Shared Figma cursors for sync sessions. When you do meet, use Figma's collaboration features. Being able to point and draw together replaces the whiteboard.

Recording design reviews. If not everyone can attend, record the session. Async participants can watch and add comments.

Explicit response SLAs. Design review feedback should have a clear turnaround time (e.g., 24-48 hours). This prevents Engineering from waiting indefinitely for sign-off.

Time zone-friendly handoffs. If Design and Engineering are in different time zones, handoffs should be async-first with detailed documentation, not dependent on synchronous meetings.

Copy-Paste Artifact: Design Handoff Checklist¶

## Design Handoff Checklist

**Feature:** [Name]
**Designer:** [Name]
**Engineer(s):** [Names]
**Handoff Date:** [Date]

### Visual Specifications

- [ ] Colors use design system tokens
- [ ] Typography uses design system styles
- [ ] Spacing is specified (or uses system scale)
- [ ] All breakpoints are documented (mobile, tablet, desktop)

### States

- [ ] Default state
- [ ] Hover state
- [ ] Active/pressed state
- [ ] Focus state (keyboard navigation)
- [ ] Disabled state
- [ ] Loading state
- [ ] Error state
- [ ] Empty state

### Interactions

- [ ] Click/tap behavior documented
- [ ] Transitions and animations specified (or marked as "none")
- [ ] Form validation behavior documented
- [ ] Success/failure feedback documented

### Accessibility

- [ ] Focus order specified
- [ ] Screen reader labels provided for non-text elements
- [ ] Color contrast meets WCAG AA (4.5:1 for text)
- [ ] Touch targets are at least 44x44px

### Edge Cases

- [ ] Long text behavior (truncation, wrapping)
- [ ] Missing data handling
- [ ] Slow connection behavior
- [ ] Failed load handling

### Handoff Meeting

- [ ] Walkthrough completed with Engineering
- [ ] Questions documented and answered
- [ ] Implementation approach discussed
- [ ] Definition of Done agreed

Copy-Paste Artifact: Design Review Feedback Template¶

## Design Review Feedback

**Feature:** [Name]
**Build version:** [Staging URL or branch]
**Reviewed by:** [Designer name]
**Date:** [Date]

### Summary

[One sentence: overall assessment]

### P1 - Must Fix Before Ship

[Issues that significantly affect user experience or deviate from intent]

1. [Issue description + expected behavior]
2. [Issue description + expected behavior]

### P2 - Should Fix Soon

[Issues that affect quality but don't block ship]

1. [Issue description + expected behavior]
2. [Issue description + expected behavior]

### P3 - Future Improvement

[Nice-to-haves that can be logged for later]

1. [Suggestion]
2. [Suggestion]

### What's Working Well

[Positive callouts—implementation that nailed the intent]

1. [Callout]
2. [Callout]

### Questions for Engineering

[Clarification needed before finalizing feedback]

1. [Question]
2. [Question]

Copy-Paste Artifact: Design-Engineering Sync Agenda¶

## Design-Engineering Weekly Sync

**Date:** [Date]
**Attendees:** [Designer], [Engineer(s)], [optional: PM]
**Duration:** 30 minutes

### 1. Current Work (10 min)

- What's in progress?
- Any blockers or questions?
- Design reviews needed?

### 2. Upcoming Work (10 min)

- What's coming next?
- Feasibility concerns to discuss?
- Design checkpoints to schedule?

### 3. Design System (5 min)

- Any new patterns introduced?
- Components that need documentation?
- Reuse opportunities identified?

### 4. Relationship Check (5 min)

- Is the collaboration working?
- Anything to adjust in how we work together?

### Action Items

- [ ] [Owner]: [Action]
- [ ] [Owner]: [Action]

Copy-Paste Artifact: Feasibility Review Request¶

## Feasibility Review Request

**Designer:** [Name]
**Date:** [Date]
**Feature:** [Name]

### Context

[Brief description of what we're trying to achieve]

### Design Approach

[Link to Figma or description of the proposed solution]

### Specific Questions

1. **Overall feasibility:** Is this buildable with reasonable effort?
2. **Technical concerns:** Anything that would be especially hard or risky?
3. **Existing patterns:** Can we reuse existing components or would this require new ones?
4. **Performance:** Any concerns about load time, rendering, or responsiveness?
5. **Alternatives:** If parts of this are hard, what alternatives might achieve similar goals?

### Timeline Context

[When does Design need feedback? When would Engineering need to build this?]

---

**Engineering Response:**

**Overall assessment:** [Straightforward / Moderate / Complex / Needs investigation]

**Key concerns:**

1. [Concern + impact]
2. [Concern + impact]

**Suggested alternatives:**

1. [Alternative approach]
2. [Alternative approach]

**Questions for Design:**

1. [Question]
2. [Question]

**Estimated spike needed:** [None / X days for investigation]

The Design System Partnership¶

Design systems deserve special mention because they sit at the intersection of design and engineering. A healthy design system requires joint ownership.

What Design owns:

Visual language (colors, typography, spacing, iconography)
Component specifications (how components should look and behave)
Pattern documentation (when to use which patterns)

What Engineering owns:

Component implementation (code that matches specs)
Technical documentation (API, props, usage examples)
Performance and accessibility of implemented components

What both own:

Deciding when to add new patterns vs. reuse existing ones
Maintaining consistency between Figma and code
Evolving the system over time

Recommended ritual: Monthly design system sync (30-45 min) where Design and Engineering review new patterns, address inconsistencies, and plan improvements.