UX Magazine

Defining and Informing the Complex Field of User Experience (UX)
Article No. 88 November 20, 2006

Pair Design Pays Dividends

In agile development methodologies, pair programming is considered a key practice.

Pair programming involves two programmers (in any combination of novice and/or expert) working together to write code.

Advocates of agile methodologies outline a range of advantages of pair programming, and I’ve always thought that it would be a great approach to design.

In my experience, designing can often be a rather lonely activity.

If you’re fortunate enough to be able to integrate real users into your design methodology then that can break it up a little. If you’re working within a team of other designers, perhaps you’ll be able to get them to review your work from time to time and give you some feedback. Working in a ‘pair design’ environment is apparently quite rare.

I’ve been fortunate enough to work on a few projects where we’ve taken a ‘pair design’ approach, and I’ve been pleasantly surprised that the benefits that the agile advocates outline for pair programming largely hold true for pair design.

Using the list of benefits set out by Wikipedia, here’s a run down of what I’ve found.

Increased discipline. Pairing partners are more likely to “do the right thing” and are less likely to take long breaks.

Whilst I like to think that I ‘do the right thing’ when I’m designing solo, I have certainly found that working with another designer does heighten your focus on the task at hand and, even more importantly, lengthens the time that this level of focus can be maintained.

I’ve also found that in pair design, you tend to design more away from the computer, instead using flip charts and pencil and paper, and post it notes stuck all over walls and drawings and user flows that you’ve mapped out on paper.

This is good design practice but, even better, keeps you away from the distraction of email, and bloglines, and all the other kinds of distractions that you find on your computer.

It keeps you focussed on the design process. This makes you design better, and makes you more efficient.

Better code. Pairing partners are less likely to go down ratholes and tend to come up with higher quality designs.

I don’t know about ratholes… But I do know that when designing in pairs there tends to be a more rigorous approach taken to design decisions.

This is because you have to be able to explain each decision you’re making, or design approach you’re taking AS you make it, not in retrospect.

Each decision needs to be justifiable. And, because you have someone there designing with you, you get to actually discuss the benefits of each approach rather than just doing what you think is best (or worse… what you can do most easily in Visio because you have a template already set up that way…. Oh, come on. You know you’ve done it.)

On the ‘going down ratholes’ issue though, if you happen to be designing with your client, then you are able to check really quickly whether the approach you’re taking has a hope in hell of being adopted by the client.

This means that you don’t waste time designing something that will never be implemented, and that what you do design has a much better chance of adoption.

On that note – designing with your client means that they understand the rationale behind every design decision. So, if you’re just a temporary resource on the project, you leave behind an evangelist for your design – again, making it more likely that what you’ve designed will actually survive the development phase.

Resilient flow. Pairing leads to a different kind of flow than programming alone, but it does lead to flow. Pairing flow happens more quickly: one programmer asks the other, “What were we working on?” Pairing flow is also more resilient to interruptions: one programmer deals with the interruption while the other keeps working.

For me, getting stuck into designing IS flow. But see above re: increased discipline and below re: less interruption. Both of those definitely mean you get lots more flow time, which is all good.

Improved morale. Pair programming can be more enjoyable for some engineers than programming alone.

As I mentioned before, designing solo can be a lonely business. When you crack a really curly design problem, there’s no one to celebrate with… well, no one who really gets it. With pair design, you have a celebration partner. This is good :)

Collective code ownership. When everyone on a project is pair programming, and pairs rotate frequently, everybody gains a working knowledge of the entire codebase.

OK. This has been a little less relevant to me, as a consultant, but see above re: designing with your client and gaining and evangelist.

Mentoring. Everyone, even junior programmers, possess knowledge that others don’t. Pair programming is a painless way of spreading that knowledge.

This is almost certainly true when you have an expert/novice pairing, but even when you have two designers with similar experience there is a lot to be learned.

How often do you get to actually watch the process that other designers go through and how they approach their work? Not often, I’d guess.

This is a great opportunity to say, ’so hey, here’s how I do it… how would you do this?’ and pick up some handy new ideas or approaches or Visio tricks.

Team cohesion. People get to know each other more quickly when pair programming. Pair programming may encourage team gelling.

Agreed. Pair designing is definitely a great icebreaker :)

Fewer interruptions. People are more reluctant to interrupt a pair than they are to interrupt someone working alone.

Now, this one is DEFINITELY true, and don’t underestimate how important this is.

You can get an awful lot of design done in a couple of hours if that’s ALL that you’re doing. But how often do you actually get this much time to do nothing but the design you’re working on?

In my case, not that often. Two people in a room makes you MUCH less interruptable!

