Design Handoff is Broken
#42: How to establish a wholesome relationship with software engineers
Welcome to Fundament, a weekly product design newsletter where we share actionable tips and insightful stories with the worldwide design community.
Design Handoff is Broken
As designers, we don’t sit chained to our desks in front of Figma for 8 hours a day but rather spend a healthy amount of time collaborating with other team members such as product managers, UX researchers, business stakeholders, and software engineers.
What’s the first term that pops up in your head when someone says collaboration in the context of design & engineering?
I’m sure it’s a handoff.
Handoff in the dictionary has several definitions:
American Football: A handoff refers to a backward pass, typically from a quarterback to a running back.
Aviation: It involves the transfer of radar identification of an aircraft from one controller to another when the aircraft enters a new airspace.
Business: The passing of a completed project to another person or group.
All definitions and contexts have one thing in common: the transfer. Handoff is the process of transferring something from one party to another. No looking back. Done deal.
Design handoff in a product environment for in-house teams doesn’t foster collaboration. Instead, it creates more walls between design and engineering. Design handoff is like a little door in the wall designers occasionally open for a one-way conversation. Designers send engineers finished assets and close the doors for months.
Can this be fixed?
Luckily, the cure is quite simple: the figurative hole in the wall must be a little bigger and open continuously. This will enable true collaboration between designers and engineers.
In today’s episode, I’m going to explain how I collaborate with engineering, structure my files, and keep the documentation up to date.
Handoff as a continuous process
The way I structure work between design and engineering follows one simple rule - no side can disappear in their cave for weeks. There should be an open channel of communication between designers and engineers. It could be a dedicated Slack channel or Figma comments for asynchronous messaging and regular (e.g., weekly or bi-weekly) design syncs for more synchronous discussion.
What’s best? For me, it’s a combo of all three, but I’m sure some designers and engineers will feel more or less comfortable talking about design on weekly calls. Instead, they would bet all on asynchronous communication. It should do the trick as long as it’s regular and relevant.
Weekly design sync
We sit down for half an hour every week and discuss what is in the making. Although I work in the product trio model, the entire engineering team and my product manager are invited to these meetings. I usually pick the latest and most relevant things I worked on in the past few days or weeks for the presentation. Engineers provide feedback on the feasibility of my ideas. If needed, we modify them together to enhance the chances of hitting production quickly without hurting the usability side of things.
Having this type of communication brings benefits on many levels. First of all, for a designer, the aforementioned check on feasibility. When you expose yourself to feedback early and regularly, your designs are not just Figma screens but are closer and closer to being ready for use by real users.
Engineers feel more involved in the entire process when their feedback is welcomed and valued. They genuinely feel that they have some control over what they are building. In general, it positively influences the well-being of the engineering team. Most software engineers I met in my 11-year career were ambitious and thrived on building cool stuff. They are not mercenaries.
Slack channel and Figma comments
Feel free to replace Slack with your favorite messaging tool, but the goal should be the same: to have open, asynchronous communication between design and engineering. Whenever one party has a quick question or a burning issue, they can post it there and get a reply within a reasonable time you both agree on.
Figma's comments are even better in this matter since they are inline. You can immediately grasp the context of the question as you see it attached to a specific part of the design. The only downside is that you need to have some designs first. That’s why they work best in combination with Slack, which you can use to discuss designs very early or things that aren’t related to the UI, such as data, models, requirements, and diagrams.
Kick-off meetings
Some might think of kick-off meetings as the traditional handoff process, which I’m stating is broken. This is true, so I’d rather think of them as revisit meetings. Because the engineering team is involved in the design process through regular design syncs and asynchronous discussions, these meetings are supposed to revisit the final state of the design a minute before the implementation. I only do them for big and complex features when discussing the final thing again makes sense, even though the implementation will be sliced into many tickets.
Figma files and documentation
Communication is at least 50% of success. The other half is the quality of the assets and documentation designers share with engineers. Some teams invest lots of energy in making their Figma files and inline documentation super delightful, but not every team has the capacity to do it. However, I believe there are a few rules that are easy and not that time-consuming to follow that will enhance the wholesome relationship between design and engineering.
Here are a few tips on how to make the figurative hole in the wall larger:
Split frames into logical chunks. Other designers and non-designers, such as PMs and engineers, will visit your files and leave comments, so make it easy for them to understand what’s happening in the file. You can split features or user flows into separate pages or files if they are large enough.
Mark what’s in progress, an experiment, or ready for development. I like to keep my work in progress and experiments on dedicated pages. Work in progress would be features and user flows that have been more or less defined and are going to be implemented in the near future. I mark something with a proper label if it’s ready for development so the engineers are not confused. Experiments, on the other hand, are somewhat ambiguous things that require further discovery with the users, customers, and stakeholders.
Use components, styles, and tokes if needed. This may sound super obvious, but it’s important to keep your design system as a separate file and the local components locally. I define styles for text, colors, and effects. I also follow the naming convention of my engineers so they can easily extract code from Figma.
Spend 10-20% of the Figma time documenting design decisions. Design documentation doesn’t have to be particularly long and written in intricate language. Sometimes, a one or two-sentence note next to or below a frame describing what’s on the frame (and why) will do the trick. If needed, I like to connect my frames with arrows to show how the user flow goes explicitly.
Once you implement those tips and enhance the communication with engineers, your handoff will become a continuous process. That’s the only alternative to the traditional handoff that truly fosters collaboration between design and engineering teams, which is crucial for the success of the entire product team and the product itself.
Visual Feast
This is a new segment of Fundament where we showcase pure visual craft. Each week, we feature a talented designer's profile and recent work.
Wanna be featured next? Tag arkadiuszradek on X (Twitter).
Dmitry Sergushkin
This week’s choice is Dmitry Sergushkin, a talented product designer based in Ukraine. Dmitry’s style caught our eye. He knows how to make UI clean and visually pleasing, even if it’s part of a complex user flow.