Home / Books / Pair Design
Pair Design
7/10

Pair Design

Gretchen Anderson and Christopher Noessel

Similar to pair programming, pair design is a way for designers to work together to deliver better results and faster. I’ve had the opportunity to pair design on several projects and I’ve enjoyed it every time. This book is a short guide for understanding pair design and how to get started in your organization.

Buy it

Key points

Highlights and notes

We’ve all been there: it’s time to review a design with some critical stakeholders, you’re prepared, you think you’ve got a great design, and you’re ready to hear feedback and move on to next steps. Except the feedback you’re getting isn’t about refining your great idea. Looking around the table, you realize that your stakeholders aren’t buying your design, because you haven’t addressed a key part of the business need. Or, you hadn’t considered another persona. Or, what you’ve done doesn’t agree with earlier work. Somehow, now that you’re here, you realize that you became lost in the weeds and didn’t focus enough on the big picture. And the part of the picture you did focus on? Well, your pitch isn’t quite landing and the design isn’t the great masterpiece you thought it was.

This happens to a lot of designers, not because they are bad at design, but simply because they are one person—one person working iteratively on a complex problem with a lot of different stakeholders.

One person can fall in love with an idea, and no one is there to point out its rough patches. One person can end up having to do a lot of information management with all of those stakeholders. One person can lose steam and not know where to turn.

This document talks about how pairing two designers can help alleviate these kinds of problems by separating strategic and tactical thinking in regard to a design challenge.

Pair design additionally gets to higher quality faster by providing continuous testing of ideas before they reach stakeholders, who can see mistakes as failures.

Pair design can make for better design output, but it also makes for happier designers.

By working in pairs with partners who share a common language and passion for giving the customer a voice, designers can develop a deeper practice, and build a stronger design culture.

Pair design is the counterintuitive practice of getting more and better UX design done by putting two designers together as thought partners to solve design problems.

The first thing to note about pair design is that it involves two brains on a project at the same time

Pair design really means being in the same room, working on the same problem, with both brains focused on the problem simultaneously for the duration of the project.

The second tenet of the practice is to have clear stances assigned to each designer.

One generates solutions. That is, one individual materializes solutions to the problem at hand for discussion and iteration. The other synthesizes the proposed solutions. In other words, they identify where the proposal is strong and where it needs improvement, connecting it to the problem statement and the goals of all involved parties; connecting it to decisions that have been made before.

The “Generator” role

In this role, the designer needs to be something of a maker, able to convey an idea clearly and quickly.

gens are generally comfortable drawing and drawing in front of their partner

Additionally, the generator needs to have “fearless generativity,” to be able to come up with a dozen pretty good solutions to a problem even with incomplete information. The person generating ideas needs to be egoless, able to put ideas out that are half baked, get feedback on those half-baked ideas (even to the extent of hearing, “Well, these are half baked.”) and iterating the ideas without taking any of it personally

Gens need to have lots of design patterns in their backpacks, ready to draw on at a moment’s notice, so they should be familiar with trends and outstanding examples from the field

The “Synthesizer” role

In this role, the designer acts as something of an analyst, able to test the design ideas as they are generated and keep the bigger picture in mind about what the design needs to do, what research and feedback has unearthed, and where the team needs to make progress.

The key skill is empathetic skepticism.

Synths give their feedback verbally to the generator, and the two of them discuss and debate the pros and cons on the fly, so they need to be quick on their feet.

designers in the synthesizer role need to be skilled at describing designs and explaining rationale in writing.

the synth needs to have dialectic skills, to keep discussions focused on iterating the designs and not the designers.

The role requires the designer to be detail oriented and have a strong memory, to keep the big picture of the system, stakeholders, and users in mind as a reference for designs on the table.

Synths need to have lots of first principles, heuristics, and business acumen ready to draw on at a moment’s notice, so they should be familiar with usability, psychology, and business practices.

Some teams stick to their role from the beginning of the project to the end. But in other teams, the roles shift back and forth.

For swapping teams, who does what can be a matter of how they’re feeling in the moment. “OK,” a designer doing generation might say, “I’ve just run out of steam. Do you want to take the pen for a while?” Similarly, a designer doing synthesis might speak up during a pause to say, “Hey, I have an idea that might help us out.”

If you opt to swap, it’s important that each designer knows what role to play in relation to the other. The team must take care to avoid situations in which both are trying to generate at the same time, resulting in a mine-versus-yours comparison in which the loudest voice or the highest-paid-opinion wins

When you come up with an idea, you come up with it for good reasons and are working with a built-in confirmation bias that tells you that your idea is good because it is yours

Until collaboration technology can catch up, it’s worth noting that pair design works best when the pair can be in the room together for the duration of the project. It gives the team deeply focused attention and the ability to read nuance in the team members’ body language and expressions

