3.8 — Design handoff & collaboration

Opening scenario

A designer DMs you at 4:30pm Friday: “Hey, can you ship the new onboarding by Monday?” You open Figma. There are 23 frames, two pages, one branch with the “real” version, a Slack thread with 80 messages about copy revisions, three Loom videos of animation references, a PRD in Notion that’s two weeks stale, and a sign-off comment from product on the wrong frame.

You ship something Monday. The designer says “that’s not what I designed.” The PM says “that’s not what I approved.” The frames in Figma changed twice over the weekend.

Design handoff is a process problem, not a tool problem. Tools enable; process prevents disasters. This chapter is the playbook.

Concept → Why → How → Code

The “ready for dev” status

Every Figma frame intended for engineering must be marked explicitly as ready. Figma supports this natively:

1. Right-click a frame → Section settings → Status
2. Choose: Draft, In Progress, Ready for Dev, Complete
3. The status badge appears on the frame in Dev Mode

In Dev Mode, engineers can filter to only Ready for Dev frames. Designers can grep their own pages: “anything still in WIP that I shouldn’t have promoted?”

The rule: never implement a frame without a status, never change a Ready-for-Dev frame without coordination. Designers who change a “Ready” frame silently are the cause of half the world’s botched releases.

The branch model

Figma supports branches like git. Big design changes (multi-screen redesign, new feature flow) live in a branch:

1. From main file → Branch → name it (onboarding-v2)
2. Designer iterates on the branch
3. Engineers can preview but don’t implement until merge
4. Designer requests review → other designers comment → merge to main
5. Engineers pick up implementation from main

Smaller tweaks (color adjustment, copy change) can happen on main with version naming: “v2.3 — copy revisions, see comment.”

Dev Mode workflow — the engineer’s daily

1. Open Figma in Dev Mode
2. Filter to “Ready for Dev” status (top filter)
3. For each frame, inspect:
   • Layout (Auto Layout structure → stack hierarchy)
   • Tokens (variables panel → color and spacing names)
   • Assets (download what you need at the right format)
   • Code preview (starting point, not final)
4. Ask any clarifying questions as Figma comments on the frame, not in Slack
5. Implement
6. Drop a Loom or screenshot reply on the comment thread once done: “Shipped in PR #1234”

Comments on the frame stay forever as design history. Slack messages die in 90 days. Future-you will thank present-you.

Redlines without redlines

Old workflow: designer drew red boxes with “8pt”, “16pt”, “20pt” annotations. Dead since Figma Dev Mode (2023). Now:

• Engineer hovers a layer → see padding/margin to siblings automatically
• Holds ⌥ → measures distance to any other layer
• Selects two layers → spacing between them shows up

Designers should not be drawing redlines anymore. If yours is, send them a Figma Dev Mode tutorial video.

Specs that aren’t visual

Some things Figma can’t show:

• States: empty, loading, error, pending, retry
• Animations: transitions between states
• Edge cases: very long text, zero items, max-int amounts
• Behavior: tap, long-press, drag, pull-to-refresh
• Copy: localization, plurals, gender forms
• Accessibility: VoiceOver labels, traits

Each of these needs explicit specification. Where:

If a designer hands you a single “happy path” frame and nothing else, the design is incomplete. Push back: “What’s the empty state? What if the API errors? What if the username is 30 characters?”

Design ↔ engineering PR review

Engineers review design PRs in Figma:

• Designer creates a branch
• Engineer reviews: “this Auto Layout structure would break on iPad — can we use a LazyVGrid pattern?” “This color uses a hex code, not a token — can we add it to variables?”
• Designer iterates
• Merge

Designers review engineering PRs in the simulator:

• Engineer ships a TestFlight build with the new feature
• Designer opens it on device, compares to Figma frame
• Files Figma comments with screenshots: “8pt of bottom padding missing” / “wrong color token”
• Engineer fixes, ships another build
• Designer signs off

Both directions are cheap with the right tooling. The bottleneck is culture, not tools.

The handoff meeting

You don’t always need one. Async-first works for 80% of cases. When you do meet:

• Designer screen-shares the Figma file
• Walks each “Ready for Dev” frame: design intent, edge cases, states
• Engineer asks questions live, designer adds Figma comments capturing the resolutions
• 15-30 minutes per feature, weekly cadence

The meeting outputs Figma comments, not minutes in a Notion doc. Comments live where the work lives.

Tooling stack — what mature teams use

You don’t need all of these. Pick the ones that solve your team’s bottlenecks.

