Engineering-ready handoff: tokens, Loom, and what to skip.

We've watched engineers actually use design handoffs. The painful truth: most of what agencies deliver is fluff. Engineers open the Figma file, find the components, and skip everything else.

Here's the handoff pack we actually deliver — and what we deliberately leave out.

What engineers actually use

1. The Figma file, organized for skimming

Engineers open Figma and search for the component they need. They don't read top-to-bottom. So the file structure matters more than its prettiness:

• Pages named by feature, not by sprint week
• Components in a single library page, not scattered
• States on the same artboard (default, hover, error, loading, empty)
• Anchors / sections labeled with the same names engineers use in code

An engineer should find any element in under 10 seconds. If they can't, the file is failing.

2. Design tokens, named semantically

Not color-yellow-500. Use brand-accent. Not spacing-16. Use card-padding. Tokens are an API — engineers should be able to use them without thinking about the underlying values.

We deliver tokens in two formats:

• A Tailwind config snippet (tailwind.config.js) ready to paste in
• CSS custom properties (:root { --color-brand: #FFD60A; }) for non-Tailwind stacks

3. One Loom per major flow

5-minute videos, no annotations, just narration. "Here's the empty state, here's loading, here's success, here's the edge case when the user has no permission." Engineers watch them once on 2× speed and refer back when stuck.

Looms beat written specs for one reason: intent. Specs describe what. Looms describe why.

4. A 1-page handoff doc

Notion page. Bullet list. Sections:

• What ships this sprint (linked to Figma frames)
• Tokens summary (copy-paste blocks)
• Known edge cases we didn't design (be honest)
• Loom links
• Slack channel for questions

That's it. One page. No PDF, no 30-tab spec doc.

---

What to skip

Things we used to deliver and don't anymore, because nobody opens them:

Pixel-perfect annotated specs

Engineers read Figma directly — they don't need a separate PDF with arrows pointing to padding values. Use Figma's built-in inspect panel and call it done.

Style guides as standalone PDFs

If your style guide isn't usable code, it's documentation theater. Skip it.

Multi-page interaction specs

"When the user hovers, the button transitions over 200ms with ease-out…" — this lives in the Figma prototype or the Tailwind class. Writing it out is busywork.

Accessibility audits as separate deliverables

Bake A11y into the design directly. Color contrast, focus states, semantic HTML expectations should be in the component itself, not in a parallel doc. If a button needs aria-label, note it on the Figma frame.

If a deliverable requires its own meeting to explain, it's the wrong deliverable.

The principle

Optimize for the person at the receiving end. Engineers are smart, busy, and they know HTML. Give them organized files, semantic tokens, and short videos. Skip everything else.

That's the entire handoff philosophy.