Good handoff improves UX quality

Two American football players on the field passing the ball to each other
Photo by Chris Chow on Unsplash

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.

A screenshot of the software Jiram showing an example of Scrum board inside the tool
Example of a Jira’s Scrum board (taken from the internet)

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.

A screenshot of the Notion software showing a kanban board of a client of mine
Capture of a client’s sprint backlog in Notion

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:

A screenshot of the left sidebar inside Figma software, showing the page structure I created for a client’s project
Page structure in Figma for a client’s project

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.

A screenshot of the Figma software, showing six different artboards with cover examples displaying different project status: in progress, completed and archived
Cover pictures on Figma to display different project status (Mozza)

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 :)

A screenshot of a Figma artboard with the design specifications of design components
Design specifications to developers: I wrote comments on sticky notes to explain the desired interactions (in yellow) and added links (in green) to animation previews
A screenshot of Figma software showing comments I created on top of the design artboards explaining especifications to developers
Comments I wrote on Figma prototype to guide my client’s development team

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.

A screenshot of a user flow for a mobile application
Representation of a user flow for the notifications center of a mobile application
A screenshot of Figma software showing a navigation structure and layout structure I created for a project at Doctolib
Navigation and page structure on Desktop and Mobile for a redesign project

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.

A screenshot of Figma software showing the final solution of a task manager module I designed for Doctolib Practice, the B2B solution from Doctolib
Snapshot of the live prototype of the task manager module I designed for Doctolib Practice (B2B product of Doctolib). Click here to open the live prototype.

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.

A screenshot of a ticket description I did inside Jira software, containing user stories, pain points description, links to user research prototypes and takeaways and a link to the final prototype
Ticket description I created on Jira gathering several information: user feedback, user stories, user testing resources, main pain points found and link to final mockups

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!

Categorized as UX Tagged ,

Leave a comment

Your email address will not be published.