Understand the four models of design-developer collaboration — waterfall, agile, embedded, and continuous — and the communication patterns, tooling, and shared vocabulary that make each work.
Most design-developer friction does not come from technical incompatibility — it comes from mismatched expectations about process, vocabulary, and ownership. A developer who understands the collaboration model being used, speaks the same language as their designer, and knows how to give useful feedback becomes dramatically more effective. This lesson lays the foundation for all subsequent collaboration topics.
Waterfall handoff: design is complete before development begins. Designers produce comprehensive specs; developers build from them. Predictable but inflexible — late-discovered technical constraints require design rework. Common in agencies and large enterprises. Agile parallel: design and development run in parallel sprints, typically one sprint apart. Design works ahead of engineering. Regular syncs at sprint boundaries. Requires discipline to keep design far enough ahead without designing features that get de-scoped. Embedded designer: a designer is embedded in the engineering team, attending standups and planning sessions. High communication bandwidth, fast feedback loops, blurred role boundaries. Works well for product teams building complex workflows. Continuous collaboration: no formal handoff — designers and developers work together in real time using shared tools (Figma + live preview, VS Code + Figma plugin). Highest quality output, highest coordination overhead. Best for small teams with tight design-engineering alignment. Most teams operate in agile parallel with elements of embedded designer depending on the feature.
Designers and developers use different words for the same concepts — and the same words for different concepts. This creates misunderstandings that cost hours of rework. Key translations: 'padding' to a designer means any space inside an element; in CSS it is specifically the space between border and content. 'Component' to a designer is a reusable Figma symbol; to a developer it is a React/Vue/Angular component. These map well but have different composition models. 'Spacing' to a designer is the gap between elements (CSS: gap or margin). 'Breakpoint' to a designer is a frame width; in CSS it is a media query threshold. 'Opacity' to a designer is a layer opacity; in CSS opacity affects an entire element and its children, which is not always what the designer intended (use rgba() instead for colour-only opacity).
1/* Vocabulary bridge: designer intent → CSS implementation */
2
3/* Designer: 'This button has 16px padding' */
4.button {
5 padding: 1rem; /* Or: padding-block: 0.5rem; padding-inline: 1rem; */
6}
7
8/* Designer: 'The card has 24px spacing between it and the next card' */
9.card + .card {
10 margin-block-start: 1.5rem; /* Or use gap in the parent grid */
11}
12
13/* Designer: 'The overlay is 60% opacity black' */
14/* Wrong: opacity: 0.6 (affects children too) */
15/* Right: rgba or color-mix */
16.overlay {
17 background-color: rgb(0 0 0 / 0.6); /* Modern syntax */
18}A collaboration agreement is a 1-page document that answers five questions: (1) What format will design files be in at handoff? (Figma frame with Dev Mode annotations, Figma with linked tokens, etc.) (2) What does 'ready for development' mean? (All states designed, responsive frames included, accessibility annotations added?) (3) How do developers give design feedback? (Figma comments, Slack, PR review?) (4) What is the expected response time for design questions during a sprint? (4 hours? Same business day?) (5) Who has final decision authority on design implementation disputes? Writing this down prevents the most common collaboration friction: developers building something and getting significant design changes after the fact because 'ready' was never defined.
1/* Example Collaboration Agreement — Team Alpha */
2
3Handoff definition:
4 - All states present (default, hover, focus, disabled, error)
5 - Mobile (375px) and desktop (1440px) frames minimum
6 - Accessibility annotations in FigJam layer
7 - Design tokens linked to Figma Variables
8
9Feedback channel: Figma comments for design issues,
10 GitHub PR comments for implementation questions
11
12Response SLA: Designer responds to dev questions within 1 business day
13
14Decision authority:
15 - Visual/brand decisions: Designer
16 - Technical feasibility: Developer
17 - User experience disputes: escalate to PMMost design-developer collaboration is asynchronous — different time zones, different focus periods, different schedules. Effective async feedback is: specific (references exact location), actionable (asks a clear question or makes a specific suggestion), and low-friction for the receiver (does not require a synchronous meeting to resolve). In Figma, use comments with pin to frame a specific location. Start comments with a category tag: [Question], [Concern], [Suggestion], [Resolved]. In GitHub PRs, link to the relevant Figma frame in the PR description. When leaving a comment on a visual implementation, include a side-by-side comparison screenshot showing the design intent vs current implementation — this makes the gap concrete and unambiguous.
1/* Good async design feedback (Figma comment): */
2[Question] The hover state on the primary button uses a
3dark background (#1e40af) — should this also update the
4border colour or stay transparent? The spec doesn't show
5the focused+hover combination.
6
7/* Bad async design feedback: */
8"This looks wrong"
9"Can you fix the button?"
10
11/* GitHub PR description template */
12## Design Reference
13Figma: [Link to exact frame]
14Implementation notes:
15- [x] Default state matches spec
16- [x] Hover state implemented
17- [ ] Disabled state pending — waiting for design (comment #23)When a project has persistent design-developer friction, the root cause is almost always one of three things: model mismatch (the team is operating in waterfall but the project needs agile parallel — design isn't far enough ahead), vocabulary gap (the developer implemented a technically correct interpretation of the spec that differed from the designer's intent), or process breakdown (handoff criteria were unclear, feedback was not actionable, or decision authority was disputed). Diagnose by asking: at which point in the workflow did the friction start? If late in development (during QA): model mismatch or late design changes. If during implementation: vocabulary gap or unclear specs. If after delivery: criteria for 'done' were not agreed upfront. Each root cause has a different fix; trying to solve a model mismatch with better specs will not help.
1/* Collaboration health check — run monthly */
2
3Ask the team:
41. When did you last be surprised by a design change
5 after you thought a feature was built? (model mismatch)
62. Did you ever implement something the designer didn't intend
7 because the spec was ambiguous? (vocabulary gap)
83. Did you know who to ask when you had a design question?
9 (process clarity)
104. Did you get a response within the agreed SLA? (process adherence)
11
12Score: 0 surprises = healthy. Any yes = identify root cause and fix.A concrete checklist to establish collaboration foundations on a new project.
Next lesson covers Figma Dev Mode in depth — extracting CSS values, understanding the inspect panel, and using tokens to bridge design and code.
Your progress is saved in this browser, on this device only.