Why are teams still doing design handoffs?

An incomplete list of conditions that keep handoffs happening in many places

Hey there!

Before we begin, two quick notices for you:

• 15th October Intro to Multiverse Mapping: https://lu.ma/30e085v7

• Got 10-15 mins? We want to know how you’re feeling about the world of tech, design and product right now. Add to this huge gathering of stories from people like you who are on the front lines of digital work: https://bit.ly/stories-from-tech

OK let’s go —

I remember being a young designer and just loving working in my design tools, making cool, beautiful images, playing about with colours and motifs, exploring visuals and interactions. It was awesome. This was what fascinated me in design at the time. Meanwhile, I really didn’t want to deal with meetings and “politics”.

Shock insight alert: apparently people want to do more of the parts of their work that they enjoy and less of the parts they hate.

Later, looking back, I realised that “politics” was really just a label I used for all the human and business stuff that was outside my control. Eventually I had to accept: that is the work. But as a young designer, I didn’t have the emotional tools or political nous to handle that bigger reality, so I hunkered down in my comfort zone of bezier curves and tasteful drop shadows. I could control the pixels in my design tool, make them line up and dance to my whim, like some kind of RGB dictator. The stuff that happened after I handed off my work — when my pixel-perfect design was inevitably “ruined” by clients or colleagues — well, that stuff wasn’t my responsibility.

Reader: it was my responsibility.

But at that time in my career, I couldn’t just be told this. There was no way to make me change my “mindset”¹, no magic incantation you could whisper in young Tom’s ear that would enlighten him. I couldn’t have the correct “mindset” installed in me – like I was a faulty robot that needed a firmware update.

I needed to try alternative ways of working over time. I needed to experience collaboration as positive and exciting – to enjoy jamming with colleagues more than I enjoyed fiddling with colour palettes. I also needed to notice more of the downsides in the way I had been working – to for visual mockups to lose some of their shine.

As I adapted how I worked with others, what I considered to be “politics” started to shrink, while what I considered “collegial collaboration” started to expand. My experiences changed first, my mind changed much later.

This is a basic complexity principle: don’t try to change people’s mindset imagining that desirable behaviour will follow. Instead, change people’s interactions, enable novel behaviours to emerge, and let them look after their own damn minds.

Why am I telling you all this? To explore why handoffs still happen

A few months ago, when I shared 5 things that surprised me at a conference, one surprise I mentioned was that handoffs are still everywhere. Someone on LinkedIn asked me: so what keeps teams doing high-res handoffs, even when they know it’s causing pain?

This piqued my interest and so I started listing conditions.

As in any complex adaptive system (like a human or an organisation, for example), there’s no root cause and linear cause-and-effect breaks down². So there’s no “because” when it comes to handoffs. Instead, there are many entangled conditions. Some are to do with individuals, some with the interactions between individuals, and others with the constraints and narratives around them.

I’ve already shared one individual factor: my preferences. I personally liked to work by myself. I disliked meetings and politics, and this was supported by beliefs about what I could influence. Preferences shift over time. In my case from preferring handoffs to preferring what you might call starting and finishing together.

Note: I’m not saying young Tom was wrong in his preferences. If you prefer working a certain way, and you’re happy with everything that’s happening around you, then great! There’s no one right way. But if you’re frustrated, and wish you had more influence or control over outcomes, then maybe you’re not satisfied with your way of working. Maybe you’re only comfortable with it.

Let’s look at another individual factor: the “easy path” that’s given to us by the tools and artefacts we use.

Young Tom didn’t really have tools or methods to show anything other than high fidelity screen mockups. I’d heard that designers started with sketches to explore ideas, and that they threw lots of work away. But almost all the design work I saw in the wild was the featured work in magazines and books – the best of the best ideas in their final, polished form.

Monkey see monkey do! I rushed to polish with this kind of process

1. lovingly craft stunning, glass-effect buttons

2. fuss over the golden ratio for my page layouts

3. tweak an emotive animation for my navigation

4. spend 3 weeks crafting something that looked awesome

5. 2 days before the deadline, I’d finally designed the whole thing in high fidelity.

6. look up from the design tool, come face to face with reality, and realise that what I’d made actually wasn’t fit for purpose³

7. pull an all-nighter to redesign the whole thing the right way from scratch – while crying.

It was expensive, unnecessary rework. But it was the best I could do at the time. I had to make the whole thing in detail wrong to figure out how to make it again right.

