The Nuts and Bolts of Pair Designing at AppNexus

Article two in a series on Pair Design at AppNexus

My team has been Pair Designing for about two quarters now, and it’s been productive fun. We were inspired when we read a few articles on the Cooper blog (Pair Design and the Power of Thought Partnership, Better Together, and Design Loneliness). As social people, the idea of having people working in pairs made sense to us. Over the past six months we’ve worked on the nuts and bolts of how it fits into our own design process.

I can’t draw people, so I drew pears instead. Each pear is a point person for a few teams

Our structure is a bit different from Cooper’s since we’re part of an in-house design team. Each designer is a point person for one or more scrum teams. The point person’s job is to sync with their scrum team members and field any day-to-day questions or create any mocks that are required. They usually work closely with product managers, developers and documentation writers.

Usually the product manager explains goals as well as explains any business requirements

New projects start with both designers meeting with the product manager to get a clear understanding of project goals, time line and other context. If we are doing ethnographic research we do it together because it allows the designers to create a shared understanding of the user. We’ve found that if one designer knows something and the other does not the design process becomes one-sided. Knowledge about the user is a source of power, make sure both designers are equals.

Once we have the project and have conducted research we can start designing. You can read more about some of the general meeting structure in my article about remote pair designing. The summary is that we have video meetings, where at least one person is in front of a white board. While designing we stick to four rules:

  1. There are two roles: generator (gen) and synthesiser (synth). The gen is the person with the pen in the room who is sketching ideas. The synth’s main role is pointing out things that work well and things that might not, tying design ideas back to business needs, and referencing the user needs. We tend to switch back and fourth quite a bit. At any time we try to make it explicit which role we’re taking by saying things like “let me gen for a minute.” The two roles means each designer knows what to focus on at any times.
  2. One pencil in the room. This means that only one person can be drawing at a time. We’ve found that this helps ensure that each idea gets the attention it deserves
  3. Shared Ownership. At no point should one designer be able to say “this is my idea.” To keep shared ownership both designers always work on ideas together. We try to avoid coming back to the pair with an idea sketched out much further than it takes to record it. Shared ownership helps prevent a sense of competition where one user wants “their” idea to win, instead of the best idea.
  4. Use Personas. The designers should never say “I don’t like this”. Everything should be spoken in terms of the personas to minimise subjective opinions and help keep the focus on the user.
Some designs take many pair designing sessions before we get them right.

The process of designing usually takes multiple sessions lasting at least an hour. As the project progresses the point person will frequently reach out to product managers and developers to get feedback. They are then responsible for bringing back feedback or other challenges. For example, if a developer discovers that a design will be much more difficult to implement than she thought, we will often work on how to balance that with design needs. At the same time we sync with the researcher to conduct ongoing usability testing. We both sit in on this so we see exactly what did and did not work.

No process is flawless — there is no Beyonce of design processes. To keep improving we borrow from the agile development methodology. There is a meeting called a retrospective, where people bring up things that didn’t work for them in the last period of time. It can be anything from technologies not working, processes being slow, or minor irks. We’ve tried to replicate this by conducting pair design retros each quarter. Ahead of the retro we each write down things that we think are working well, things that aren’t, new ideas to try, and anything that we think is hampering our productivity. We’ve used this to change the way we track our progress, change file naming conventions, and refine the ‘point person’s role.

Our process is ever evolving, so this has just been a snapshot in time. Are you an in-house designer trying Pair Design? How has it worked for you?

Product Design at Spotify. Patron saint of emojis.

Product Design at Spotify. Patron saint of emojis.