The other week, I was working towards a very tight deadline for a project at Made by Many. I usually relish these types of challenges — the chance to get my head into a new business, learning lots, unearthing problems and making stuff quickly. But this particular project presented a set of pretty meaty problems. It was complex and filled with edge cases.
At Made by Many we usually work on projects that, with a sufficient enough timescale, a small multidisciplinary team can work nimbly and efficiently to achieve way more than say a larger more cumbersome team might. However this particular project was different to some of our usual client engagements — we were working to an extremely condensed timescale.
Our project team consisted of a strategist, product manager, technologist and myself, the designer. But even with these smart people supporting me, I felt I couldn’t effectively tackle all the nuances within this project to this timescale on my own. So I put my hand up and asked for help. I felt we needed more than one designer to get the most out of the short time frame we were working to. A problem shared is a problem halved.
This turned into a little experiment for us in pair designing.
Now, the concept of pair programming might be familiar to some of you but if not:
“In pair programming, two people work collaboratively on the same task on a single computer. This encourages better communication, better clarification of the problem, and better understanding of its solution.”
Sounds good right? (maybe not the single computer part — in the context of design). With this approach in mind, here are a few things I learnt whilst working in a design pair:
Having two heads worth of inspiration and different perspectives, meant we came up with lots of contrasting approaches to solving our set of problems quickly. We were working on an e-commerce experience, and at this stage of the project we were tackling a relatively linear user journey to begin with to add focus. With both of us working together, we were both sketching up the same steps in the process and battle royal-ing opposing solutions to efficiently finalise the user journey and approach we wanted to take forward.
Once we had a fleshed out user journey, we upped the fidelity in Keynote. Having an agreed journey to work up, myself and Owen split the workload. He tackled the beginning of the journey and I started at the end — so that we met in the middle. Sitting next to one another and working off dropbox, we would take copies of each others keynote files every hour to see how the other was progressing, steal design styles or re-use elements. For instance If I’d worked on the navigation, Owen could steal it, riff off it and update his file whilst I stole the listing style he was working on.
We managed to cover most of our scoped user journey in a higher fidelity within a day. And by keeping the feedback loop super tight between us both, it felt like we covered a huge amount of ground very swiftly. I’d say about 4x faster than if just one designer would have worked on it on their own.
A problem shared
We often use well timed design critiques to help unblock our thinking and gain different perspectives on a problem, but when pair designing it felt like we had a constant dialogue up and running. This tight feedback loop meant we could unblock problems we were facing instantly. A quick conversation and some white boarding and we could move on to the next task at hand.
Know when to stop
Whilst it felt like we had a rocket booster applied to our usual design process, I found that paired working was only efficient for a finite amount of time. There came a natural point when it felt wasteful to have two designers working on the same thing. Once we were starting to over-polish our proposed solution or there just wasn’t the workload to sustain two designers we pulled the plug and I carried on solo to add a consistency to our design output.
It’s more fun
I didn’t feel as stressed, like the project was just on my shoulders. It felt great to spread the responsibility and work load — and we had more fun doing it together.
As far as the experiment went, I think it was successful. We managed to work side-by-side in a structured and efficient way, spreading the complex service thinking between the two of us. At the end of sprint retrospective, it was unanimously brought up by the team that it was a great way of working (for this kind of project).
Pair designing might not be appropriate for every project, but this experience has made me think differently about how we could resource future design projects at Made by Many.
What is your experience of working in design pairs? I’d love to hear them — fire me a note on twitter.