The Best Handoff Is No Handoff

About The Author

Vitaly Friedman loves beautiful content and doesn’t like to give in easily. When he is not writing, he’s most probably running front-end & UX … More about Vitaly ↬

Email Newsletter

Weekly tips on front-end & UX.
Trusted by 200,000+ folks.

Design handoffs are inefficient and painful. They cause frustration, friction and a lot of back and forth. Can we avoid them altogether? Of course we can! Let’s see how to do just that.

Many companies organize their workflows around projects and departments. Especially in large companies, work often travels from one place to another, often getting stuck between emails and Slack messages, and often “refined” on its never-ending journey between design and engineering teams.

This inevitably brings up the question about the design hand-off: that magical moment when designers are done with their work and developer can take over. Most importantly, that’s where designers must stop working, and move on to other work — unless the scope changes or late adjustments creep their way in.

A man with a bald head and beard is sitting in an inflatable life raft while stranded in the middle of the sea trying to patch the holes caused by a seagull with a thought bubble containing random characters to show that the man is cursing and not really having a good time
Too often things don’t go as expected. (Image credit: José Torre) (Large preview)

The “No Handoff” Method

Last week, I stumbled upon an interesting article about the no-handoff method, in which Shamsi Brinn shows an alternative to typical design hand-offs. Shandi shows a fluid model where product and engineering teams work on the product iteratively all the time, with functional prototyping being the central method of working together.

Double Diamond illustration
Before and after: the good ol’ Double Diamond on the top, an alternative “no handoff” method on the bottom. (Image credit: Shamsi Brinn) (Large preview)

With the process, the working prototype is the living spec of the project and a shared language for the team. No more translation is needed because everyone works on the same prototype. The problem space and the solution space are explored by designers and engineers collaboratively, and the entire workflow is organized around the product, rather than company’s internal structure.

The “Hot Potato” Process

This reminded me of the Hot Potato Process by Dan Mall and Brad Frost, where ideas are passed quickly back and forth from designer to developer and back to designer then back to developer for the entirety of a product creation cycle — similar to throwing hot potato back and forth (audio, video).

Hot Potato process
“Hot Potato” process, with designers and engineers throwing mock-ups and prototypes to each other repeatedly. (Image credit: Dan Mall) (Large preview)

From my personal experience, I can only testify that the best collaboration doesn’t have any handoffs between teams. There, work flows seamlessly from design to engineering and back — with both teams working simultaneously, and discussing issues as they occur, during the entire product lifecycle.

There are phases of independent work for sure, but there are also plenty of overlaps for collaborative work, which are opportunities to discuss the progress, explore what is and what isn’t viable and hence avoid lurking issues down the line.

Create As Many Overlaps As Possible

Of course, the process works well for small product teams. But what if a part of the product is outsourced to an external agency? Many companies choose the route of extensive documentation — almost to the last pixel, along with a brief explaining the strategy and the thinking behind the design.

This isn’t enough though. Design decisions have to be informed by technical implementations and its limitations. There is no universal language around design patterns and their interaction design either. And not every design detail can be implemented in an accessible and performant way. This is why beautiful mock-ups turn into painfully slow and inaccessible monsters.

An illustrations showing five hands working on a presentation on a board together
Engineers could and often should contribute to the design process. (Image credit: José Torre) (Large preview)

We can reduce the risks of hand-offs with dedicated overlaps between designers and engineering teams. With regular check-ins. Weekly reviews. Shared channels for communications. Visibility into the work done. Usability testing of functional prototypes and small but regular design revisions.

Design is a team work. It involves everybody who contributes to the website — from customer service and marketing to developers and designers. Any overlaps you can create will benefit the teams, their productivity, and ultimately your users.

Wrapping Up

So we want to move away from handoffs. But how to convince teams to change their workflow entirely? With a small experiment on a small project. Pick a project where you could test the waters and suggest a collaborative process. Ask what designers could do while developers are busy. Ask what developers could do while designers iterate. And enable both teams to work together, at the same time.

Ultimately, the success depends on one simple thing: just how well the teams work together. And if they can’t collaborate particularly well, chances are high that a design hand-off won’t make it any better, and a major change in the team culture will need to happen first.

You can find more details on design patterns and UX in the video library on Smart Interface Design Patterns 🍣 — with a live UX training that’s coming up in September this year.

Smashing Editorial (il)