I've been on both sides of the design-dev handoff. As a designer, I've watched developers look at my carefully spaced components and build something that felt structurally correct but somehow wrong. As a developer, I've received Figma files where every screen was a slightly different shade of the 'same' color because there were no design tokens — just eyeballed hex values.

After working on enough projects to see this pattern repeat, I stopped treating design and development as sequential phases and started treating them as the same phase.

Start with constraints, not with freedom

The worst Figma files I've worked with start with infinite freedom — every element positioned wherever feels right, every color chosen fresh. The best ones start with a defined system: a spacing scale, a color palette, a type ramp. When you design within a system, the developer implements the system once and everything else follows naturally.

For my own projects, I define the system as CSS variables before I design a single screen. `--bg-color`, `--text-color`, `--accent-color`, `--border-color`. These go in the code first. Then I use the same values in Figma. Design and code share the same source of truth from the start.

Design components the way you'll build them

A button in Figma should map to a button component in React. If your design has seven variations of a card that don't share a single common component, you'll build seven separate card components and maintain seven separate sets of CSS. The discipline of component thinking in Figma pays off directly in the codebase.

If you can't explain how a design element would be built as a component, you haven't finished designing it yet.

The rule: if it can't ship in a sprint, redesign it

Beautiful animations that require a custom physics engine. Layouts that break when the content is three words longer than expected. Interactions that need browser APIs not available on Safari. Every one of these has shipped as a simplified version — not because developers were lazy, but because design that ignores implementation cost is incomplete design.

When I'm designing something I'll also build, I run a mental simulation of the implementation before committing to it. Not 'can this be built' — everything can be built — but 'is what this costs in implementation worth what it adds in experience?'

Motion is a design decision, not an afterthought

I use Framer Motion across all my projects because it forces you to think about animation as part of the component contract. An entrance animation isn't decorative — it communicates to the user that something has appeared, giving the eye a path to follow. An exit animation confirms that something is gone. When you skip these, the interface feels jittery and cheap even if every static frame looks perfect.

• Entrance animations: fade + slight upward drift (12–20px). Durable, readable, fast.
• Exit animations: the reverse, but faster. Users are done looking at what's leaving.
• Layout animations: let the browser handle reflow with Framer's layout prop — don't try to animate width/height manually.
• Hover states: keep them under 150ms. They should feel instant.

The workflow isn't magic. It's just doing the same work twice at the right time — once in the design tool and once in code — with a shared system that makes the second pass fast and predictable.