Allaland

Pair Design

Posted on: January 11, 2010

Having recently worked at a few companies that are fully agile, meaning both design and development follow agile, versus just development. I have really come to understand the benefits of agile, and you might say, am definitely drinking the agile cool-aid.

One of the things that I like best about agile is the notion of pair programming. I have often watched a pair of developers work together on a bit of code, and was silently jealous because I wished I could have a partner for design! In all of the places that I have worked – even if there is a design department – only one designer gets assigned to a project (unless it is extremely large). So the designers rarely get to work in a team, and are often isolated within their individual projects.

I think perhaps that its time for the design industry to take a cue from agile development and consider pair design.

Let’s take a step back and look at why pair programming works? From Wikipedia, here is a list of benefits for pair programming:

  • Design quality: Shorter programs, better designs, fewer bugs.Program code must be readable to both partners, not just the driver, in order to be checked in. Pairs typically consider more design alternatives than programmers working solo, and arrive at simpler, more-maintainable designs, as well as catch design defects very early.
  • Reduced cost of development: With bugs being a particularly expensive part of software development, especially if they’re caught late in the development process, the large reduction in defect rate due to pair programming can significantly reduce software development costs.
  • Learning and training: Knowledge passes easily between pair programmers: they share knowledge of the specifics of the system, and they pick up programming techniques from each other as they work.New hires quickly pick up the practices of the team through pairing.
  • Overcoming difficult problems: Pairs often find that seemingly “impossible” problems become easy or even quick, or at least possible, to solve when they work together.
  • Improved morale: Programmers report greater joy in their work and greater confidence that their work is correct.
  • Decreased management risk: Since knowledge of the system is shared among programmers, there is less risk to management if one programmer leaves the team.
  • Increased discipline and better time management: Programmers are less likely to skip writing unit tests, spend time web-surfing or on personal email,or other violations of discipline, when they are working with a pair partner. The pair partner “keeps them honest”.
  • 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.
  • Fewer interruptions: People are more reluctant to interrupt a pair than they are to interrupt someone working alone.
  • Decreased risk of RSI: The risk of repetitive stress injury is significantly reduced, since each programmer is using a keyboard and mouse approximately half the time they were before.

The list above can easily be viewed from a designers perspective:

  • Design quality: Pairs typically consider more design alternatives than designers working solo, and arrive at simpler, more-maintainable designs, as well as catch design defects or usability problems very early.
  • Reduced cost of redesign: With design flaws or usability problems being particularly expensive, especially if they’re caught late in the product development process, the large reduction in flaws can significantly reduce costs. Furthermore, having a pair of designers explain the reasoning behind a design is much more powerful and convincing, and may lead stakeholders to request less redesign.
  • Learning and training: Knowledge passes easily between pair designers: they share knowledge of the specifics of the system and domain, and they pick up design techniques from each other as they work.New hires quickly pick up the practices of the team through pairing.
  • Overcoming difficult problems: Pairs often find that seemingly “impossible” problems become easy or even quick, or at least possible, to solve when they work together.
  • Improved morale: Designers report greater joy in their work and greater confidence that their work is correct.
  • Decreased management risk: Since knowledge of the system is shared among designers, there is less risk to management if one designers leaves the team.
  • Increased discipline and better time management: Designers are less likely to spend time web-surfing, tweeting,or on personal email,or other violations of discipline, when they are working with a pair partner. The pair partner “keeps them honest”.
  • Resilient flow. Pairing leads to a different kind of flow than designing 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 designer deals with the interruption while the other keeps working.
  • Fewer interruptions: People are more reluctant to interrupt a pair than they are to interrupt someone working alone.
  • Decreased risk of RSI: The risk of repetitive stress injury is significantly reduced, since each designer is using a keyboard and mouse approximately half the time they were before.

Pair design, think about it!

Advertisements

2 Responses to "Pair Design"

Hi there,

Cooper has long practiced pair design, and I’ve always thought it was a great way where one could mesh IxD practices with Agile development practices. Pair design at Cooper combines a more generatively-oriented designer with a more synthesizing-oriented design. The two are a powerful pair and I always loved the camraderie and opportunity to talk through problems and solutions.

All of the benefits you describe above were experienced by me to some extent. At Cooper, though, the designers split up digital production chores so RSI risk wasn’t reduced. That was the point at which the generative designer focused on visual production while the synthesizer worked on text-oriented documentation, both pushing around Adobe creative products. Generally, too, the dynamic and dialectic between the two parties led to more rapid conceptual iteration.

I wish more people & companies practiced pair design! Especially for mentoring and knowledge transfer, nothing finer. It brings back the apprentice/journeyman/master model to some extent, too.

Cheers,
Liz

Hi,

We’ve been practicing pair design for several years now, and find it works very well. For us design is cooperative and social, and we find that the work we produce in pairs is much better than going it alone. There are three of us on the design team, so the pairs get mixed up for each project, which keeps it interesting. I’d also agree that the process is quicker, as you generate ideas and feed off of each other during design sessions.

Have fun,

Kristen

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Alla Zollers

I design products and services that just. make. sense.

When products make sense, customers are happy.

If customer are happy, they sign-up, stay on site, engage, share, and buy your product or service.

Happy customers allow companies to profit in both senses of the word.

I provide the following services:

• Heuristic Evaluations
• Discovery Research
• Strategy and Vision Development
• Information Architecture
• User Experience Design
• Usability Testing

You can find me on:
Twitter
LinkedIn

Twitter Updates

Archives

%d bloggers like this: