I've been working on my hand-offs...
Designers want to hand over something that looks great. Developers want to build something that works great. Somewhere between those two goals, things often get messy.
If you’re short on time
Design hand-offs fall apart when there’s no shared language between design and dev. Here’s what’s helped me fix that:
- Use shared naming conventions
- Label components clearly
- Leave context notes in the file
- Jump on a quick hand-off call
Those few extra steps make everything smoother. You’ll spend less time fixing things later and more time focusing on the good stuff like animations, polish, and making the site feel great :)
Here's what I've noticed...
I’ve lost count of how many times I’ve seen design hand-offs fall apart. Not because people didn’t care, but because everyone was just trying to get things out the door on time.
Designers want to hand over something that looks great. Developers want to build something that works great. Somewhere between those two goals, things often get messy.
I’ve been there more times than I’d like to admit. Tight deadlines, last-minute tweaks, missing hover states, and questions that never quite get asked.
It’s always the same story, and it doesn’t have to be.
Over the years, I’ve slowly built up a process that’s helped me hand off designs with way fewer bumps along the way. It’s not fancy, it’s not full of rules, it’s just the result of trial and error (and a lot of kind devs who were always willing to tell me how I could improve my files!!).
Why I think hand-offs keep tripping teams up
Design is usually the first step in a project, which means it's where the most slack is given on deadlines. Pushing for an extra 3-5 days isn't uncommon during the design phase, but this automatically impacts the amount of days developers have left.
By the time design wraps, everyone’s already thinking about launch. The “handoff” becomes a quick upload and a Slack message saying “it’s ready for dev”.
Then dev starts… and :
- Some variables aren’t clear or named consistently
- There are missing states or transitions
- Small ad-hoc design changes never got communicated
- Components don’t match what’s in the system
And suddenly, the dev team is left to guess.
They want to ask questions, but they don’t want to look like they’re slowing things down. So they just build what they *think* you meant.
And that’s when QA turns into an endless list of fixes... Designers are frustrated the build doesn’t match, and devs are frustrated that the designs “don’t make sense”.
What I realised
The real issue isn’t that designers or devs don’t know what they’re doing, it’s that we rarely stop to agree on *how* we’re working together.
Most designers don’t know what devs actually need to build confidently. And devs often don’t get enough space to ask questions at the right time.
I started noticing this pattern everywhere: agency projects, in-house teams, freelance gigs... It’s always the same tension.
So I stopped trying to make hand-offs “perfect” and instead started making them clear. And that’s where everything started to change!!
What’s worked for me
This isn’t a strict process. It’s a way of working that’s come from a lot of trial, feedback, and late-night fixes :)
Here’s what’s made the biggest difference for me.
1. Start with naming
Variables are amazing, until everyone names things differently!!
Now, before I start any design system work, I check how the dev team handles naming. If they use Tailwind or a design token setup, I mirror it as closely as I can.
That simple step means fewer translation issues later. Everyone’s speaking the same language from day one.
2. Make components easy to read
For me, this was a big one. I used to hand over files that were visually tidy, but totally confusing for devs.
They’d often ask “is this a variation or a new block?” and honestly, I didn’t blame them.
Now, I clearly group and label every component, list its variants, and keep a quick reference section at the top of the file.
It takes a bit more time, but it saves so much back-and-forth later (and the devs always notice!).
3. Add quick context notes
Even the best-organised file can’t explain everything on its own.
So I started leaving small sticky notes throughout my Figma files like:
- “This animates in from left”
- “Not final copy yet”
- “Scroll speed TBD”
They’re simple, but they make a huge difference. It shows where things are flexible or need a chat, and that helps avoid any silent assumptions later!
4. Always have a quick hand-off call
Honestly, this changed everything for me.
A quick 30-minute call with the designer, dev, and PM to walk through the file together. That’s it.
It’s not a full presentation, it’s just a chat to:
- Highlight key components
- Mention anything unusual
- Let the dev ask questions before they start
Every time I’ve done this, the dev team’s confidence goes way up. And we almost never get those “oh, I didn’t realise that’s how it was meant to behave” moments later on :)
Why this matters
This whole thing isn’t about being perfect. It’s about making the process smoother for everyone.
A good hand-off builds trust. Designers feel seen. Developers feel supported. And everyone moves faster.It’s honestly one of those small workflow tweaks that completely changes team energy.
And when you’re working on complex B2B SaaS sites, that kind of clarity can save weeks of stress!
My little hand-off checklist
Before I hand over anything, I always check these:
- Variables match the dev system
- Components grouped, labelled, and tidy
- Notes added for anything unclear
- Assets exported and linked
- Hand-off call booked and recorded if needed
It’s not rocket science!! But it works.
It usually takes under two hours and saves everyone so much time and confusion later!