{"id":12284,"date":"2017-09-20T11:45:58","date_gmt":"2017-09-20T10:45:58","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=12284"},"modified":"2021-01-17T23:26:29","modified_gmt":"2021-01-17T23:26:29","slug":"guide-successful-design-handoffs","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/guide-successful-design-handoffs\/","title":{"rendered":"A Guide to Successful Design\u00a0Handoff Document"},"content":{"rendered":"

A good product is a lot about the problem that you pick & the ideas that you implement. But a well-sorted & deliberate Design handoff document<\/strong> and a process can play more than a handy role; ironing out quite a few wrinkles that can cause unnecessary escalations and ad-hoc duct-taping later during the execution phase.<\/p>\n

"As designers, we are the guardians of execution and thus equally responsible for the air bubbles that might exist in the finished product. Thus before every release, it\u2019s imperative for the designer to sign off the build. But it\u2019s not always that Design Quality Check<\/strong> is given it\u2019s due place in the process, and most product releases burdened by tight timelines end up bypassing this or at the most subset it under exercises like Dogfooding. The problem with bypassing Design Quality Check is that it looks like an easier trade-off to make instead of squeezing in those precious few hours before the release \u2014 More than the immediate quality loss what\u2019s even more harmful is the legacy it carries onto the upcoming releases & sometimes it almost lingers throughout the lifecycle of the product, either as a function of team\u2019s mindset or the actual workflow."<\/span><\/p>\n

Having underscored the importance of a design quality check, there\u2019s a responsibility that designers have too<\/strong>, which could lighten the burden of quality check & bug bashing later on, which is \u2014 how were the designs shared? <\/strong><\/p>\n

For the most part, it really does depend on how comprehensively were the designs published by the designer to the stakeholders. Designers, more often than not, want to see themselves as Thinkers but not so much as Executionists.<\/strong> It helps to learn a thing or two looking at the way Developers operate. The Version Control rigour, Namespacing of the files\/modules, Documenting iterations or Commit messages or Patch notes etc. It would only help us designers get more productive & useful at our job.<\/p>\n

<\/div>
<\/svg><\/div>

\"Designers, more often than not, want to see themselves as Thinkers but not so much as Executionists.\"<\/p><\/span><\/blockquote>\n

"With this premise, I\u2019d like to share some thoughts on how designers can adopt a few techniques to ease our & our colleagues\u2019 work in the execution phase with the help of a well rounded & thorough design handoff<\/strong>." <\/span><\/p>\n

When a design is handed over to the developer, there\u2019s multiple layers of information that needs to be conveyed<\/strong>. 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<\/strong>.<\/p>\n

\"\"<\/a><\/p>\n

<\/p>\n

A Design Handoff Document<\/strong> is a throwaway artefact. It serves the goal to build something, and that\u2019s it.<\/p>\n

\n