Design handoff best practices

In a world where information has to be clear for those who receive it and objective for those who transmit it, passing on the correct information without noise can be challenging, and within products and services development, this is no different. However, it is always possible to improve communication for the success of the project. In this context, we will focus on best practices to handoff design work to the development team.

Picture2-2Image by Suzanne Tucker/ Shutterstock

Design handoff is the delivery or transfer of work done by designers to the development team.

The development team relies on the handoff file to start building the final product, in code. When the handoff is done correctly, we reduce time and effort from both the developer and the designer and at the same time increase the quality of the final product and the satisfaction of the user.

The handoff documents bridge the gap between design and development and while it may sound like an overwhelming process, it doesn't have to be. To create a seamless design handoff for a developer, we share some important tips that UX designers should follow.

When design handoff may happen

During the project

The delivery of the design handoff can be done in small batches during the project, such as at the end of each sprint. It contains only what is essential for the accomplishment of a certain task. It is important to communicate with the team regularly to make sure that they are aware of the project’s progress. To make this delivery easier, producing, iterating, and delivering little by little can bring better results.

Instead of letting everyone do their own thing, put everyone together every time there is something important to be delivered. Communication issues can be easily avoided by having a dedicated channel with all relevant parties involved.

Use a common place to share asset files (fonts, images, videos, reference documents) like Google Drive, One Drive or Dropbox. If in doubt, don’t hesitate to make a call.

At the end of the project

When a project includes all design work prior to development, the handoff must be done at the end of the project, in a documentation repository that contains all files, flows, assets, interfaces and everything necessary for the implementation of the final product.

Best practices for documentation and communication

Communication between Designers and Development team 

  • The developer is your user too, the one who will use your handoff to implement the product. Therefore, be empathetic and understand the developer's needs and way of working.
  • Work as a team, show the value of design to developers, include them in the interviews, listen to their opinions. If developers participate in building the solution, the design will be clearer to them.
  • If the direct participation of the development team is not possible, then explain the reason for the proposed solution. You can use, for example, user stories.
  • Check the technical feasibility of your design and present your ideas to the development team periodically. This will facilitate product development and prevent work and time from being wasted on solutions that are not viable.
  • Always be close to the developer: good communication will result in fewer implementation errors in the future. Be available for Q&A.
  • Set up a meeting to present the handoff file to the development team or record a video instead. This will make the team more familiar with the file.
  • Learn if there is anything that can facilitate the work or the understanding of the developer. If something is not clear, talk to the developer to understand what the problem is.

Handoff file – Mockups and Specifications

  • Show developers how to use the tools where handoffs will be delivered. If needed book a demo session with them. Creating a HOW TO file for onboarding new team members is also a good resource. It is important that they know how to use the tool to find relevant information when developing the code. In most design tools, they can see color codes, font used – type, size, and weight, spacing between elements, element sizes, and so forth. If setting up a meeting with the team is difficult, you can always record the session so everyone can see it later.
  • Name files and artboards semantically: You should keep in mind that naming files and artboards in a simple, clear, and semantic way will help the development team to understand what this frame or the flow is about. For instance, it would be easier to understand one frame that is named "Home" (it is probably the product's home page) than "Screen01". It's never a waste of time to be very clear when naming objects, this can avoid misunderstandings in the future.

                                                            Image by Pets Care App Shot / Goutham HM
  • Keep the file clean and updated: only deliver what is needed, delete old screens and variations that are not in use. You can keep the old screens in another file to achieve it, but when delivering for the development team, be sure to only send the product's final version. Only sharing the final artboards/frames that are important for the developers will avoid misunderstandings and keep your file relevant.
  • Create organization in your design file: Separate what is ready for development from what is still in progress. Use icons for identify the state of the work (done, in review, work in progress, ...0 and separator pages to create sections. Such an organization will help developers identify what is ready to be consumed when the handoff is done incrementally. This can avoid implementing one screen that is still under design process and not ready for development yet, wasting the team's efforts.
  • Design the corner cases and different scenarios such as empty states, not found, not allowed, etc., when necessary. Do not just consider the happy path.
                                                                            Image by Leni Kauffman
  • Create flows to demonstrate your product navigation. In addition, whenever possible, having a clickable prototype can be a great way to show what is expected after coding.

    Image by Phil Goodwin / Dribbble

  • Describe any special behavior that elements may have. Be verbose, add as many instructions as possible to describe what is expected to be implemented.Picture8-Aug-23-2022-04-09-22-99-PM

    iOS Reminders App

  • Use animations and behavior references when you are not able to prototype your product. Add the link to the reference.

    Skeleton loader and the reference

  • List texts you use in the interface, such as status messages, empty states, helper text, tooltips, among others in a separate place. This will make it easier for developers to locate all the text needed.
  • Organize layers in your design tool file, use semantic names that specify the object's function. This will make it easier for developers to understand the file structure.
  • Be consistent (use the same components for the same functions, same behaviors, same spacing, etc.). Make sure you are using a component library or the product design system.
  • Make use of plugins for component specs, style guides and asset export. Current design tools have plugins that can help a lot with documentation.
  • Describe any specification in the file itself when necessary. Do not forget to document for accessibility: tab navigation, feedback behavior, rem units for rendering, etc.
  • Keep the Design System organized and up to date. A well-structured and documented design system will guarantee consistency in the design work as well as in the implementation. Dedicate time to maintain it.

Design review of implementation

Design Review is the review of the implemented design in code to identify possible errors, opportunities, and necessary changes.

During the design review we can find inconsistencies between what was proposed and what is developed, unexpected behaviors and flows, usability, and accessibility problems, among others.

Reviewing what has been implemented is important to maintain consistency during the project and to avoid misunderstandings between what has been proposed and developed.

Set up some checkpoint meetings with the developers in every sprint to run a design review. Doing it before the code is delivered to production will reduce the cost of fixing things.


Documenting design decisions and passing them appropriately ensures that the work done by the designer is understood correctly by developers and other stakeholders and it’s consistent and understandable.

Organization, the right depth of detail and good communication ensure that the project has a clear, accessible logic, where errors and reworks are mitigated, thus bringing greater productivity to the progress of the project.



This article was written by Diego Matheus Santos Silva, UX Designer at Encora. Thanks to Flavia Negrão, Michelly Marsoleta, João Caleffi and Kathleen McCabe for reviews and insights.

About Encora

Fast-growing tech companies partner with Encora to outsource product development and drive growth. Contact us to learn more about our software engineering capabilities.

Contact us

Share this post

Table of Contents