Until ... eventually ... I’d had enough of unnecessarily working and reworking high fidelity mockups. It’s painful when you've polished something till it looks amazing and then you find out it can’t work that way because of something nobody thought to mention earlier. And I realised that it doesn’t matter how much you ask people to tell you all the constraints and limitations before you start ... you will never find out about all of them until you show them your completed design that bumps up against them. And then you have to ruin everything you crafted and it never fits together right again. It was often easier to start from scratch.

And then I started to realise that I could learn 90% of the usability and technical issues by making something really fast and rough. Not by spending time on polished visual design, but by quickly drafting the conversation between the user and the system. That was usually enough to stimulate colleagues to tell me what I needed to know, and it was considerably less painful to change.

And — finally — I accepted that high fidelity mockups in design tools are pretty much wishful thinking. You can draw anything you like in Figma or Photoshop, but quite a lot of it just won’t translate when it’s shipped into code.

Even if you stay in the bounds of the possible, you’re not the one writing the code. After you hand off your wishful thinking to the developers, they’re in control. I hear designers complaining about developers ruining designs all the time. But stop a moment and put yourself in the dev’s shoes. You’re under massive pressure to ship, you have folks breathing down your neck asking when it’s gonna be done, and the deadline you promised is looming. You look over the design mockup you’re working on and figure it’ll take five hours to tune and debug exactly what the designer drew … or five minutes to drop in a drab-but-serviceable alternative. What do you choose?

Some designers still want to cling to that dream: “if I can just make my design cool enough and clear enough, then I’ll finally inspire everyone to overcome all constraints and barriers and implement as I intended!” Sure.

Meanwhile, in the past few years, UI kinda got boring. Collectively we’ve figured out most of the patterns and collected them into design systems. (And hey presto, that’s the new place designers love to cling to the illusion that they can control things!)

Personally, I find it weird that more designers don’t want to work with the narrative layer. As soon as I was introduced to that through working with

Corissa Nunn

, I didn’t look back. The conversation betwixt user and system is where it’s at! It was hard to work on that layer in Photoshop, but it’s easy and fun in Miro, FigJam, etc.

In the section above, we started considering interactions between designers and developers, stakeholders, and other colleagues. Which brings us to another interaction: who are you making a handoff artefact for?

I remember clients and colleagues who couldn’t “understand” anything other than high fidelity mockups. For them, I still had to spend weeks or months making and remaking mockups.

At the other end of the scale, I remember the developer who took a rough story map and draft copy we’d laid out together in Miro, and implemented a complete, decent-looking solution in working code. Then we jumped on a call and tweaked it. It took 2 days from starting together to finishing together.

Over time, I’ve experienced more situations like the second and fewer like the first. We're past the earliest days of the web – the days when obsessing over every pixel of your corporate microsite homepage felt like a valuable use of everyone’s time.

But I’ve also experienced colleagues who still believe that pixel-perfect mockups are the only way to communicate, even when that isn’t the case.

Depending on who you’re showing your mockups to, perhaps it’s really that you’re afraid of showing something “unfinished”, in case they judge you as if it’s your best work. To be fair, you might be right to be afraid, because some people will judge you.

Tricks for sharing unfinished work:

1. explain that it’s deliberately rough to get the right feedback for this stage of work where you’re interested in the big picture of how it works rather than the details.

2. share it within hours of starting, so nobody’s left wondering if this is the best you can do. This can help you to get the main ideas sketched out fast rather than getting lost in the details.

3. reference Pixar’s rule that work should be between 20% and 80% done when you bring it to the brain trust. Too early and there’s not enough for people to respond to, too late and it’s far too uncomfortable to consider structural changes. If in doubt, remember that most people wait far too long.

4. pay attention to how people engage with the work you share. If you’re not triggering the conversations you want, try different formats. Maybe you do have to polish it more first.

Because hey, developers also have preferences. Some love making sketches or user story maps together, figuring out the behaviour and flow as a team. But some want to be given a mockup and left alone to spend more time doing what they love – playing in coding tools, rather than being in meetings or dealing with “politics”.

Perhaps you or one of your colleagues wants to be the hero – to be the one that solves all the issues single-handed. (I know I’ve made that mistake before.)

At a team level, I’ve noticed that almost nobody on any team likes working on the most important part of the design: the copy! Of course, they also won’t hire proper writers to sort it out. This forces someone to be the hero.

Zooming out another level, let’s look at some organisation-level constraints:

