Addressing the Handover
By: Jonny Gibson
Tags: Development, Teamwork, Design, UX, Psychology

I don’t like the word handover.

In design circles it implies the end of involvement for one group and the start for another. Designers will create a suite of assets, whether it’s a style guide or page designs, and then hand those over to a developer to be coded.

The designer dusts his hands and moves onto the next task, while the developer gets the design equivalent of a bucket of cold water to the face and is told to get cracking. For some reason, we expect developers to see all the countless micro-decisions the designer has made, understand the designer’s intent, and execute in accordance with it — even when the delivered files have unintentional discrepancies… (sorry designers, but you know it’s true).

This traditional waterfall process is still ever present, and common amongst a lot of digital agencies. It’s another hangover from the old creative agency model. But even the often lauded agile method has limitations, and doesn’t solve the issue of asset handover and collaboration. Not fully.

The main problem is that there is a gap between those who do the thinking and those who are responsible for the doing. We’re not really working as a team.

Typically, there might be a group of strategists, responsible for setting up the vision or proposition for a project or product. Then there are designers who ideate concepts for an interface or design aesthetic. Then we have the developers who are responsible for bringing all of the above to fruition. Projects will often work their way through teams in this manner and in this order. It’s rare that you find a developer involved in the ideation process, rarer still to find them included in the strategic thinking.

This is not how good teams work.

The most effective teams have a shared understanding, language and goal. Sports teams are a great example of this. They can only be successful when they work together.

They communicate often and openly, spending time getting to know how the other thinks and plays so that they can facilitate better for one another. They have a single purpose, and work together using each other’s individual skills to achieve a common goal — without a big handover. They are in-sync.

Project teams are no different. We all have a common goal of creating a successful, useable and beautiful product for our client and the real people that use it, in the least stressful way possible. To do this we need to be inclusive, contributing to the entire project cycle through the lens of our individual disciplines. Only when we collaborate in this way will we be truly efficient and successful. This collaborative culture spells the beginning of the end for the unhelpful handover.

The first step to greater collaboration across disciplines is understanding. It’s no longer viable for disciplines to be specialised in execution at the expense of understanding each other’s craft.

I’m not saying that teams should be multi-disciplined in execution, in fact people who heavily differentiate their skills usually end up with one of them suffering as a result (jack of all trades, master of none). But like any great sports team, we need to have a clear understanding of how each other works and what we need from one another in order to do the best work we can.

Fortunately, there are some simple steps that can help steer your project team in the right direction.