Rethinking the Design Handoff

I’ve been working for over a year to improve the working relationship between web designers and engineers. The current best practice is characterized by the “design handoff”, where designers provide pictures of app screens to engineers for implementation. Approaching this problem, it’s hard not to notice a grassy knoll littered with tombstones: the hill that others have died on, trying and failing to “eliminate the handoff”.

Early in my research, I spoke to an entrepreneur who had a spot on this hill (and not a bad one, his business was acqui-hired before their product was sunsetted). His perspective cuts against the grain: maybe the handoff is not so bad. Perhaps so many have failed, not due to timing or team or technology, but rather because the very handoff they were working to eliminate is a useful part of the process of building a product.

These reservations led me to go from hating the handoff, to loving it, to finally — in dialectic fashion — resolving the contradiction through synthesis. With this adjusted mindset, and propelled by passion for the creative process, I’ve started a company with a fresh take on the relationship between engineers and designers. Instead of eliminating the handoff, our goal is to transform it.

The Joys of Handoff

The handoff is a useful checkpoint. Product teams create many iterations, often in consultation with engineers, before a design is handed off. The “final” design specification is a contract between design and engineering. The engineers “accept” the design, meaning they promise to build something that matches this spec. With the handoff, teams can ensure designs are complete, high-quality, and stakeholder-approved before engineers begin implementation.

The contractual nature of the handoff formalizes various working relationships. In its most extreme form, the handoff is literally part of a contract, as design agencies hire external teams to implement this spec for a fixed fee. If something is missing the agency can point to the spec and say “here, you missed something”. Likewise, if the agency asks for something new, the contracted engineering team can say “well, that wasn’t in the designs”.

More commonly, designs are handed off within an organization. The client/provider power dynamic is echoed in a less formal (but still somewhat contentious) product/engineering departmental power dynamic.

The handoff fits neatly into an industrial-age way of thinking about process: a series of ordered steps towards a result. As anyone who’s read Peter Drucker or the agile manifesto knows, top-down processes where information flows in one direction are not considered ideal in the digital age. Products that dominate markets are typically created in small steps by integrated teams working non-hierarchically. Everyone in the organization contributes according to their expertise at the exact time their insight matters.

The handoff excels in groups organized using the traditional, militaristic, top-down flow of information from managers to workers. Stakeholder-approved designs clearly signal to engineering: “do exactly this”. When the spec neatly aligns with engineering constraints, products are built efficiently. When handed-off designs are not technically possible, or more costly than alternate solutions, the result is weak.

The handoff, due to its divisive nature, can split groups who otherwise experience no pressure to work in silos. The best teams fight against this separation by bringing engineers into the design process early and keeping communication channels open.

The handoff is painless for teams that are not very concerned with quality. The pictures and animations provided by design tools fall short of saying “do exactly like this”, since they don’t match the intricacies of code. However the handoff is a great way for a designer to say “make it somewhat like this”. In my interviews, the more obsessed with detail and quality a designer is, the more likely they are to be frustrated by the handoff. In companies with low standards, designers are checked-out and collecting paychecks, engineers liberally interpret the designs, and no one seems to notice that the end product is low quality.

A better industry standard will elevate not only the top teams, but also organizations that can’t invest heavily in product design. Perhaps the most toxic aspect of the handoff is its tendency to foster divisions between teams that otherwise would collaborate seamlessly.

The No-Handoff World

Replacing the handoff is far from straightforward. If there was no handoff, there would be no communication whatsoever! How could everyone contribute to the end product? Perhaps so many startups die on the hill of eliminating the handoff because their solutions replace old problems with new ones that are even worse.

What does a no-handoff world look like for web teams? We don’t know. No one has succeeded in eliminating the handoff for sophisticated web experiences which require engineers. We can look to other industries (for example, the level design process in game design) for inspiration. And there we see a trend: designers working within the implementation itself, fine-tuning every detail.

For simpler sites, engineers aren’t needed, and there is no handoff. Over half of the web is powered by NLC (no- and low-code) solutions ranging from Squarespace, Wix, and WordPress to Bubble.io, Reflow and Webflow. The design tool generates browser code, and the designer’s work is 1:1 with the implementation itself. These processes eliminate many of the weaknesses of the handoff:

• Stakeholders review the fully interactive end product. Since the actual implementation is the focus of design review, there are no surprises when the product ships.
• User testing can be performed on a full, exact version of the site. Prototypes can be quite close to the end user’s experience.
• Designers are not surprised when they see their work implemented. Intricacies of interaction can be fully assessed while designing.
• There is no communication overhead (as there are no engineers to communicate with).
• Work does not have to be done twice (once it’s designed, it’s engineered).

Despite these benefits, no-code workflows have limitations:

• Sophisticated products cannot be realized. Most teams today are building things that cannot be built with no-code tools and require at least some parts to be built by engineers. NLC tools are getting more capable, but not catching up to the ever-growing capabilities of engineered apps.
• Designers have to do more work, as they must manage the nuances of interaction while they iterate. This is inevitably slower than making pictures of a design, and can distract the designer by flooding the creative process with implementation details.

This last point is what comes to mind when I hear “maybe the handoff is not so bad”. In larger teams building sophisticated apps, the handoff shields the designer from all the messy details of the exact implementation. This allows designers to focus on the user’s goals, without worrying about low-level design details. There is a time and a place for this in design. It’s important for creatives to interview users and discuss abstract goals. But is it not equally important for designers to control the subtle nuances of product realization?

The Solution: Choice

We are constantly reminded these days of how design is about more than details. About 15 years ago, the practice of “UI Design” became rebranded as “UX Design” to highlight that designers are not merely concerned with low-level concerns such as font, color, size, and spacing. The designer guides the overall user experience (UX).

In the past 5 years, as UX Design has become associated with small details, designers have rebranded themselves as “Product Designers”, again to highlight high-level guidance of the product as opposed to small details.

While this focus on high-level user goals and motivations is important (and helps justify fair salaries), design can’t disassociate itself as a practice from the very smallest of details: Helvetica vs. Roboto, a 10- or a 12-pixel margin, whether an animation takes 0.5 or 0.75 seconds to complete.

We can visualize design as a chain of decisions. Choices at the top of the chain (how a user feels in relation to the product) are beautifully linked to intricate implementation details at the very bottom of the chain.

I say “beautiful” because this chain is what makes design so amazing as a practice, and such a fascinating thing for non-designers to behold. We all know what it’s like to appreciate the continuity of the lines on a car body, perfectly arranged and in harmonious synthesis with the functional aspects of the vehicle, and think to ourselves “was this vehicle heaven-sent”? When design decisions along the entire length of this chain are spot-on, the effect is sublime. We see this transcendental quality in all kinds of designed artifacts, web apps included.

Web design process should allow designers to easily move along the full length of this chain. Sometimes designers need and want full control of the details. Sometimes teams have engineers with design experience who can fill in the gaps. The ideal solution allows for overlap between design and engineering.

Instead of a divisive handoff, we have collaboration. If teams want to have divisions and separations in process (for contractual or other reasons), they are free to add them. Process follows the needs of teams rather than the constraints of design tools.

This new way of working has benefits that go all the way to the top of the chain: user research. Designers can augment their existing products to explore user behavior with fully functional apps. Unlike current prototyping workflows, designers don’t have to stage scenarios, instead they can assess user behavior in the context of the complete app.

This re-imagining of the design handoff requires a new kind of designer, and of course a new toolset. I hope to share more about both in future posts. If you like this post, make sure to applaud and check out my prior thoughts on this topic.