Research

As the pair researches the domain, the stakeholders, and users, the pair’s roles are quite similar. Both are there to come to a detailed and actionable understanding of the problems to be solved; the goals to address with the design. Any difference in roles here would be due to other factors

It’s important to ensure that one person is tasked with taking more literal notes, often acting as a transcriber of what was asked and what was said

At the same time, you’ll want to see some diagrams and drawings out of your research, as well: an overview of workflows, ecosystems, and relationships. Depending on the specific team members, one person might have more of an affinity to one of these roles over another. If not, being clear about who will do what is an important step

Wireframing

It is in wireframing where the roles become more distinct and their differences play out more formally

synth will often manage the design activities for the week and structure the tasks for the day

As the generator’s primary role is to generate design for review by the team, she will lead these activities. For each identified design problem, she draws an initial solution or even a set of possibilities. To do this she stands at a whiteboard (or, more commonly, sits at a digital whiteboard like OneNote) so that the proposed design is immediately visible

She talks over her design, voicing her thinking and rationale. The synth responds to the proposed designs, testing and challenging the design against the known requirements and patterns that have already been established in the design system

Often the person synthesizing helps the gen to remain at the right level of fidelity, neither staying too broad nor getting too wrapped up in microinteractions and detail. For example, when working through the overall structure of an app, it’s helpful not to get wrapped up in the layout of every page. Conversely, it can be helpful to have someone pushing the design toward details when it might be tempting to keep questioning first principles.

As they discuss identified problems, the gen will document key moments in the conversation, marking up the drawings and making new ones as needed. Capturing the conversation—including what was rejected—helps recount the team’s thought process to stakeholders

the synth keeps a shared document open to capture the final design decision and rationale, for sharing with developers and other team members.

In this stage, the synth will be in charge of producing the narrative, whereas the gen will be helping to illustrate with visuals.

High fidelity design

Because the gen and synth are doing “heads down” time during this phase, they might isolate themselves in separate spaces or with headphones. When design issues arise they will jump back into the same room and modes as during wireframing, working through the problem, and then when the question is answered or the issue resolved, returning to document the results

Presenting work

When we speak of pair design across a process, a few other common activities often come up: presentations, the creation of working prototypes, and gathering user feedback. For none of these is there a clear mandate for a strong gen/synth division of labor

We feel it’s important that the shared work of the pair can be conveyed by sharing the presentation equally. Neither the gen nor synth is a default presenter. This is not a hard-and-fast rule; and teams might want to adjust this for the seniority and comfort of the pair

it does not make sense to have someone synthesizing during the creation phases of a prototype, unless the team can work on it in parallel.

Pairing improves the quality of the design ideas.

Pairing forces constant iteration: idea testing and course correction

Pair design is not the same thing as just having two designers to work on a problem. By having someone tasked to generate and someone tasked to synthesize, you gain two vital perspectives on the problem

Someone is looking at it from the bottom up: does this microinteraction make sense in the context of the workflow? Someone is looking at it from the top down: are our design choices consistent with themselves and with the business goals? You have someone thinking of strategy, and someone thinking of tactics. Someone is caught up in the moment and someone is looking at the big picture. These two stances mean the choices must work strategically and tactically at every one of the thousands of interconnected decisions that make up a completed design.

Pair Design in orgs

Pairing improves the culture of design for teams and organizations.

Having two roles leaning on different strengths means hiring managers can abandon the quest for the “unicorn designer” who is wise and capable in all ways. It’s much more likely to find people with more focused aptitudes and pair them with another person who possesses complementary skills

The cross-pollination in this “square dance” makes for an organization that is continuously sharing and refining its best practices.

Each will have things to learn from the other, and working together as a community of practice of two will naturally have those effective techniques shared, practiced, and discussed

Pair designers keep design moving forward.

By having only one generator at a time—even if the role swaps back and forth between the pair—it means that an idea’s strengths and weaknesses can be thoroughly explored before considering a competing idea

It also helps remove the designer’s ego from the comparison of ideas. It’s not mine-against-yours, it’s ours.

Pair design encourages designers to materialize ideas early

For the synth to have something to respond to, the gen must put something in the world. This pressure means that teams must materialize their ideas quickly and continuously. This means they spend less time in the purely hypothetical, the details of which can be forgotten. The pair leaves a trail of materialized ideas as they iterate toward a buildable solution. This also gives a concrete stem to return to if it turns out a branch was not viable

Pair design encourages designers to vocalize their rationale

Because the pair begins work in low fidelity and iterates higher and higher, to engage in discussions about the design, the synth still needs to hear a description of what is being drawn and the rationale behind it. This pressures the gen to vocalize her thinking so that the synth can address it as well as what is drawn

