As a mid-level designer who has been working on projects and been through hand-offs with developers, I kind of found a basic starting point on how I would hand-off my design in the future.

This does not mean that my process is The standard, but the process I have makes me have clear communication with our developers most of the time.

Overview

An efficient design hand-off is a key to properly communicate and transfer the designer’s design decisions in a product to a developer. An approach that provides clarity to both teams to deliver a precise output.

What is a design hand-off?

Design hand-off is a detailed document that contains a description and specifications of the products design components and composition. It is a process of turning-over the final design to the developer for conversion.

Design hand-off should include the flow, behavior expected in the design, breakpoints, validations, states, and preferably a prototype included for demonstration.

Aside from the specifications, we want to also show annotations to know the rationale behind design decisions that made the designer come up with such design. This gives clarity and understanding at the developers end.

Design hand-off is meant to provide an ease of identification of the properties the developer needs to follow in order to convert the design properly.

Hand-off contents

Elements specification

Elements specification includes the sizes, spaces, colors, and typography of the elements inside the design. The designer should provide guidelines on the specific measurements of the elements.

In Figma, developers can inspect the color and typography specification through the inspect functionality of Figma. This is one less of a work on the side of the designer.

Another part of the specification is indicating the accessibility points in a product. Accessibility points include touch points and alternative actions and captions. Providing accessibility information will allow developers to know how an element will be used in a certain out-of-normal situation. Visualize touch points by providing red-lines around the area of the elements that needs to be specified. Red lining can be manually created or you can use a plugin to help you fasten the process; in HOV design, we use the plugin Redlines.

Behavior

Behavior includes animations and interactions. It can be visualized by creating a prototype and make an area where developers can observe and play on how the designers intended a page or an element to behave. Some of the times, some of the behaviors follow a certain pattern already and can be relay by just adding annotation noted for developer to know what the designer want or expecting to happen.

Screen states

Providing a screen states make it clear for the developers what are the possible visuals of pages in a certain situations, such as empty, fresh install, loading screen, or error screen. It allows to provide back-up visual on unusual page situations; this will also avoid the looping back of the developer to the designer just to ask for a screen states.

Flow

Providing flow pages in your file will allow developers to understand the sequence and the scenario happening in your design. Flow should show the entry point or action and the result. If necessary, you can provide annotations beside your flow if it requires a specific instruction on the designers end. In our design department at HOV, we use the plugin Autoflow to fasten our process.

Breakpoints

Providing breakpoints for the screens, especially if there are still no system or guidelines both the design and developer departments are following is essential. It allows the developer to apply accurate responsive screen size on specific devices.

Common breakpoints we have that are generally recognized are;

• Mobile breakpoints (Small devices) min-0dp, max-600dp.
• Tablet breakpoints (Medium devices) min-600dp, max-900dp[Portrait] and min-900dp, max-1200dp [Landscape].
• Desktop breakpoints (Large device) min-1200dp, max-1800dp.

Some will say to start on Mobile first approach, but some designers argue that you should design on what is the priority of your product. Your layout of your design may vary depending on the size of the device you are designing to. Additionally, as the device gets smaller, the elements get hidden as we are prioritizing essential information as the visual space gets limited.‍

Assets

Assets include icons, images, illustrations, media that will be included into the design. Providing it on your design hand-off will reduce the looping time the developer will have on asking for the assets of the project. Advisable to have a specific cloud storage in which the designer can store the assets and the developer can just download it straight from the cloud.

Quick sync-up with your developer

Lastly, you would want to jump on a quick call with the developers. Discuss the flow and the reminders you would want to clarify to them. Having a meeting. With them will basically serve as a final stage of hand-off and the conversion is now at their hand. Guide them through the pages you have on your file and some signals that you provide.

Providing a clear hand-off process to your design will also serve as a communication and agreement between you and the developer. Miscommunication on handing-off can lead to conversion errors and back and forth clarification between the designer and the developer. You can also try approaches that you deem may fit into your culture. No approach fits all; the key point we want to cross over in here is to relay the design message correctly to developers for a better conversion.

I hope you got some substantial information from this read. See you again next time as we tackle more things and experiences about life and design.

‍