One fewer workstation required. Since two people use one workstation, one fewer workstation is required, and therefore the extra workstation can be used for other purposes.

Well, in our case we abandoned workstations all together and took over a small office/war room. So, I guess there have been a couple of free workstations!

Choosing the right co-designer is pretty important. I’d be loathe to pair design with someone who knew nothing about interaction design… it would be way too much mentoring and not enough designing, which isn’t practical or appropriate on a ‘project’ based design.

I would however suggest that if you find a client who has people with the right skills, you do what you can to try to get them involved.

This is much more likely if you’re applying other agile methods that involve rapid designing and iterating.

Now, it would be unrealistic to suggest that pair design be adopted for all design projects, it’s never going to happen, and in many situations would be unnecessary.

But, if you do have the chance to work this kind of methodology into your project, then I’d encourage you to go for it. I think you’ll find it a very rewarding experience.

Have you experienced pair design? I’d be really interested to hear if you’ve had similarly good experiences, or if there are some horror stories out there!

ABOUT THE AUTHOR(S)

Add new comment

Comments

41
38

What you were doing is pair research not pair design.

38
46

It’s an interesting way to look at it. Are you suggesting to have two designers work on one machine or two designers work side by side on 2 machines in a parallel fashion?

I have worked parallel with designers on many occasions and we found it hard to work on 2 machines to work towards getting a job done. It proved a bit troublesome & confusing.

I’d love to see if anyone has employed anything like this strategy because it really is something to consider for the future.

31
41

hey Blaze, Actually what I’ve found is when you do pair design you tend to do a lot more design and a lot more detailed design on paper first, which is great.

Once you’ve solved all the big problems on paper, there are often logical ways that the work can be sectioned off and ‘realised’ electronically.

Usually once we get to the stage that we’re working on machines, the pair resource becomes more of a ‘review’ and QA process than an actual design process, although there’s obviously a lot finetuning and iteration that occurs at this stage.

By the time we get to a reasonably high fidelity prototype, all the work tends to be one one designer’s machine, but in the lead up each designer can work on sections of the design on their own computer… provided the work is well planned!

44
31

This is a great post and I would love to have this opportunity (alas I am the only web designer at my firm). What I have found useful is pairing with a developer who is going to implement some of the more advanced elements of the design (like Ajax). I have found that can work really well for many of the same reasons you address here – especially the explain as you go point.

37
33

Hmmm… I’ll definitely keep those points in mind when managing my next project. Whilst we would usually assign two developers to work together on a development process, it’s rare that you would offer two designers to work together in union, rather than submitting “competing” designs

36
40

Leisa you briefly mentioned the possibly of integrating ‘real users’ into the design process. Was this an abstract idea or does this actually happen. And if so, how exactly does something like that work out? Both in theory and in practice.

38
44

hi James, where I work we integrate ‘real users’ into all our design processes.

Usually we’ll start the project with user research (often in the form of contextual interviewing), to make sure that what we’re designing is actually something that users want and/or need and to learn as much as we can beforehand about the problem and potential design solution.

Once we get designing we try to get users to come in and test our design work as early and as often as possible (this is more or less difficult depending on the project!). We’ll keep designing in between user testing sessions so that we can continue to refine the design as we go… rather than let half a dozen people tell us that something is broken.

Access to users and budget are obvious constraints so you’ll often have to be a little creative about who you can wrangle in to do some testing for you.

At any rate, getting eyes other than yours on the design as early and often as possible is incredibly important.

39
33

Great article! Definitely most designers would benefit from this type of arrangement, though i suspect the political will is often low to be unavoidably monitored by your peers.

Pair designing would be a testament to a good working environment/relationship generally! Incidentally my business is a partnership and though we work together well, we tend to assign design tasks individually where we are equally able to do it, rather than share in all tasks evenly. Horses for courses I suppose!

46
38

hi Ali… it’s interesting that you’ve described it as being ‘unavoidably monitored by your peers’. In a way, I think this is one of the great things about pair design – that you become a lot less ‘possessive’ about the design that you’re doing. It becomes a lot less subjective and personal and so it is easier and more enjoyable to share your work with others.

Also, because of the pair design work, you’ve had to be able to articulate the rationale for your work as you go – so if you have to explain why you’ve done something a particular way, you know what those reasons are, and they tend to be a lot more rigorous than if you’re designing solo and you just ‘know’ why you designed it that way… if you know what I mean.

For me, a great working environment for designers is when everyone is happy to put their work up on the wall and take questions and suggestions, but in reality, you don’t see that very often!

36
38

I do agree on all counts.

It is a consideration though, that sometimes there is nothing as annoying as advice at a point where i may not be ready to present it.