Localization handoff — the often-ignored channel

Strings in Figma should reference the localization key, not just the English copy:

[onboarding.title]
Welcome to Acme

Designer maintains a strings file (often a Google Sheet or Lokalise project) where each key has translations. Engineers read keys from the spreadsheet via CI, generating Localizable.xcstrings (the modern Xcode 15+ format).

For Dynamic Type, designers should preview “DE” (German — verbose) and “JA” (Japanese — compact) variants in Figma. German strings ~30% longer than English; Japanese strings shorter. Layouts that work in English break in German.

In the wild

• Linear (the project management tool) ships its Figma library and Swift component library on the same release schedule — one PR touches both.
• Apple’s design team uses Figma extensively for app design specs (per public job postings). The handoff to Cupertino engineering teams reportedly uses Figma comments + screen recordings.
• Shopify open-sources Polaris — their design system. Worth reading their docs on contribution model: PRs to design tokens flow through a tooling pipeline.
• Notion’s Aristotle design system — case study on bidirectional design-engineering collaboration.

Common misconceptions

1. “Handoff is the designer dumping a Figma link in Slack.” That’s not handoff; that’s a notification. Handoff is structured: status, specs for all states, redlines via Dev Mode, sign-off process.
2. “Engineering shouldn’t push back on design.” Engineering must push back on design that can’t be reasonably implemented or that violates HIG. Designers welcome it from engineers who explain why.
3. “Design QA is gating.” Treat design QA as collaborative review, not a gate. Otherwise designers become bottlenecks. Empower engineers to ship “design-approved patterns” without per-screen sign-off where possible.
4. “Designers should learn to code.” Not necessarily. They should learn to spec well — which is a separate, valuable skill. Code is for engineers; specs are for designers.
5. “This process is overkill for a small team.” Even 2 people benefit from explicit status labels. The cost is 30 seconds per frame; the payoff is zero “wait, was that ready?” Slack threads.

Seasoned engineer’s take

The best designer-engineer relationships I’ve seen all share one trait: they ship together. Designer ships the Figma, engineer ships the PR, both review each other’s work, both sign off. No gate, no over-the-fence handoff.

Cultural shift, not tool shift. The tools (Figma branches, Dev Mode, Tokens Studio) make it possible; the culture makes it happen. If your designer treats engineers as implementers, fix the culture first.

A short list of things to insist on, kindly but firmly:

1. Status labels on every frame. Non-negotiable.
2. Auto Layout — not pixel-pushing.
3. Variables/tokens — not raw hex.
4. All states — not just the happy path.
5. Comments on frames, not DMs in Slack.

If a designer fights you on these, you’re not at a serious shop. (Or the designer is junior — coach them.)

TIP: Use Figma’s “Observe” feature when pair-debugging design issues — your cursor follows the designer’s in real time. Better than screen-share for design reviews.

WARNING: Don’t implement from screenshots. Always work from the live Figma. Screenshots go stale the moment the designer iterates.

Interview corner

Junior-level: “How do you know a design is ready for you to implement?”

The frame has a status of “Ready for Dev” set by the designer in Figma. Specs exist for all states (loading, empty, error). I have asset exports and design tokens available. If anything is unclear, I drop a comment on the frame, not in Slack.

Mid-level: “Walk me through your design handoff process.”

Designer marks frames “Ready for Dev.” I open Dev Mode, inspect Auto Layout structure, download assets, note tokens. I implement, file Figma comments for anything ambiguous. I ship a TestFlight build; designer compares to Figma and files comments. I fix; designer signs off via a comment. We don’t have sync handoff meetings — it’s all async unless something complex needs a 15-min call.

Senior-level: “You join a team where design and engineering communicate badly. What do you change first?”

(1) Diagnose: where’s the actual friction? Spec quality? Status visibility? Sign-off ambiguity? (2) Lowest-cost win: get everyone using Figma frame status. (3) Tokens pipeline so color/spacing changes don’t require coordination. (4) Pair design and engineering on a sample feature end-to-end; the experience builds empathy. (5) Quarterly retros where both sides air complaints in a structured way. Tools don’t fix culture; culture changes change tools.

Red flag in candidates: “I just implement what’s in Figma.” Means they don’t push back, don’t review specs, don’t catch edge cases. You’re hiring a code monkey, not an engineer.

Lab preview

You’ll exercise the full Figma → SwiftUI handoff flow in Lab 3.1.

Next: 3.9 — macOS design considerations