Design for handshakes not handovers

If you’ve followed me for any length of time, you’ll know that I’m really bullish on the notion that practitioners of a craft should be able to understand the core principles of their neighbouring crafts in order to produce the best outcomes.

To put that in more clear terms, a designer should understand how their designs are built for their end platform but they don’t necessarily have to be able to implement it themselves. Understanding the core principles and basic architecture of the platform you’re creating for gives your team the best chance of great outcomes.

For the sake of this post, I’ll focus on my craft as a designer but you can apply this more broadly to any role. We all have adjacent teams and roles that are impacted directly by our work so understanding them at their core is essential.

One of the first things I ever built and shipped was my initial Figma plugin (then called Px››Em and now Hand››over). The original intention of that plugin was to make it easy to convert Figma design pixels into ems. I later upgraded this to be rem focused so that you could adjust your baseline pixel value and added more canvas detection features. This then evolved into a Mac, iOS and iPadOS app because I wanted to use it for myself and because I fancied learning SwiftUI.

But now I’m wondering if the name is right…

I’ve come to realise through my time across multiple startups, moving between design-only and design-engineering hybrid roles that a design is never really handed over. The physical files may be sent via a link or exported and shipped, but the learning and conversation, the heated debates on delivery, the nitpicking over alignment doesn’t stop. And as such, the handover never actually happened.

Handover implies responsibility is passed on. Handshake implies responsibility is shared.

In retrospect, the handover only really happens when it reaches the customer and even then, if you’re working in the right way, you iterate and learn, and then subsequently evolve the project further. Rinse and repeat. Handover never happened.

Working with designers at different stages in their careers and different levels of engineering knowledge, it becomes evident that for some, handing over offers a relief. A way to move responsibility off of their shoulders and onto someone else’s. Or to feel that their job is done and now it’s time to move on to the next thing. As such a handover implies responsibility is passed on, a handshake however, implies responsibility is shared.

In fast paced environments, this is certainly often true. But the best teams work like an organism, harmonious in form and consistently sharing resources and forever communicating. In an environment like that, hard handovers can’t ever truly happen.

To give another practical example. If an engineer was delivering a feature but hit a stopping point because something was missing from the original designs, should they a) stop work entirely, hand it back to the designer and wait? Or b) raise the issue with the designer, work to reach a conclusion together, and then carry on?

I’m guessing we’d all pick B. Well, that sounds an awful lot more like a handshake to me. An agreement, a shared understanding, teamwork, partnership.

So how do you design for Handshakes?

There’s five key points that really lead to great handshakes.

  1. Involve your developers early and often
  2. Share ideas
  3. Design together
  4. Keep connected
  5. Develop a bond´┐╝

1. Involve your developers early and often

Great teams work together throughout the course of a project. Rather than relying on finite touch points, they focus on passing the baton whilst continuing to run alongside their team mates, ready to take the baton again when their time comes.

The earlier and more often you involve developers in your process, the less likely designs are to be handed over and become undeliverable or need iterating.

When you’re ready to handshake, grab your developer and walk through the codable iteration of your work. Pass on the files and keep in constant communication as the project develops.

2. Share ideas

Be open to sharing developer thoughts and ideas. Design isn’t about gatekeeping so welcome a collaborative and open atmosphere, and let your developer challenge you during the entire process. The more you share, the more you understand each other and the more you’ll be able to riff off each other to get to the best result.

If you foster a good enough bond here, you may even be able to be less specific in certain design processes as your developer will know how you think (and visa versa) and as such, can make valid assumptions.

Equally, you’ll develop a better understanding of how your product actually works, and as such, learn to make better decisions initially before agreeing on final designs.

3. Design together

This collaborative space should invite co-designing. I challenge you to invite a developer into your file as you work, talk at the same time, design in real time. Getting comfortable with live designing will make a world of difference. You won’t get your deepest work done, but you’ll ensure the designs are developer friendly from the get go.

Invite questions. Invite challenges. Challenge them back. Think of this as your safe place to thrash ideas out.

4. Keep connected

Once your designs are feeling ready to go, don’t lose that connection. Whether you have regular stand ups, async chats, or use Loom to share progress, make sure you stay connected.

As the designer it’s your responsibility to encourage this and foster it within your developer. If you want to handshake rather than handover, own this part of the process.

5. Develop a bond

In the end, you should evolve a stronger bond with your developer. This will make a big difference in the long term as they’ll feel safer with sharing honest feedback, they’ll make better default assumptions or decisions and they’ll welcome the idea of working with you again.

This bond is one of the most important in a software development business because it ensures that what ships to customers is the best it can possibly be. Providing the idea is the right one, this execution phase is critical to success so if you can nail this process, you can be confident in the outcomes.

Finding the nuance

It’s all well and good for me to say that handovers aren’t right. This is merely my belief based on working with handshakes for most of my design career. Understanding how the development process works develops a deeper empathy for the difficulties these days to do with responsiveness, unpredictable screen sizes, data rates, device themes, accessibility settings and more. There’s so much to contend with, and building these great partnerships rather than transactions will leave your product feeling better than it ever did.

Make sure you share your process with your teams too. Be the leader of the handshake within your organisation and upskill other designers, developers and anyone else in the business on this collaborative process.

If you end up trying this handshake approach, let me know how you get on. I’d love to hear about it.

Further reading

Turning Handoffs into High-Fives