A guide to a streamlined design handoff between designers <> developers
Handing off deliverables and design specifications to developers is always an ongoing debate inside the product design community and product teams I’ve worked with. I believe there are no right or wrong answers because, in a given context, different teams should choose the methodologies and tools that work best for them.
But why is design handoff important? Because that’s one critical point in the delivery process where teams usually compromise the UX quality of the designed solution. To set an example, the design team at HackerOne spotted that their handoff process was responsible for the drop in their UX quality in 23% of times. Imagine how high this figure may be in other companies, where design teams don’t even have the culture of running and measuring handoff process to the development team.
Design handoff is one critical point in the delivery process where teams usually compromise the UX quality of the designed solution.
And what is design handoff exactly? It is the process of handing over a finished design for implementation. It is a key moment in project management where knowledge is transferred and, thus, transformed. A well documented design handoff is essential, one whose specifications and documentation meet user needs, speaks their language and make their lives (jobs) easier.
If there’s no clear process in place, one that is respected and constantly improved by the team, it is very likely that information will be lost, guidelines won’t be followed, and design solutions won’t be respected.
Thus I will share in this article how I prepare and run design handoffs on my own projects, based on my past experiences in small and large product teams, and on my current processes as a freelance product designer.
In all companies I’ve worked for, I encountered Jira as the main project management tool (I even wrote an article on Medium explaining how I decided to integrate design tasks inside development sprints to improve design and product collaboration). Jira is a powerful management tool for agile software development and very useful for creating scrum and kanban boards in order to run and understand the project management processes properly.
Nonetheless, since I started freelancing, I see more and more early-stage start-ups relying on Notion to create and run their project management process.
Whatever works for your team, you should get familiar with the product management tool they use. This way, you can propose and manage the design handoff process to developers the best way. No need to jump from tool to tool: gain time and improve the transfer of knowledge by having one single source of truth.
Figma is a collaborative prototyping tool and it allows us to create several supporting materials to the design process and final results. It becomes therefore very convenient to communicate details of your final design solution directly in the tool:
2.1 Set up a page structure
It’s very important to structure the design file since day 1. My philosophy is to let people know where to find what they are looking for.
In terms of design explorations and evolution, I usually split my design progress into different pages, separating the current designs from previous versions that are no longer relevant. Here’s an example:
Pro tip: If you have the Organisation and Enterprise plan on Figma, you can use their branching feature: you can create “branches” in your file, similar to branching strategy to software development. This is particularly useful if your master file is too heavy, to clean up the master file by pushing older iterations into a dedicated branch.
Besides findability, a nice structured Figma file also let people in the team understand the project steps and grasp the design decisions leading to the final solution.
2.2 Communicate project status
Each team uses different naming conventions to represent their project evolution. I usually use names that are based on phases of the project workflow, such as: discovery, ideation, prototyping, testing, in development, in review, live.
Some designers also show a more simpler classification: ongoing, in review and shipped.
At Mozza — a collective of freelance product strategists and designers I work with — we use custom banners on the Figma file cover to reveal the current state of the project. In my previous role at Doctolib, we would also add the name of the designer responsible for the prototypes (and the date of the last update), since we were working with a team of 20+ product designers.
The name convention should be easily understood by the team collaborating with the project. Pick whatever works for you and your mates. This is ultimately a communication system to give visibility on the current state of the project so everyone is aligned.
2.3 Describe with words
I like to leave comments or create sticky notes to communicate the design decisions textually: raise a question, a concern, or to explain an interaction. It is very useful as a communication tool with the developers :)
2.4 Describe with visuals
An image isworth a 1000 words. This couldn’t be more true when documenting design decisions.
For instance, I find helpful to represent navigation flows and to explain all the possible paths and navigation levels in the prototype visually.
Also, the live prototype (called “preview mode” on Figma) is always better than any written or visual explanation you might offer. It shows a specific user flow from end-to-end, presenting context and an interactive version of the final solution (including transition between screens, micro animations and other interactions). This is the type of information that it’s very hard to explain by written form, therefore this solution becomes handy to communicate the design decisions.
So, whenever possible, I provide a clickable prototype of my desired solution to developers. It’s not only a good opportunity to discuss technical constraints and run design reviews with the tech team, but it’s a powerful way to communicate my design solutions to stakeholders.
Finally, development ticket. That’s where the magic happens! Inside the ticket description to developers, I always try to add the following design information:
- Project documentation (scope, ideation, discovery, etc)
- User stories
- Link to prototype
- Link to preview mode, if applicable
- Specifications on how to implement the final design solution: design system documentation, technical details, interactions, animations and intended behaviours
If my design needs extra documentation to explain edge cases scenarios, for instance, it’s ok to create it in a different source (Google Docs, for instance) and attach it to the development ticket. Sharing compelling and useful/usable deliverables is important, such as test reports, field study findings or client feedback.
Make sure your document is not too dense and extensive because this will reduce the chances that anyone, including the developer, will read in its entirety. Make your ticket description easy to read & scan, but powerful and detailed!