...or even worse, the glory-thief who sneaks up and ‘suggests’ the thing that you are so clearly about to do. OOO that makes me mad.

On days without lots of coffee though, sure ;)

39
34

yes, I hear what you’re saying, but I guess the difference with pair design is that you, individually, don’t own the design, two of you do.

And the methods that tend to be used in pair design are very rapid and low fidelity for the best part of the process, so there is no drama about presenting when you’re not ready.

I can relate to what you’re talking about tho’. It, perhaps, makes the case for pair design even stronger? :)

37
40

yes, I hear what you’re saying, but I guess the difference with pair design is that you, individually, don’t own the design, two of you do.

And the methods that tend to be used in pair design are very rapid and low fidelity for the best part of the process, so there is no drama about presenting when you’re not ready.

I can relate to what you’re talking about tho’. It, perhaps, makes the case for pair design even stronger? :)

40
45

I do agree on all counts.

It is a consideration though, that sometimes there is nothing as annoying as advice at a point where i may not be ready to present it.

...or even worse, the glory-thief who sneaks up and ‘suggests’ the thing that you are so clearly about to do. OOO that makes me mad.

On days without lots of coffee though, sure ;)

38
37

hi Ali… it’s interesting that you’ve described it as being ‘unavoidably monitored by your peers’. In a way, I think this is one of the great things about pair design – that you become a lot less ‘possessive’ about the design that you’re doing. It becomes a lot less subjective and personal and so it is easier and more enjoyable to share your work with others.

Also, because of the pair design work, you’ve had to be able to articulate the rationale for your work as you go – so if you have to explain why you’ve done something a particular way, you know what those reasons are, and they tend to be a lot more rigorous than if you’re designing solo and you just ‘know’ why you designed it that way… if you know what I mean.

For me, a great working environment for designers is when everyone is happy to put their work up on the wall and take questions and suggestions, but in reality, you don’t see that very often!

41
38

Great article! Definitely most designers would benefit from this type of arrangement, though i suspect the political will is often low to be unavoidably monitored by your peers.

Pair designing would be a testament to a good working environment/relationship generally! Incidentally my business is a partnership and though we work together well, we tend to assign design tasks individually where we are equally able to do it, rather than share in all tasks evenly. Horses for courses I suppose!

37
39

hi James, where I work we integrate ‘real users’ into all our design processes.

Usually we’ll start the project with user research (often in the form of contextual interviewing), to make sure that what we’re designing is actually something that users want and/or need and to learn as much as we can beforehand about the problem and potential design solution.

Once we get designing we try to get users to come in and test our design work as early and as often as possible (this is more or less difficult depending on the project!). We’ll keep designing in between user testing sessions so that we can continue to refine the design as we go… rather than let half a dozen people tell us that something is broken.

Access to users and budget are obvious constraints so you’ll often have to be a little creative about who you can wrangle in to do some testing for you.

At any rate, getting eyes other than yours on the design as early and often as possible is incredibly important.

37
45

Leisa you briefly mentioned the possibly of integrating ‘real users’ into the design process. Was this an abstract idea or does this actually happen. And if so, how exactly does something like that work out? Both in theory and in practice.

38
41

Hmmm… I’ll definitely keep those points in mind when managing my next project. Whilst we would usually assign two developers to work together on a development process, it’s rare that you would offer two designers to work together in union, rather than submitting “competing” designs

39
40

This is a great post and I would love to have this opportunity (alas I am the only web designer at my firm). What I have found useful is pairing with a developer who is going to implement some of the more advanced elements of the design (like Ajax). I have found that can work really well for many of the same reasons you address here – especially the explain as you go point.

39
40

hey Blaze, Actually what I’ve found is when you do pair design you tend to do a lot more design and a lot more detailed design on paper first, which is great.

Once you’ve solved all the big problems on paper, there are often logical ways that the work can be sectioned off and ‘realised’ electronically.

Usually once we get to the stage that we’re working on machines, the pair resource becomes more of a ‘review’ and QA process than an actual design process, although there’s obviously a lot finetuning and iteration that occurs at this stage.

By the time we get to a reasonably high fidelity prototype, all the work tends to be one one designer’s machine, but in the lead up each designer can work on sections of the design on their own computer… provided the work is well planned!

29
35

It’s an interesting way to look at it. Are you suggesting to have two designers work on one machine or two designers work side by side on 2 machines in a parallel fashion?

I have worked parallel with designers on many occasions and we found it hard to work on 2 machines to work towards getting a job done. It proved a bit troublesome & confusing.

I’d love to see if anyone has employed anything like this strategy because it really is something to consider for the future.