When a design is handed over to the developer, there’s multiple layers of information that needs to be conveyed. In addition to the Mockups and Specs+Assets, one must also share the Interactions, Copy, and a Checklist. All these cover different aspects of the design solution and need to be collated in one, simple, accessible document that sits on the cloud. You can call it the Design Handoff Document.
Mockups
Naming your files : Let the file/screen name not possess any form of versioning. The name of the screen should simply describe it’s function. If you’re not yet using a version control solution for your designs, you probably should.
Plus, make sure you use consistent casing when naming your screens, whether it’s ‘camelCasing’ or ‘Sentence casing’ or ‘lower casing’ etc.Have the necessary, archive the rest : At the time of handoff, you’d have collectively zero’ed on an option you’re going to build. So weed out all the older iterations & explorations. It also helps you write simpler filenames.
Interactions
Make a flow : Putting the mockups together is only half the work done. You’d need to stitch the screens together based on the flow using Hotspots (or just make an Interactive Prototype). It helps the product manager understand how the user journey is panning out; and helps the developer plan her/his approach to code.
Figure out the fidelity : Not every screen has to be fleshed out with high fidelity prototypes. Few screens could simply be static with explanatory comments, few could get away with platform-specific standard interaction patterns and few might require those custom prototypes. There’s no blanket rule for all the screens, so discuss with your developer & plan accordingly. Do not end up spend a ton of time prototyping a simple interaction pattern that already exists.
Whether you choose to communicate the interactions through an Interactive prototype or Comments marked up on each static screen — it’s upto you. But the idea is to have the interactions documented. There’s a tendency to leave this bit till the last minute when you hear designers say, “I will sit with the developer & hash it out”; but it’s not efficient.
Copy
List all the Copy in a 3-column table using any cloud tool of your team’s choice. There’s always a lot of Copy that cannot be shoe-horned in the UI mocks, so we’d need to record them somewhere else.
For reference, see example below of a brief template for Copy table —
• First, specify the type of copy. This helps developers quickly parse through the list. The rows could be grouped by the name of the screens (Homepage, Cart, Checkout etc.)
• Second, specify the situation & context of the copy. (Eg. Whether the user is logged in or if it’s a repeat user. Or, if there’s an ephemeral event which’d influence a particular UX). Mentioning the context or the heuristic helps the developer understand when should the message appear/disappear.
• Lastly, the actual message.
More often than not, most product & design folks don’t spare enough brain cycles on Copywriting. Different team compositions would dictate if you’d need a specialist copywriter or not. You should have all the copy documented when you share designs.
Specs & Assets
Automate: Today, with the abundance of handoff tools available, a designer should not be allowed to waste any time redlining the designs with specs, measurements, and style guides. Let’s make use of these nifty tools and save our team’s time. It’s just a matter of properly organizing layers & groups in your design file and let the tools do the rest.
Accountability: Automating the handoff process gives designers the authority to question the developer incase of deviation from the prescribed designs.
For example, raise a Jira ticket against the responsible developer the moment you spot a discrepancy in the build. This way there’s organized accountability within a timeframe and no email escalations against the designer.
And ...
When sharing your Specs, don’t forget to communicate to the developer the Grid System you’re using in your designs. I use 8-point grid system considering almost all the screen-sizes in the market are divisible by 8. Here’s how you can start using it in your designs.
If your designs involve a lot of state-changes for buttons or labels, then be sure to document passive/active states of your buttons, up/down states, dynamic text, animation from variables, etc.
Design Handoff Checklist
The most gut-wrenching part of any design execution exercise is the ‘missing designs’. There’s always an edge case or two missing from the designs shared, and this always gets escalated mostly during the last mile of design execution, with a sense of panic because of the looming deadlines. This leaves the designer reacting to the situation instead of responding with reasonable thought.
A practical solution to avoid all the last moment chaos, is —
Maintain a plain checklist of all the cases & features that need to be designed; created & managed by the designer on the project.
The checklist will flag the status of the feature being picked up or not, and whether it’s completed or under works. All the completed rows should have the link to the corresponding design.
If a certain feature is moved to the next version because of a certain dependency, then the corresponding team is marked along with a describing comment.
Anything that does not exist on the checklist, is not accountable for implementation, and this understanding is established between product, design & engineering at the start of design solutioning. This way the checklist acts as a reference & single source of truth incase of a deadlock or confusion around whether or not the feature was agreed upon to build.
Add Comment