In an idyllic world with clear segmentation between product, design, technology and business there would be a clear-cut way to take ideas through the pipeline of your team and output beautiful, functional and valuable software. The act of passing that idea from the product team to a design team, from design team to the tech team etc. may be known to people as “handoff” or “handover”. In principle it sounds like the perfect process.
But we don’t live in an idyllic world.
I want to discuss the notion of handoff to explore why as your team gets smaller, handoff can cause more harm than good and how to stop killing your product.
Quick recap of handoff
Using designer handoff as an example to illustrate, handoff is a process where a designer exports a set of assets and deliverables that a software engineer or team may be able to take and execute on. This isn’t the only handoff that happens; a product team, client or “the boss” will often need to pass downstream the vision or strategy to designers or, as is in some tech agencies, directly to developers to take forward. In many instances this works good enough, or can even work really well with the right type of team and working culture.
A list of design deliverables you might find in a design handoff process may include; wireframes, copy, style guides or updated design systems, prototypes, mockups or static maps delivered using tools such as Zeplin or Avocode. As the complexity of a product or feature increases the more detailed these deliverables need to become in order to communicate the finer nuances. The point of handoff as I understand it is to ensure that by the time it hits the implementation layer, it does justice to the original big picture thinking.
Why it’s killing your product
Some form of handoff is inevitable but in the purest sense it can imply that any vision can be designed and that any design can be implemented. That’s simply not the case. Conversely I’m not implying that it’s impossible to have a well thought-out and structured vision, turned into a coherent design that can be implemented flawlessly via handoff. It’s possible, but difficult. We’re all human and like most of us, we’re somewhere in the middle where we need some form of handoff and can rely on our own processes to fill the gaps.
Many greenfield projects start with a small team. Whilst validating new ideas against a market, you want to strike a balance of execution with experimentation. Discovering new business models demands experimentation and failure in order to succeed. Setting yourself a goal of perfect handoff and flawless execution closes you off from accidental discoveries and leaves less time for you to experiment and test against the market. At first it may seem like a strange trade off and indeed will feel counter intuitive, but perfectly executing the wrong idea won’t help you make meaningful progress.
Over-simplifying, these are some traits that get exhibited by trying to enforce and create the perfect handoff:
- You deliver much more slowly–enforcing handoff to only happen through deliverables means those deliverables need to be extremely clear and precise which takes time. That time taken increases if you need to make some serious changes to the design or structure. This step needs to somehow allow wiggle room for your work to quickly pivot or evolve as you learn more about your product and market.
- The end result is in danger of becoming lacklustre– you miss the opportunity to leverage the collective knowledge of the team to introduce new ideas and insights back to the beginning and feeding back any learnings. What could end up happening is each component in your team compromises their craft in order to reach the next stage and thus stifles innovation.
- Failures can easily become the blame game– hopefully your team and company culture can surpass this, but if not you have yet another failure point that can cause friction between teams and individuals. Even if it doesn’t come to this, there may be some underlying tension that could be resolved.
Cross-functional teams to the rescue?
In the earlier days I thought this would be the answer. “Yes! Let’s all just learn how to do each other’s jobs and we can overcome these drawbacks!”. Taken to one extreme, if all facets of a team were fluently skilled in each other’s disciplines then theoretically we could not only overcome some difficulties with strict handoff but also scale up the strategic, design or tech bandwidth as the need arises with a truly cross functional team. Alas, this too is an idyllic fantasy that not only comes with it’s own drawbacks but I think is practically impossible past a team of two.
Even so, there is still something we can learn from striving for this type of approach. I’ve found that even though I strive to include developers as early as possible when fleshing out a new design, I’m more able to arrive at a design solution that is closer to what we decide to implement and release at that point in time due to my previous experience as a developer. I’ve also had the pleasure of working with clients and partners who at least grasp the fundamentals of development and we’re able to progress a lot faster than I thought possible. It’s these experiences that give me confidence that it’s worth digging deeper.
So, what should you do?
These are some principles that I’ve picked up and follow that seem to make a good impact both for myself, and the teams and individuals that I work with.
- Immerse and teach yourself– spend some time learning and appreciating the craft of others. You don’t have to go as in-depth as I have, but even learning the basics can give you some fresh insight and make you better at your role.
- Collaborate and communicate often– at first it may feel like a lot of time wasted, especially in a developer’s shoes (trust me, I know), but you will thank yourself later when you find that you spend less time handing things back and forth and your time spent executing your craft increases in quality.
- Accept that you won’t always get it right, and move on– the ideas person doesn’t have to have the best idea, nor the designer the best designs, nor the developer the most eloquent approach to code. At the end of the day you’re a team working towards the same common goal (I hope) and it’s the team effort that determines whether you’ve truly succeeded or failed. An individuals success at the expense of another’s failure isn’t really a win.
- Design together– I can’t stress this part enough. At first you may walk on each other’s toes a little and it can feel foreign to the team, but over time your deliverables will become more crude where it matters since you can communicate more with the same. Using footballers as an analogy, the team know when the other will likely pass, dribble, shoot or fall back. Just the same, knowing what your other team mates intend reduces the need for minutiae and frees the team up to focus on making an impact.
What’s you’re take? Tweet your thoughts and comments to @chuckwired.
