8 Mar 2019
3 Min Read
Two ways you can immediately improve your Teams Design Handoff Process
8 Mar 2019
3 Min Read
Does your team have the following questions on a recurring basis: “This isn’t the shade of blue I used?”, “Could I get that in .png and .svg resized for android?”, “Why does this font look different? I didn’t use this in the layout I sent you!!!” If your answer was “yes” or “sometimes”, then you definitely have some gaps in your design process which are impacting your handoff.
Constructive collaboration between your design and development teams impacts profitability positively in companies whose billing model is built on selling hours and billing on milestones. For software consulting and design firms, any hour spent on back and forth communication to clarify, rectify or redo of certain parts of a deliverable is a cost to the company. More so when after the client has already given the okay for implementation.
At the iHub Software Consulting(iSC), we believe in an iterative rather than a linear process when it comes to shipping UI layouts, Design Sprint deliverables or End to End Applications. This approach allows us to move as we improve. Reducing avoidable back and forth communication between the designer and developer after the sign off from the client has been received works to our advantage. I cover how to do this later in the article.
I have a project philosophy that goes like: “If it’s meant to be done on a project, it has to be done. Just because X hasn’t done it right, doesn’t mean someone else won’t have to pick up the slack”
Equipping your designer and and developer to flourish in their domain increases your chances of quality work. Here’s a short behaviour analogy of the two:
Developers(Frontend and Mobile): They tend to follow the path of least resistance when it comes to implementing layouts. If you meet this need as a designer, awesome. However, if your layouts were done without them in the process, be prepared for number of disgruntled clicks as they try to bring your imagination to life.
Designers: They are like over protective parents, who would like to see their kids brought up in a specific way. Hence the pixel perfection tendencies. As a developer, if you can bring to life 90% of what they had in mind, they’ll remember you for life :O. If not, they’ll be handing over their work with the feeling that their darlings are heading to the slaughter house.
In reality, hand off begins at the sketching and mockup phase. As the designer, share possible design directions with the developer implementing your work to understand what’s possible and what’s not given the constraints of the project. At the iSC we make it mandatory to have our engineers participate in the design session. This reduces the number of unimplementable designs, saves us hours down the road and contributes to our bottom line.
NB: Pushing the boundaries of design is great but it takes time, money and whole lot of user education within that problem domain. If you have the muscle to guarantee that, then go ahead, if not, get creative around your constraints(that’s what makes useful interfaces and not abstract works of art).
The less a developer has to talk to you after the asset handover has happened the quicker implementation goes. This is bound to happen when they have the freedom of retrieving their assets in the formats they desire and have an easy way of getting measurements and styles they need.
Here’s where tools come to the rescue. Apps such as Zeplin, Sympli, Invision(integrates using Sketch or Invision Studio), Figma and Avocode have collaboration, version tracking, layout inspection, asset imports and code generation. If you’re looking for a cheap way to get started, Figma and Invision(using Sketch or Invision Studio) are free to use while the Zeplin free package allows for one project. All will layout your assets in an easy to browse way and display the code in a dev friendly manner.
We currently use Zeplin at the iHub Software Consulting(iSC) because it works for our designers toolset and makes life easier for the engineers.