Pair design encourages constant course-correction

If you’ve ever tried to bring a third party into a deep design problem, you know that the information overhead can be pretty steep. It can take 30 minutes to explain the domain, the strategy, the persona’s goals, the workflow, the step, and the microinteraction before you can get to the crux of the problem. The overhead can discourage feedback, and the longer you go between check-ins, the more you have to explain, and the greater risk the team will have gotten something wrong. By having the pair in the room looking at the same problem at the same time, the information overhead is dropped to zero and the course-correction is continuous, which enables free-flowing, constant, and confident iteration

People who practice pair design for a while find it difficult and counterproductive to return to working as “genius” designers, doing it all themselves in a slower, fault-prone, and isolated environment

Chris and Suzy swapped responsibilities back and forth, one leading the contextual inquiry sessions, building rapport and listening actively, while the other asked follow-up questions and focused on exhaustive notes.

with Chris running the sketching on a OneNote notebook while mirroring the tablet to a large monitor in the room, and Suzy testing ideas as they go using the personas, scenarios, business goals, and research findings (see Figure 1-2). As they worked through the problems, she led the definition of what’s central to the concept, and what influences it. What happens when a child is 7? 12? 17? What happens if we position this as aspirational instead of shameful?

Suzy opened their daily design sessions by reviewing what they had done previously, and identifying the user stories or “problems of the day” to focus on. The pair would run each one through a design/test loop in sketches for several hours in the morning, and often spend afternoons working solo to develop more detailed renderings, prototypes, or develop enough design rationale documentation for the next scrum meeting with the developer.

With so little information management overhead to deal with, the pair instead put energy into the storytelling of the design for their clients as they did the design, which saved them time and increased the rigor of what they shared with the client

Suzy maintained a list of what states and features were developed, and drove the development of presentation materials. During the presentation, Chris generally led the walkthrough of the scenarios, with Suzy framing the problem and leading facilitation of the client discussion.

At Pivotal Labs, the roles of generating ideas versus synthesizing information are called, respectively, “Driving” and “Navigating.” In this configuration, the designer using the computer is driving the design session, while the other is navigating—consulting notes, testing ideas, checking edge cases.

Because iteration happens between designers who have the authority to make critical decisions, pairing moves quickly

The constant switching of roles—driving versus navigating—is a key component of pair design at Pivotal. Although the switching happens regularly, it’s not a battle for the talking stick or one person correcting another. Instead, explains Michael, the switching is about balancing focus on details with longer range thinking. As one person is operating the drawing application or holding the whiteboard marker, the other person is testing the ideas

Another aspect of switching roles is that designers are constantly learning from each other. Maybe one designer is a stronger illustrator and can quickly render a complex visual idea. Maybe another designer has a 3D background and can bring some spatial awareness to the design solution. Or, in the case of Aaron and Michael, maybe they teach each other new tools that are useful to the task at hand.

Pair Design with a developer or remote

Dustin and Michael’s day-to-day responsibilities were very different, and literally working together, all day, for days was impractical. Instead, they worked in bursts. Dustin ran quick design sessions with Michael workshopping the ideas he’d developed the days before. Michael would review with an eye toward what his stakeholders would want to know, and they then developed surveys or A/B tests to gather the data to back a design decision. Rather than try to “play designer,” Michael says he focused on helping Dustin articulate his assumptions and then develop ways to test them using the site’s relatively heavy traffic.

They had mixed results at first. They discovered that each of them needed time and space to do their own research, Tracey into users and what they needed, and Ned into the backend systems and regulations for the system

As they continued through the design of the project, they learned that pairing worked in phases. These days, they collaborate for a few days upfront as they begin the design of any new area or module of the system. Then they break off to do their own design and development work, coming back together again as the sprints turn to the detailed development

Key traits critical to successful Pair Design:

For Those in the Generator Role

For Those in the Synthesizer Role

For Both Roles

To do great work as a pair, many of the agreements are about ensuring that both members of the pair feel psychological safety; that is, it is safe to take risks.

Attributes of an org with successful pair design

The organization must have a commitment to being a learning culture because pair design can take more resources than simply putting a solo designer on an Agile team

The organization must be quality-focused rather than focused on “shipping” because pair design principally offers major gains in design quality

The organization must be customer-focused

The organization can’t be too vested in its hierarchy or silos

The organization must be committed to psychological safety for its teams

I’m management, how should I implement pair design in my organization? Our recommendation would not be to simply pull a lever and switch the entire organization to pair design. It would be too much chaos. It’s better to start small. Find the “genniest” designer you can and pair her with the “synthiest,” have them work through a few projects as a pair to see how it goes, evolve a process that works for your organization, smooth out the wrinkles, and become resident experts. Then, split them up, assign them with new pairs, and begin to spread.