What is pair programming?
If you’ve worked on Agile projects, you’ve probably heard of or witnessed pair programming. Pair programming is a practice where two developers program together at one workstation. One developer is the “driver” and the other is the “navigator”. The navigator observes what the driver is coding and gives guidance on changes to the code to improve the quality.
In its simplest definition, the driver is tactical and the navigator is strategic. The developers switch roles often and, in some environments, will switch partners periodically to increase the sharing of knowledge within a project.
I’ve seen this work beautifully in Agile projects. This style of work further enhances the already strong sense of camaraderie among a project team of dedicated, co-located developers.
How pair designing works
What happens when you apply the same technique to the user experience team on the Agile project? I’m not referring to the technique of design professionals pairing with a developer (which is also extremely beneficial to both parties) but rather two designers with varying skill sets pairing on a project.
Pair designing is more about 'whiteboarding' together. It’s about getting someone whose strengths complement your weaknesses and vice versa to collaborate with you, because they’re going to see things you don’t see.
When you pair user experience professionals with complementary skills in the breadth of the disciplines that roll up into UX, ideas are generated, discarded, refined and accepted much more quickly.
I’ve worked on projects where my counterpart is strong in information architecture (IA), strategy and research, complementing my strengths in visual design, interaction design and storytelling. I know that I work best with someone with a very strong vision who can aim my empathy in the right direction. Without that nudge, I run the danger of empathising too much with multiple parties: the user, the developer, the project manager, the business analyst … it’s a long list.
Get the Creative Bloq Newsletter
Daily design news, reviews, how-tos and more, as picked by the editors.
I’ve been working in this manner so regularly in the past few years that I wanted to see what other design professionals thought about the notion of pair designing.
Extreme collaboration
I spoke with Amy Silvers, director of user experience at a small startup designing educational software, and Trip O’Dell, senior UX and product design strategist currently working at a large consumer software product company.
Silvers recalls her collaborative experiences at a global digital marketing agency a few years ago:
“We didn’t do [pair designing] formally because we had a small team. We were the smallest team within the agency. We did sort of collaboration by expertise. Where some of us were stronger on the interaction design side, some of us were stronger on the IA side. And we solved problems together. Nobody was really talking about Agile at that time.”
When Silvers was at a major cosmetics company, she had some of her most successful and memorable collaborative experiences. During a fast paced app redesign, she recalls working very closely with one of the developers:
“[The offshore] lead iOS developer, had a lot of mobile development experience. I hadn’t done a lot of mobile design before this. So he and I would sit on Skype and he would tell me why something might not work, and he would sketch an idea that he had for how it could work and Skype it to me, and I would take it and talk through it with him.
"While we were talking, I would be working in Axure or Photoshop to flesh it out, shoot it back to him, and that’s how we got the [app] designed. It was extremely collaborative and it was pair designing, though I wouldn’t have called it that at the time.”
I asked Silvers what she thought the greatest benefit of this kind of design collaboration was:
“It was hugely successful. We got phase one out within six weeks, about a tenth of the time our traditional IT projects took. And it wasn’t exactly formal Lean, but we did have daily sprints and we got it out for feedback as quickly as possible. And we released the MVP. We iterated on that, and went back to Skyping with my new developer pal … in Ireland. It was one of the most successful collaborations I’ve ever had in my career. It was unexpected and unstructured, but it totally worked.”
A natural fit
When I spoke with Trip O’Dell, he had strong opinions about designing collaboratively:
“I’ve never formally done it, but gravitate to it naturally. In terms of co-designing, I think that it’s actually a critical check to personal biases about the user ... If you’re working really effectively, you’re leveraging each other’s skills and abilities to mitigate your personal blind spots and opinions.”
O’Dell believes that this type of design is a “natural fit for the kind of work we do”.
O'Dell considers himself to be much stronger at cognitive interaction models, but his basic philosophy is that “The dirty secret about UX is that it's a generalist's business. We all come from really diverse professional backgrounds and bring different strengths to the problem solving process.”
I asked him to talk me through his current collaborative process:
“I’m working on a project right now with multiple stakeholders. Colin Ochel, the UX prototyper I’m collaborating with, visualises the interactions for a lot of the problems I’m working through at a strategic level. He challenges my thinking, and we use a design scrum to review progress on a daily basis.
We loop in the product manager and talk through specific patterns and approaches and how they align with everything we’re doing. We’re putting our work up on the board every day and tearing it apart. What probably would have taken six weeks for me to accomplish alone is getting done in a week and a half simply because you have someone working with you, on the same wavelength, challenging and refining your best thinking.”
What O'Dell said resonated with me. I’ve also had very productive, rewarding collaborations with user experience professionals with strengths in information architecture, frontend development, product design, interaction design or visual design. In each instance, they all brought something to the table that I didn’t have. They each had a different perspective on how to approach a particular business need or design problem.
The right fit
Not everyone can collaborate effectively, though. The people who are going to succeed at pair designing are the ones who are open to criticism from all corners. They’re able to take the criticism as feedback on potential problems with the design, and not as a personal attack.
I’ve tried collaborating with people who are zealously protective of their designs and see them as a reflection of themselves personally. It’s very difficult to do any kind of collaboration, much less the close collaboration that pair designing calls for, with someone who can’t separate themselves from their designs.
Silvers has had similar experiences:
“I had a visual designer [who] was terrible at collaborating. He got to the point where he would just do exactly what was in the wireframes because he hated the pushback so much. I call that 'coloring in the wireframes'. That drives me crazy.”
When I asked O’Dell about what I refer to as 'diva designers', he immediately said they’re part of the problem in terms of blocking collaboration to create successful, usable designs.
“An engineer or a product manager, or a marketing person, can come up with a badly rendered bad idea. The diva designer is just as likely to come up with a beautifully rendered bad idea.
"For visual designers who want to focus on their craft, [working alone] is fine. They have to live within the guidelines of marketing and brand, but it’s OK if that’s what they want to do. But when you’re actually designing solutions for real people, there’s no place for that.”
Putting pair designing to practice
Often in Agile, as well as other development methodologies, the UX designer isn’t assigned to just one project. They’re sprinkled across projects. If you put two design professionals with complementary skills on the same project, they’ll be able to work two or three reasonably-sized projects at a time and bounce ideas off each other and work fast enough to stay ahead of development.
If getting multiple designer professionals assigned to a team is an issue, you don’t have to do it formally. Engage other designers or UX-focused peers to come and create ideas with you for an hour here and there.
And if you work in an environment where you don’t have other designers to collaborate with, look to other people on your teams. They may not be design professionals, but they certainly have design ideas. This is one of the practices espoused in Lean UX.
Silvers is currently working as a UX team of one.
“On my current team, I have no UX peers. But everyone on the team, even if they can’t design alongside me, can concept alongside me and whiteboard with me, and that’s hugely helpful. That’s making a really big difference.”
When you broaden your acceptance of who you collaborate with, you increase your potential for success.
Image via sporkist, licensed under Creative Commons
