The design handover is not the handover meeting or the handover file. You’re not done when you put the last pixel/vector on the canvas and hand over the documentation. It’s just getting started. It is important to realise that the quality of your design is dependent on the developer’s implementation.
I remember (way back when!) some awkward moments during job interviews when they asked to see the live version of my meticulously designed screens. Nowadays, you won’t get away with a sad story about how some developer screwed you over. Good designers make nice designs. Great designers ensure those nice designs are nicely implemented and maintained. Great designers are accountable for the handover process.
Good designers make nice designs. Great designers ensure those nice designs are nicely implemented and maintained. Great designers are accountable for the handover process.
Yes, I said that
Designops as a hobby
I might be a bit quirky, but I am always writing and documenting every aspect of my design process and seeking opportunities to improve the design process. Large design teams have started to add DesignOps to their teams to provide on this aspect. It’s not every designer’s hobby to do this, but it is mine. This is not just because, as a freelancer, you can be in and out of a project before you have the opportunity to clean your files up before you leave the building.
Sure, I want to be remembered as a nice person and a great teammate, but I have to confess; I’m teeming with pride when they mention I was the most structured designer they’ve met (and that my files were in great shape when I left). Yes, I even made the ‘exit handover’ an art. You’re quirky or not.
The art of the design handover
- Build relations & trust.
Get to know your teammates and figure out their preferred way of working or even their user manual. If you discover any cheat codes, use those wisely! People sometimes just need to hear you actively seek their feedback and want to learn from their wisdom; tell them you want to be (read Prove me wrong). - Have recurring conversations.
The design handover is not just a single meeting with the developer, showing them where to find the designs and running through the Acceptance Criteria. I can just imagine the blank stares now. Instead, turn it into continuous conversations, discussing the work at hand and what is coming up in the future. - Make yourself available.
Appreciate that developers estimate future work without knowing all the details in advance. When we ask them to take time for our handover, they must zoom away from their current work and consider future work on a higher level. But it is only when they actually start doing the work that questions start to arise. You’re a pro if you make yourself available for such moments, preferably proactively, to cater to more introverted devs. - Don’t use them as a tool.
Treat your teammates as the professionals they are (read Don’t be a tool!) Involve them early, and assume they also want to do their best work. They’re not lazy nor here to fuck up your work. - Happy developer, happy designer, is what I always say.
What to document for the design handover
Writing and documenting are part of my system as a designer. Both activities help me think and stop the process of ‘knee-jerk design’ in Figma. If I can write clearly about the problem, I can design for it. As a bonus, you have the beginning of the documentation and the info to align with your Product Owner, team members and stakeholders. Sometimes, you’re pulled from a project and have to continue at a later stage, so it’s good to preserve all the design decisions and thinking for the future. Much of this information will also be available in the User Story (Jira ticket), but those are fleeting and disappear over time. I’d like to include all relevant information in Figma, don’t make them search.
The state of your Figma file
Before we dive into the content of your Figma file, let’s take a step back and make sure the Figma basics are in order. Do your developers and other stakeholders have access to the file? And do they know how to use Figma as a developer or stakeholder? Ensure you onboard new team members into Figma and explain the application and your way of working. I can’t begin to explain my horror when I found out someone didn’t know how to move the board around; they thought I wasn’t done yet, and I didn’t understand the feedback. Same for navigating through the many pages of your Figma file; don’t make them search! You can also read this guide to developer handover on Figma.com or this piece on Smashingmagazine.com Designing A Better Design Handoff File In Figma.
My thoughts:
- Onboard team members in Figma, teach them the fundamentals.
- Don’t send the link to the Figma file—instead, send a direct link to the Figma page or specific artboard.
- Make sure developers understand and use the Inspect (or DevMode).
- Keep your Figma page clean. Remove sketches and any old stuff irrelevant to the design handover. Move it to an archive, and keep the handover clean.
- Annotations & document.
- Make clear agreements on how to use the commenting feature.
- Provide clear names for pages and the same for vital layers in your designs. You don’t need to rename every layer, just have a smart attitude about it.
- Use your Design System. In large Product Organisations, the developers use the same source as you. When you neglect to define the right colours, fonts, sizes, spacings, etc., your developer will choose the next best thing, and that might not be what you intended. Don’t go rogue; use the system diligently; it’ll improve everyone’s lives.
What to document?
I am working on a Figma template for documenting and annotating, one that I use for all my projects. It might be nice to share with you but bear with me. I need some time to get it ready. In the meantime, some plugins do the same thing, but I’d be hesitant to lean on plugins and their particular way of working; it’s never exactly how I like to work. That said, the nice folks from EightShapes (if you don’t know their Contract Grid, you should stop everything now and go check it out first) have a Figma Specs plugin that might be useful for some.
In any case, make sure you include documentation in your Figma designs to provide your developers with one source with all the answers and include topics like:
- Design thinking, problem definition.
- Design decisions, particularly useful for future reference.
- How to test, define the required interaction states, use cases and explain the edge cases
- All relevant links to
- Confluence documentation,
- Whiteboard sessions or other sketches,
- Jira Tickets,
- Prototypes,
- User Research: is the design validated with user research or based on assumptions? Include links to the research.
- Change log, what has changed from the previous version? We are sometimes stuck in endless optimisation loops, and it’s good to know what is previously done and when (or why).
- Accessibility: Does the design deviate from the general Design System or documentation? Does it require additional guidelines, e.g., tab order, landmarks, or any other area aspects that should be considered? Sometimes, it’s good to point out other topics as alt-text to make sure someone in the team is taking care of them. Not that everyone thinks it’s someone else’s worry.
- File health, are we looking at a well-kept file that’s fully aligned with the Design System or is it a deprecated version or worse a half-assed collection of screenshots?
- Design System, how well is the Design System used vs creating custom components or breaking Design System components apart?
Thanks for reading. You are amazing, you know that, right?!