Getting the build to match your designs, and what developers really want from a handoff.
Try as we might, it’s difficult for a designer to know exactly what a developer wants from a handoff. I’m sure you’ve received multiple messages after handing something off about where to find assets or hex codes. Or worse, you did a QA check after your design’s been built only to look in horror how wrong it is. Well, here are all the things as a designer I ensure are addressed so that my designs are built as precisely as possible—with minimal back and forth.
All of these are based on working in a multi-disciplinary product team or squad, using kanban or scrum, and Figma as your primary design tool. If not, try these out anyway and let me know in the comments how it went.
A clickable prototype is fantastic and communicates the nuances in the interactions fantastically. Not all features and work need that level of depth though. Sometimes static designs are a more appropriate use of time. When that’s the case, it’s really important to annotate your work. Describe the interactions that happen, accessibility considerations, and anticipate questions you might receive.
I annotate my designs with a custom “sticky note” component, as Figma comments are easy to forget or ignore. A drop shadow and overhanging my frames help enforce this isn’t part of the design.
Takeaway: make your thinking tangible, visible, and obvious to the viewer.
Many tools build upon handoff such as Zeplin, Avocode, and even Figma has an “inspect” tab intended to aid developers in an automated way. The thing is—it’s like Chinese whispers. Consider this chain of events:
- We create a design file
- An automated tool creates some handoff documentation
- A developer interprets this as best they can
- It gets built with feedback from other developers during code review
- You come in at the very end to see if everything went according to plan
No wonder as designers we’re constantly unhappy how the final result doesn’t match the original designs. As designers we have a responsibility to communicate our vision and inspire our devs, not to simply pass the buck. It doesn’t have to be complicated, either. A short call is often enough to support the handoff process. Not only is communication mostly body language and tone, but in a call you’re really inviting the other person to collaborate with you.
As a bonus, they’ll be bought in. As a developer, I know I work harder to execute someone’s design if we spoke about it and shaped it together.
Takeaway: walk me through your designs—tell me a story, and invite me to help shape it.
When you avoid sharing early drafts, you’re essentially stating that you know best. In design that may be true, but not when it comes to executing your designs and getting it into the hands of users. As a dev I will take the opportunity to point out alternatives that save lots of effort, or problems that you haven’t foreseen. It’s really important to “battle test” your work from a variety of different perspectives, to get to the best result possible.
It doesn’t have to be a big, high effort activity either. Keep sharing little and often for best results. Some examples:
- If you have a standup, share your work afterwards for 2 minutes
- If you have a Slack, Teams, or Discord, you can send videos and screenshots
- Working with Figma you can always share your designs anytime
Whether you prefer synchronous or asynchronous communication, there’s really no excuses. Waiting for a “big reveal” is inviting trouble.
Takeaway: invite feedback from everyone throughout your design process, little and often. You’ll be surprised how resistance at handoff time simply disappears.
When’s the last time you heard “don’t worry, it’s an edge case”?
For me it’s instinctual to anticipate failure and solve for it. The bulk of my programming experience is based on the Reactive Manifesto, after all. As a designer you have a duty to help guide your users in case something goes wrong. In fact, see Jakob Nielsen’s UX heuristic #9: recognise, diagnose, and recover from errors.
Some common cases you should consider in your work:
- What happens if validation on a field fails?
- What happens if it passes?
- What happens if fields are left empty?
- What if I accidentally click a button or delete something?
- What happens if it takes a while to load?
- What if loading the next part of the flow fails due to loss of internet?
- What if I interact with this flow or page out of the intended order?
- What if I come back to this in 1 hour, or 1 day?
I appreciate a lot of these questions are form related, and will be easier to answer if you have a conversation with someone technical. After some practice, you’ll build up the muscle memory needed to anticipate failure and solve for it.
No more interjections from others claiming your designs are “incomplete”.
Takeaway: handling errors isn’t just for programming’s sake. It’s crucial for a complete user experience.
Whilst designers will have a working understanding of how to compose a layout by eye, learning the mathematics behind it will be a tremendous help. Containers, breakpoints, and the 12-column grid layout all work together to create a responsive layout for web content. Understanding how it all works not only helps you better design for the web, but teaches you to speak the same language as engineers. Much like an MBA teaches you to speak the language of a business.
If you’re a hardcore designer through and through, you’ll be pleased to hear there’s a rich design history behind grids. Kudos to those that have taken the initiative to learn these. For those that haven’t, you’ll be wondering why you didn’t learn these sooner.
Some helpful resources:
Takeaway: learn how layouts are calculated in reality. Your designs will be more accurate, and engineers will have newfound respect for you.
Handoff is just one part of “how the the sausage is made”. You might be asking yourself “how am I so sure these work?”. As an example, I led the redesign of a website that had more than 200 web pages, involving a design team of 5. We redesigned it in one swoop, before sharing it with the engineering team.
Guess how many issues were raised at handoff?
3.
As designers, we can either pretend developers aren’t able to execute our designs, or we can tailor our handoff efforts for the best chances of success. There are a number of things we shouldn’t do—letting them guess, passing the buck, or doing a big reveal—but there are equally a couple of things we can start doing more of. Designing for failure is simply a good idea, and when you find that language intersects between development and design, discussing layouts?
It’s just, magical.