What gets rewarded in your neck of the woods? This can be as subtle as people saying “wow” about visual polish, while shrugging when you’ve sweated over clear structure or narrative. Visual polish “sells”, especially to non-designers.

Next, what’s your organisation’s tempo? Do you have enough slack in the system to spend time collaborating? Perhaps everyone’s just too slammed to spend time working together.

This creates a vicious cycle:

1. managers want to “get ahead” of the next project by preparing designs in advance

2. but the developers are way behind on the current sprint, so they don’t have capacity to think about what’s coming next

3. so the developers can’t influence designs in ways that are easier to implement

4. so they’re even more behind on the next sprint

5. and managers want to “get ahead” even more

In some companies, everyone on a team is actually working on multiple different projects in parallel, not one project together. Here, collaboration is a myth.

Of course then everyone’s in back-to-back meetings, which makes feedback cycles incredibly slow. If you have to wait 2, 3, 10 days before you can get feedback on your work, why wouldn’t you use that time to polish the work up?

And does your org truly encourage collaboration, or only “collaboration”? Perhaps it says “we are team players!” in lovingly typeset values statement on the walls, but the reality is that performance reviews pit you against your peers.

Speaking of performance reviews, when designers are judged, does anyone take into account the smoother flow and shorter time to outcomes across the whole system you’re a part of? Or are you judged on your ability to pump out screens quickly, and manoeuvre to get your pretty mockups signed off?

That’s a lot of conditions and we’re still only scratching the surface.

Shifting from handoffs to “start together finish together” is influenced by all these conditions and more. Yes, anyone can try out using different tools and collaboration styles at the individual and team levels. But to really have it become a norm, you have to shift constraints and norms in the whole organisation. This can start to happen when a small team can knock it out of the park by delivering consistently, quickly and at a high quality by collaborating. But that team also takes a massive risk because their weird success can feel like a threat to others. (I’ve heard of more than one team that was “managed out” because their pace and results made other teams look bad.)

Can you shift conditions with shock therapy?

I once nearly took a job with the Innovation Lab at Redhat. I loved the vibe of the space, which felt like less like an office and more like my dad’s sports science lab at Loughborough University.

The team there told me about how they would teach teams from huge global corporates how to work collaboratively.

Here’s how it worked:

1. BigCo team would leave their corporate environment and move into this totally different space: a lab with mess all over the walls, where there was no choice but to collaborate.

2. the Innovation Lab coaches would drag BigCo team through 12 weeks of working collaboratively.

3. at first this would be hard and awkward. It would feel slow and painful – not at all like progress at first.

4. but they’d eventually cotton on: hard at the start is the secret behind effective collaboration: you want to front-load the hard stuff so it doesn’t kick your ass later, when it’s too late to change plans.

5. by the end of the 12 weeks, the team would ship something that would have normally taken them 2 or 3 years.

6. They’d demo the work to their company leadership, who’d be blown away.

7. the Innovation Labs team would make it clear that the team could totally continue like this … in theory. But that this would all go away instantly if they had to slot back into the normal BigCo way of working.

8. The BigCo bosses would nod their heads and make the right noises.

9. Occasionally, the BigCo team would be able to sustain some of what they’d learned.

You see, the team in question had shifted the individual and interaction conditions. But all that would mean nothing unless the wider organisation could change the broader conditions they had to operate in.

When fast, collaborative working is hard to start and hard to maintain, don’t be surprised when it mostly doesn’t happen.

So there’s my incomplete list of conditions that tend to keep handoffs happening. Can you think of any more that I’ve missed?

Until next time,

Tom x

---

Thanks to

Corissa Nunn

for editing and clarifying.

Photo by Jeff W on Unsplash

1. In quote marks because “mindset” as a concept is incoherent with neuroscience, but it’s a broadly recognised idea. I bet you’ve come across someone who wants to change people’s mindset!

2. I know this will frustrate some people, as a heck of a lot of the way things are framed in businesses is “if we do X then we’ll see Y result” … all I can suggest is that you think through how often such effects actually happen vs how often conditions and effects just kinda change in ways that our outside our control. If there’s one thing I learned from tons of A/B tests, it’s that businesses have way less direct control than many people like to think.

3. Sometimes this was getting client feedback (should’ve got it sooner), sometimes usability testing (should’ve done it sooner!), sometimes it was feasibility issues from a colleague (should’ve checked it sooner!), sometimes it was just stepping back and getting some damn perspective.