agile ux · information architecture · interaction design · UCD process

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, in theory and as a relative outsider to the code writing process, it would be a great approach to development. I’ve never worked on a project where there was budget or resource available for pair programming though.

In the past 12 months or so, practitioners of the various design disciplines that I’m interested in have been talking more and more about agile methodologies and how they might apply to design processes. There’s been a lot of talk of collaborative design and rapid iteration, but I’ve not seen anyone talking much about ‘pair designing’.

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, however, quite rare.

I’ve been fortunate enough to work on a few projects where we’ve taken a ‘pair design’ approach (in fact, I’m working on one right now), 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. (Hey, none of us know everything, do we!)
  • Team cohesion. People get to know each other more quickly when pair programming. Pair programming may encourage team gelling. Yep. 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!

12 thoughts on “pair design pays dividends

  1. Leisa,

    I have been called a process freak more than once, and have an interest in agile designing as such.
    Here’s my question: I know Agile methodologies are usually document-averse. How would you see pair-designers deal with documenting the design? Is that a co-operative effort as well (or is it one of the distractions you sepak about ;-))?

  2. hey Peter,

    I was skeptical about Agile methodologies for this reason for a while, but I’ve come to realise that, in my case at least, the prototype becomes the new document. But, there is still documentation.

    The way I’ve been working lately is to do initial design on paper (flip chart with extensive use of post it notes) which is then transferred to Visio wireframes (of reasonably fidelity), that are then outputted as GIF and imported into Dreamweaver where hotspots are applied and a prototype is quickly developed. Then we can do lots of testing/research and rapid iteration until we get to a design that’s actually doing it’s job.

    There’s lots of scope (and reason) for capturing specifications etc in the Visio document, just make sure it’s on a seperate layer so you can switch it off to output the gifs for the prototype, and switch it on for printing.

    For the project I’ve described here, documentation will be really important because we have three development teams working on this – each of which are more or less remote from each other. We need to document as much as possible to reduce miscommunication and misunderstanding between the teams.

    Now, is this actually a pair design activity? I think it can be, but it depends on how much time you have. I think it would be ideal, but in reality I’ve found that you tend to split the project up into sections and each designer does most of the documentation on that particular part of the project, then someone pulls it all back in together.

    I’ve found this is where the ‘weak spots’ in the interaction tend to creep in. In my ideal design environment. you’d do all of the documentation in a pair environment as well.

    (yeah, i know. sounds bizarre. I never thought I’d be saying this either!)

  3. (first of all: thanks for the quick reply!)

    So the protoype becomes the specification, eh? I know that works great with clients who need to see it working before they can sign off, but I also know that next to the prototype that specifies *some* of the interactions, you always need a set of descriptions for the other/edge cases. So there’s also a Visio document next to the prototype. (And then you need to update two parts when a specification changes, ugh!) But I agree that for the more-and-more highly interactive (yes: AJAX-y) systems we’re working on, a prototype which shows some of the interactions in real life, is the way to go.

    As for creating early prototypes straight from Visio, can I point you to Swipr ( It has some nifty macro’s in the shapesheet that allow you to automate the steps you describe (export, import, add hotspots, create prototype in HTML). Have a look at the sample files, convince yourself of the advantages, and say “hi!” to Jacco when you register to download the templates :-)

    As for pair-documenting, when you say “I think it can be, but it depends on how much time you have” you make it sound like you think it takes more time to pair-document, is that true? Because I am sure others will have said the same about pair-designing, and still you, or at least the Agile people, are convinced that it’s faster to pair-design…

    I think a less-Agile approach, where documenting is an instantaneous part of the design process (and not an end-of-iteration, or worse: end-of-phase activity), would work better for pair-designers. And I am still not sure if it beats the more traditional design-review approach, where a (senior) designer reviews the work of the main designer every now and then, after having agreed on the activities and deliverables.

    One last question: what does your documentation look like? You mentioned annotations in (a separate layer of) the Visio file. Is there more?

    (FYI: I am considering submitting a proposal for a panel about IA processes to the IA Summit, and am interested in hearing about people’s experience with documented IA processes and deliverables)

  4. Menlo Innovations ( uses paired design, which they call High Tech Anthropology, as a part of their agile methodologies. Much like with extreme programming, the designers rotate through the current projects so that the knowledge base for the design is distributed and so that multiple perspectives are incorporated. The flow of the process does definitely depend on who you’re paired with, and is impacted by personality as much as by IxD experience.

  5. hey Todd (Sorry, late reply!)

    This sounds like an interesting methodology… I can definitely imagine that results vary depending on who you’re paired with. Do we know how often the designers rotate projects? Is their assignment time based (eg. you work on this for six weeks) or outcomes based (Eg. you design this process then you rotate). I guess it would have to be time based.

    It’s interesting that they call it High Tech Anthropology. Why anthropology I wonder? It doesn’t sound like anthropology as I understand it!

  6. Hi Leisa,

    Their rotation speed depends on how many designers they have in house at the time. Everyone there is a subcontractor so they sometimes get into crunches where each designer will be working on 2 different projects each day, and may hit 3 or 4 projects in a week. They use an agile project management methodology, so each subtask (e.g. design a screen, create a process flow, create use cases) is written on a card which gets a time estimate. Basically, the designers are assigned to a project for a day or half a day and work on however many cards they can get done during that time. They will usually try to finish a card before rotating out, but if a card is taking longer than anticipated it’s possible that a new designer will rotate on and finish a card that was started by someone else. There is some inefficiency introduced because the new person has to be brought up to speed on the particular card, and sometimes the project as a whole, before work on the card can proceed. But usually it works out ok.

    The High-Tech Anthropology (HTA) is a part marketing voodoo but mostly refers to their contextual inquiry/observation process they do before working on the design, and the contextual prototype testing they do.

  7. You wrote this a loooooooong time ago, I’ve only just started considering it, and I wondered if any of your views have changed.

    “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.”

    Inside my company all I have are non-designers, but I think there has to be value in getting them involved, if only to help my thought process and come up with some new ideas.

    However, I’m slightly worried about them being too worried about the ‘blank piece of paper’, and me riding over their ideas if they don’t make sense from an interaction point of view and ending up where I would’ve been in the first place.

    Hmm, seems like something I’ll just have to try and see.

    Because I work in a small company, the more I can spread the load, the more can get done, but I guess it’ll be a gradual process as people get up and running with it.

    Just thinking out loud really, I’ll let you know how it goes. :¬)

    1. I do a lot of design work with non-designers, but it’s not really ‘pair design’ work, and more about facilitating conversations around the product that are more effectively achieved using ‘design’ as a framework. It sounds to me as though you’re trying to cross-skill/up-skill non-designers, in which case pair design might be something worth considering. I do stand by my view of not wanting to pair design on project work with someone who is new to design but that’s more a product of the type of agency/freelance work that I do where projects can’t bear the time/cost involved.

      You’re in a somewhat different situation, being in-house, so in that case, it is possibly something worth considering because you get real long-term value from the time you’re investing.

      I’d love to hear how you go with this, and where you start (with developers or product people, for example?) and sing out if you want to knock some ideas around.

      (btw: it was nice to be reminded of this post and the great experience I had that prompted me to write it!)

Comments are closed.