With this premise, I’d like to share some thoughts on how designers can adopt a few techniques to ease our & our colleagues’ work in the execution phase with the help of a well rounded & thorough design handoff —

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.

A Design Handoff Document is a throwaway artefact. It serves the goal to build something, and that’s it.

1. Mockups
2. Interactions
3. Copy
4. Specs & Assets
5. Checklist

1) Mockups

There isn’t much to mention here. We all have been generating & sharing UI mocks comfortably since many years now. But I do have a couple of points to make :

1. 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.
2. 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.

Suggested Tool(s) : InVision, Marvel

2) Interactions

1. 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 his approach to code.
2. 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.

Suggested Tool(s) : Tour Points on InVision, Interactions on Atomic

3) Copy

1. My advice is to list all the Copy in a 3-column table using any cloud tool of your team’s choice (Paper by Dropbox or Sheet by Google). 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.
2. For reference, I’ve drawn a brief template for our 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 of the 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. But this post is not about whether the designer should write her/him own copy; nor is this another rant about how ‘copy is king’. I’m just saying you should have all the copy documented when you share the designs.

Plus, you’d anyway not want your developer to ‘fill in’ the copy for you in the final hour before the release. (‘cuz you are obviously not around ‘cuz you’ve already left for the day. Oh, designers.)

Suggested Tool(s) : Paper by Dropbox or Sheets by Google

4) Specs & Assets

1. Automate : Today, with products like Zeplin, Avocode & InVision’s Inspect, 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. A tool called Sympli even has plugins for Xcode & Android Studio. It’s just a matter of properly organising layers & groups in your sketch file and let the tools do the rest.
   Whenever you ought to define/refine your visual library — Give Lingo a spin, which helps you create a sharable style guide.
2. Accountability : Automating the handoff process gives designers the authority to question the developer incase of deviation from the prescribed designs.

Suggested Tool(s) : Spec Mode by UX Pin, Avocode

5) 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-jane 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.

Suggested Tool(s) : Paper by Dropbox or Sheets by Google