Tom here.
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 what they enjoy and less of what they hate.
Later, looking back, I realised that “politics” was really just a label I used for all that 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 the 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 an 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 absolutely 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”1, no magic incantation you could whisper in young Tom’s ear that would've enlightened him. I couldn’t have the correct “mindset” installed in me, like I was a faulty robot in need of a firmware update.
The way out was being able to try out alternative ways of working over time. I needed to experience collaboration as positive and exciting – to find more enjoyment jamming with colleagues than I did futzing about with colour palettes. I also needed to notice more of the downsides in the handoffish way I had been working. I needed visual mockups to lose some of their shine.
And over time, as I adapted how I was able to work with others, the parts I considered to be “politics” started to shrink, while the parts 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. Let them look after their own damn minds.
Wait, 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 down2. So there’s no single “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 that surround and connect the individuals and their interactions.
Individual factors
I’ve already shared one individual factor: my preferences. Young Tom liked to work by himself and disliked meetings and politics. This preference was supported by his beliefs about what he could influence. Preferences can shift naturally over time. In my case: from preferring perfecting something for handoff towards preferring starting and finishing together somewhat messily.
Note: I’m not saying young Tom was wrong in his preferences. If you prefer working a certain way, and you’re happy with the results you're getting in your current situation, then great! There’s no one right way.
But most ICs I've spoken with lately are frustrated. If you 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. Maybe you could try out something a little different.
Let’s look at another individual factor: the “easy path” that’s given to us by the tools and artefacts we use.
Very 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. I did that too, but I don't think I had any idea just how much got explored and thrown away. Because almost all the design work I saw in the wild was fully realised, glossy brilliance 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:
- lovingly craft a stunning, glass-effect button
- fuss over the golden ratio for my page layouts
- tweak an emotive animation for my navigation
- spend weeks crafting something that looked awesome (in parts)
- 2 days before the deadline, finally get the whole thing together in high fidelity.
- look up from the design tool, come face to face with reality, and realise that what I’d made actually wasn’t coherent or fit for purpose3
- pull an all-nighter to redesign the whole thing the right way from scratch – while crying.
This was expensive, unnecessary rework. But it was the best I could do at the time. Without better process, I had no choice but to make the whole thing in detail wrong before I could figure out how to make it again right.
Information from colleagues and customers
Until ... eventually ... I’d had enough of unnecessarily working and reworking those 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. Why couldn't they have told me at the beginning, dammit? And then I realised that it doesn’t matter how much you ask people to tell you all the constraints and limitations before you start ... people physically can't tell you about some of the constraints until they're faced with a concept that crashes into them. At which point I had to re-jig everything I'd crafted ... and it never fit together right again. Better to start again from scratch while crying.
But then I started to realise that I could learn about 90% of the constraints, limitations, usability and technical issues by making work that was fast, ugly and rough. Zero effort on polished visual design, maximum effort on drafting the conversation between user and system. That kind of artefact alone was enough to stimulate colleagues and customers to tell me everything I needed to know, and it was considerably less painful to change.
And — last of all — I accepted that high fidelity mockups in design tools are wishful thinking. You can draw anything you like in Figma or Photoshop. It won’t necessarily translate when it’s shipped into code.
Even if you stay in the bounds of what's possible, you’re not the one writing the code. After you hand off your wishful thinking to the developers, they’re in control.
You hear designers complaining about developers "ruining their designs" all the time. Stop a moment and put yourself in the dev’s shoes. Burndown charts. Daily standups. Tickets and bugs flying around. 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 were forced into agreeing to is looming. You open the design mockup you’re supposed to build and figure it’ll take five hours to code and debug exactly what the designer drew … or five minutes to drop in a drab-but-serviceable alternative. What are you gonna choose?
Some designers still cling to a 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 it as I intended!”
Sure.
Meanwhile, over the past decade, UI kinda got boring. Collectively, we’ve figured out a lot of patterns and collected them into design systems. (And hey presto, design systems are the new place designers love to cling to the illusion that they can control things, while in reality having less control than ever!)
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, 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, or even a notepad file.
Handoff artefacts
In the section above, we touched on the interactions between designers and developers, stakeholders, and other colleagues. Let's zoom in on one critical 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 — months even — 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 in an hour. He 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 many 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 it isn’t the case.
So think about who you're showing mockups to. Perhaps that belief that they need to see high fidelity is really just that you’re afraid of showing something “unfinished”, in case they judge you as if it’s your best work. And let's be fair, you might be right to be afraid, because some people absolutely will judge you.
Tips for sharing unfinished work:
- explain that it’s deliberately rough like this so you can 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.
- share it within hours of starting, so nobody’s left wondering if this is the best you can do. This forces you to get the main ideas sketched out fast rather than rabbit holing into fussy details.
- 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, far too long.
- pay attention to how people engage with the work you share. If you’re not triggering the conversations you want, try different formats, different levels of fidelity. I'll bet you a fiver you need way less polish. But maybe you do have to polish it more first.
Because hey, turns out 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. (Yep, I know I’ve made that mistake before.)
Last point on artefacts: 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! But of course, they also won’t hire proper writers to sort it out. This forces someone to be the hero.
Organisational constraints
Zooming out another level, let’s look at some organisation-level constraints:
First, 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 getting the structure or narrative really clear. Visual polish “sells”, especially to non-designers.
Next, what’s your organisation’s tempo? Do you have enough slack in the calendar to spend time collaborating? Perhaps everyone’s just too slammed to spend time working together on things.
When calendars are crammed, you get a vicious cycle:
- managers want to “get ahead” of the next project by preparing designs in advance
- but the developers are way behind on the current sprint, so they don’t have capacity to think about what’s coming next
- so the developers can’t influence designs in ways that are easier to implement
- so they’re even more behind on the next sprint
- and managers want to “get ahead” even more
And it gets worse. Because everyone’s in back-to-back meetings, feedback cycles are incredibly slow. You have to wait 2, 3, 10 days before you can get any feedback on your work, so 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.
In many companies, everyone on a "team" is actually working on multiple completely different projects in parallel, not one or two projects together. That's not collaboration, that's cohabiting.
Speaking of performance reviews, when designers are judged, does anyone take into account the flow of work, or the time to outcomes across the whole system you’re a part of? Or are you judged locally, on your ability to visibly "pump out screens" quickly? Or your skills at manoeuvring the backchannels to get pretty mockups signed off?
Crap, that’s a lot of conditions and we’re still only scratching the surface.
Can you shift the conditions?
Shifting from handoffs to “start together finish together” is influenced by all the conditions mentioned above and more.
Anyone can try out using different tools and collaboration styles at the individual and team levels, creating a local pocket that's different. But to really have it become a norm, you have to shift constraints and norms across a 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.)
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:
- 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.
- the Innovation Lab coaches would drag BigCo team through 12 weeks of working collaboratively.
- at first this would be hard and awkward. It would feel slow and painful – not at all like progress at first.
- but they’d eventually cotton on: hard at the start is the secret behind effective collaboration: if you front-load the hard stuff, it doesn’t kick your ass later on, when it’s too late to change plans.
- by the end of the 12 weeks, the team would have shipped something that would have normally taken them 2 or 3 years.
- As the finale, they would demo the work to their company leadership, who’d be blown away.
- the Innovation Labs team would make it clear that the team could totally continue like this … in theory. But that this pace and quality would all go away as soon as they had to slot back into the normal BigCo way of working.
- The BigCo bosses would nod their heads and make encouraging noises.
- Occasionally, the BigCo team would be able to sustain a little of what they’d learned.
You see, the team in question had shifted their individual and interaction conditions. But all that would mean nothing unless the wider organisation could change the broader conditions they had to operate within.
And that's why handoffs are still happening.
When fast, collaborative working is hard to start, hard to maintain, and personally risky, we shouldn't be surprised when it mostly doesn’t happen.
OK 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 This is 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.
