I’ll pass: Why there’s a better way than automating your handoffs
Every now and then I see a tweet, a LinkedIn post, or get an email inviting me to do something I never want to do using some product or other.
“Automate your handoffs”, these messages say. In fact, just Google “automate your handoffs” and you get a collection of promotional material and blog posts telling you how to do it.
These messages are quite frustrating if, like me, you believe there’s a better way for designers to work effectively with their teams than to automate handoffs. Instead, as a design team at Auto Trader we focus on intensively collaborating with our colleagues and delivering towards outcomes together.
What is meant by automating handoffs?
When people say they can automate handoffs they’re referring to the moment in time when a designer is finished with the design, and wants to give assets (screen renderings, accompanying image resources, and so on) to a developer to implement.
The tools or processes that are being proposed intend to assist with this, typically by supporting things like clickable prototypes and allowing inspecting for CSS properties (to make these assets clearer), by bundling multiple things together (so it’s easier to understand what relates to what, in one place), and by adding accompanying notes, comments, and documentations (to minimise misunderstanding).
Why might this not be the ideal approach?
By describing these types of functions as “automating handoffs”, these tools promise something that, to my mind, is not achievable. The amount of documentation that is required to accurately communicate anything other than the simplest solution is completely impractical if we want to be able to move quickly and iterate.
To truly automate this, the collection of assets provided would need to successfully communicate — without misunderstanding or error — all of the following:
· Purpose & goal of the design work
· Every possible flow, including all non-optimal flows
· Every state or combinations of states possible
· All visual UI appearance at all relevant breakpoints
· Animations and transitions for all cases
· Probably lots of other things
The only realistic way to make this completely automated — to remove the need for human beings to communicate — is either to dramatically simplify all of these or not care very much how they’re implemented. It also requires that the information being communicated in the first place is perfect — free from error or omission.
There’s a better way
It is extremely difficult to automate these transitions. But more important is that it’s not desirable to do so.
Firstly, we should challenge the assumption that a “handoff” should happen at all — automated or not. The idea of a handoff is, to me, about the least agile concept imaginable. Let’s consider some of the things we should value in agile software development (and things we do actually value at Auto Trader):
· Early and continuous delivery
· Welcoming changing requirements
· Working software
· Motivated individuals working together
· Face-to-face conversations
· Simplicity
· Self-organisation
None of these things are enhanced by the idea of handoffs — the idea that one person (a designer) does some work, collects together a set of documentation, and then gives it to another person (a developer). It’s an anti-pattern.
In a better world, designers, developers, testers, and others collaborate intensively through iterative product design and implementation. In this world, “handoffs” are almost imperceptible — tiny, frequent, constantly occurring moments of teamwork.
Secondly though — while we may be working towards this world — there are moments where teams do go through phases of work that are more design, phases that are more development. And when this is your reality, I believe that trying to automate the transitions between these phases is the wrong choice.
Instead, at Auto Trader we would be thinking about how to produce less documentation and having more conversations. A “handoff” should be done as early as possible, with as much face-to-face contact as possible and a desire to get from an idea into working software using the most direct route possible.
Focus on communication not automation
If you want to improve how design and development work together don’t listen to siren calls of handoff automation, but focus instead on the practical work of how designers and developers work more closely together and talk to each other earlier and more often. And delete that email.
