Pair design

Working Together, Closely

The first thing to note about pair design is that it involves two brains on a project at the same time. This doesn’t mean part time, checking in with each other on work that’s been accomplished separately. This methodology is more properly called a feedback relationship, and even though it’s certainly better than nothing, it doesn’t achieve the benefits that we’ll be discussing. 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. This is central to the practice because it reduces the communication overhead of a design team, allowing higher quality design with less documentation. We’ll get more specific on how this plays out across phases of a project in the next section, but for now this is a good place to begin.

Two Defined Stances

The second tenet of the practice is to have clear stances assigned to each designer. These need not be binding forever, as we will see, but each person in the pair takes a distinct and complementary stance toward the design problem as they work together. 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. Because of these default stances, at Cooper these roles are even named. The former is the generator, or gen, and the latter the synthesizer, or synth.

Aren’t These Just Tasks?

Can a single designer just take on generating and synthesizing as tasks to be done? Does it need to be two people? Possibly, but it’s not easy. 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. Synthing your own work fairly takes some superhuman capabilities to overcome that bias. And your experience as an individual might not be as equipped to provide a counterexample as another person with an entirely different set of experiences. So, maybe, kind of, good luck with that?

Can a team simultaneously generate and then swap to simultaneously synthesize its work, to help overcome the confirmation bias? It’s similarly difficult. First, there are the problems mentioned earlier, where the loudest voice or most senior employee wins. Additionally, if someone must cross the threshold from generation to synthesis, and that transition can carry an implication that because someone felt the need to swap, the design must be bad and need fixing. That can raise the defenses of the generator. When it’s one person’s default stance, they’re not being bad by switching to synthesis and criticism. That’s what’s expected because that’s the value they are asked to bring.

Those cautions aside, yes, some individuals and some teams have managed it, but for the reasons discussed, be aware that it’s not a beginner skill.

(You might be interested to know that this issue—whether roles are better if assigned or adopted on an as-needed basis—was probably the biggest point of discussion between the authors and our reviewers. So, be aware that there are widely varying opinions on this point.)

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. That individual can focus on real-time tagging of her notes; such as challenges that were mentioned, pain points that were felt, or workarounds the interviewee has developed. 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.

Analysis and Sensemaking

After completing research, user-centered designers undertake sensemaking efforts: that is, formalizing what was learned across research, crafting communications of these findings back to stakeholders, and building the tools that will facilitate design in subsequent phases.

The person synthesizing is tasked with building a big picture in his head in which to frame the design efforts. He will often take a lead in facilitating the sensemaking activities. He might posit some initial questions to frame analysis of the notes, and often takes the lead in drafting personas and scenarios. The person who was focused on literal note-taking will also be a good source for verbatim quotes that illustrate key concepts in users’ actual voices. Gens will reference their notes to participate in making sense of research and co-create the tools needed to make great software happen.

Detailed Design

It takes more than interaction design to get a product out the door. While the pair of interaction designers has been hammering away at the workflows and interface decisions, other teammates will be resolving related issues such as industrial, branding, and visual design. Let us call the activities of all of these coming together in the final product detailed design. (Acknowledging that it is usually a messier picture than this description presents.)

Efforts in detailed design are often around making the messy designs-in-progress cleaner and clearer for quick review by stakeholders but mostly more understandable for sharing with developers. In this stage, the synth will be in charge of producing the narrative, whereas the gen will be helping to illustrate with visuals.

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.

Other Common Activities

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, but there are a few notes about how gens and synths handle them having done other work as a pair.

It Makes for Better Design

Pairing improves the quality of the design ideas.

It Makes for Better Designers and Better Design Organizations

Pairing improves the culture of design for teams and organizations.

Pair Design Makes for a More Effective Process

Pair designers keep design moving forward.

In Short…

Between being happier, producing better work, and being more effective, pair design offers a lot to the designers and the organizations that choose to work this way. 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.

This is so true that there is a legend at Cooper of one team who found pairing with each other so powerful and fruitful that when they left that company, they sought out opportunities and even interviewed at other organizations as a pair. It really is a powerful shift in how we get great design done.

Cooper: Pair-Designing an App

Christopher Noessel and Suzy Thompson are two designers who have worked as a team for six years and have established roles and methods with which they are quite comfortable. When they designed Kurbo, an app for kids to support healthy eating (see Figure 1-2), Chris played the role of generator on the team while Suzy served as the synth. Because of their long history together, they maintained those roles consistently as they worked together, rather than switching, as we will see in the next case study.

The Cooper team began the research stage together conducting contextual interviews with families. During this stage, 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. They tended to be intuitive about deriving big patterns and insights quickly and upfront. After each session and in informal discussions about the research, they each shared their impressions; as Chris describes it, “find the big rocks first” in the research, because both people are present for the same sessions, consistently. The details can be then pored through to test hypotheses quickly.

It was during one of these informal sessions that their biggest, hidden challenge emerged—kids don’t make their food choices in a vacuum, their parents, friends, and environment have a big impact on them. This led them into a phase in which they developed scenarios and interaction frameworks for the app. During this stage, the pair used a dedicated room, 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?

On a typical day, Chris in turn, sketched out different approaches to these challenges, side by side on his canvas. After they had a set of interaction frameworks that addressed different challenges, Suzy began leading an evaluation of each one against their personas and scenarios, quickly tossing out ideas that didn’t work or scale, identifying unique versus pedestrian solutions. Together they iterated the design to ensure that it met the goals of the personas, their friends and family, and the businesses paying to develop the app.

As the framework solidified, the pair then moved into a more detailed design phase. During this stage, 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. As a review approached, 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.

The Kurbo app launched in 2015 and won an award at the Interactions16 conference, serving as a good example of how a very structured team can do pair design over the course of a three-month, intense project. The team from Cooper pointed out that the support they received from the organization is a big part of the success of the project and the team.

Across different organizations and industries, design teams and organizations look very different, and it turns out there are many ways to put pair design into practice. To understand how pair design might look differently, let’s look at how other teams practice pair design between designers, and cross-functionally.

Pivotal Labs: Pair Design with a Client

As at Cooper, pairing is the status quo at Pivotal. Pivotal was an early adopter of pair programming and pioneered pairing-up designers, and pairing designers with developers. Regularly, two designers on a team are dedicated to a design problem for the duration of a project, and pair programming is a natural mode for engineers. Pivotal makes its own products as well as acting as consultants for clients, and pairs function in either setting. Sometimes, the second designer on the team is a designer from the client’s organization.

When Aaron, a lead designer at Pivotal, began the design session we observed, he introduced Michael as his design partner. Michael sat on a tall stool at a high table, and Aaron stood next to him. They shared a monitor, and each had a mouse and keyboard, much like traditional pair programming, except rather than looking at code, they were looking at a design sketch. 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. It’s only at the end of the session that we observed when Aaron explained that Michael was actually their client who was embedded at Pivotal to guide the design, learn how to pair, and build his knowledge of the design system overall.

The two designers were working through a complicated enrollment flow for a new solar energy provider. Clearly, there were lots of details that needed to be worked through, but they understood what problem to solve and were very focused on it. They decided that the process would benefit from adding a step and were working through the interactions in that step. Michael had a prototype up and was pulling together elements from the style guide to create the new step. Aaron was looking at notes and highlighting any missing pieces of information. They took a step back to look at the previous 10 minutes of work. Even though all of the pieces were there, it was clear that users would need a new element to indicate progress in the flow.

Aaron had an idea for an icon, and he grabbed the keyboard to begin illustrating it, pulled in an existing brand element, and quickly cleaned up the layout of the section. They discussed it for a few minutes, identifying a few other approaches they could try, as well. The discussion turned to how the interaction would animate and behave in space, and hands started waving. Then, Michael whipped open Flinto, a simple animation tool, and showed Aaron how it worked. After 20 minutes they had designed the flow, tested it against the product manager’s requirements, and created a simple prototype. 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. Does it scale appropriately? Is it consistent with design patterns elsewhere? Does it bring up issues that the client or product manager will need to think through? How can it be tested?

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.

GreatSchools: The Life of the Designer–Product Manager Pair

GreatSchools is a national nonprofit that helps America’s K–12 families research schools every year with their website, as shown in Figure 1-3. Michael, a senior product manager, and Dustin, a senior UX designer, didn’t have a lot of experience working together, or in pairs of any kind when they started a project to redesign Community Reviews of schools, which are a key part of the site.

The site began in 1999, and like many sites of that vintage, it had been undergoing a longer-term migration to new core technology. As a result, it was difficult for the team to make assumptions about how the backend systems and processes would or should work. Michael, as the product manager for the new platform, was best poised to help Dustin work through the ambiguity. At the same time, because the system was evolving, there was an opportunity to change systems and processes for the better. However, because reviews are so central to the organization’s operations, it needed to match or beat certain metrics of success to be viable. The two decided that if they worked closely together, they could more quickly understand the implications of different designs for both the users, the business, and the system itself.

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.

With such a key part of the site up for redesign, they knew that key stakeholders and funders would need to be managed closely and ideas presented clearly, or risk a “kitchen sink” design solution for the minimum viable product (MVP). As they learned what worked and didn’t work for users from their research, Dustin says he also began to understand how his work affected marketing, search rankings, and more. Rather than teaching each other design tools or illustration tricks, Dustin was gaining wider knowledge of the core business at hand. Michael in turn, used their research when presenting their work to the stakeholders to justify their design decisions.

Because the problem was complex, and they needed others to fully appreciate the extent of changes they were about to make, they decided to extend their experience of pairing together to working with other teams. So they began a journey of embedding team members from marketing, editorial, and operations, one or two at a time, into their project for a half a day. These sessions were less about co-creating design and more about taking time to educate different factions about what they had learned and the data they had gathered.

In the end, Dustin says they ended up with a design that maintained a simplicity that was critical to users and met the complex business objectives in record time. By having a product manager as a partner, his design ideas were paired with evidence of successes—from usability findings, to A/B test findings, to engagement metrics that are critical for the organization at large. He found the debates about design elements to be less subjective, and even if it took time to educate other colleagues and funders, that was less time spent defending ideas.

Lab Zero: The Life of the Designer–Developer Pair

Tracey Thompson has been a UX and Visual Designer at Lab Zero, a design and engineering studio in San Francisco, since 2010. Tracey and Ned Holets, a lead software engineer with Lab Zero, have been pairing together as a designer-developer team for the past three years on two large-scale, long-term projects. It began informally—two colleagues in close proximity (their desks adjoin) who began to consult each other on a regular basis as they were working.

They both recall when they realized how pairing together more formally could really change both the process and outcome of their projects. While working on a website to support a PR event, they were facing a tight deadline. They inevitably ended up working some long days, and even some nights to make sure the site was ready for the event. The site design was very high-touch with lots of animation, transitions, and complicated timing issues. Sitting side-by-side, it was easier to refine details quickly, deciding that what was originally specified was quite right. Tracey says she felt like she could better craft the details she knew mattered most to the user interface (UI), having access to a live prototype from which to learn. As some long days grew even longer, they were able to remote pair in the evenings, using a screen-sharing tool, Screen Hero (see Figure 1-4). Although they don’t tend to work under pressure like that as much, the partnership they forged continues today on a much different project.

For the past two years, Tracey and Ned have been designing and developing a system for a large commercial bank with many older databases and existing code for a client whose expertise is in many things besides design and technology. Coming off of their successful pairing on the PR website project, they decided to formalize their partnership up front and continue their close collaboration on the new project.

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 Ned put it, “I need to get a full picture of the system, and I don’t want to kill ideas about the design early on by thinking too much about feasibility.” At the same time, Ned felt that coming together around the implications of each of their research bore a lot of fruit. Rather than being on the receiving end of a fully developed idea, he and Tracey spent time working through the highest-level concepts for the system and each of them could better develop ideas that took advantage of constraints, rather than avoiding them.

Tracey describes one of their first meetings, for which she brought in her research and she began sketching out different concepts and models for the site. She knew that users needed to get a view of their data that was spread across several different services. And Ned knew that calling on all of that data simultaneously was unlikely to be performant, but he also appreciated the user need that Tracey was addressing. Over the course of the design session, they developed an asynchronous approach to the problem that delivered what would satisfy users, in just a slightly different way. This breakthrough turned out to pay dividends over the life of the project because the core concepts and system architecture are designed to scale together.

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 stages. This flow echoes what happens with designers and other stakeholders who come together and break apart as the ideas diverge and converge.

Ned says this is actually reflective of how pairing works in pair programming. “The myth of pair programming is that you’re doing everything in lock step, but I’ve found that when big breakthroughs happen, engineers break up and work independently on the details.” And Tracey adds that through pairing, she’s become more technical, and there are times when “no one needs to watch me tweak CSS all day.” What’s clear is that by having the ability to work closely together, even across different skill sets, has great value at times. And when it doesn’t pay off, they have learned to maintain communication, while not being joined at the hip.

As this case study shows, designer–developer pairing has many similarities to designer–designer pairing but takes advantage of the more varied skill sets of each partner. By increasing the frequency of communication, Tracey and Ned were able to better understand each other and avoid some of the pitfalls that happen when designers see developers as more distant partners who simply execute the design.

What Makes a Successful Pair Design Team?

Until this point, we’ve shown how pair design works and how it can be practiced in a variety of ways. And we’ve shown how it can support a variety of skill sets and approaches. For some, pair design can be challenging, and presents an opportunity for designers who struggle to work in real time with a partner to grow some new skills. Across the teams we interviewed, certain key traits emerged as critical to this practice:

Diversity of backgrounds and complementary skills

The individuals within a team are each T shaped, with deep competency in different areas. Although this is not exclusive to pair design, it’s useful to note that pairing two very similar people can backfire as they struggle to hold roles and space for each other.

Quick thinking and strong verbal skills

Being able to talk through ideas in real time is critical to this practice. One criticism that could be made is that those who aren’t native speakers of the dominant language might be at a disadvantage in an environment that is explicitly about efficient verbal communication over more deliberate approaches.

Multistate thinkers who can improvise

The ability to keep a multistate system in mind is critical when evaluating and describing ideas with a partner. Teams often develop a shorthand for communicating complexity as a way to move quickly, but then they must be able to transition into a mode where they can communicate that complexity to outsiders.

Ability to think long- and short-term

A key benefit of pairing is the constant testing of solutions against edge cases and details, without losing track of the bigger vision and project plan. For anyone who will hold the synthesizer role, this skill is critical. Even though all good designers should have this ability, having a dedicated partner helps support this. When practicing solo, it can be difficult to shift your own perspective easily.

Ability to think systemically and in the instance

Interaction design is systems work. Most good designers have the ability to keep a complex multistate system in their heads as they work through details. When designers are paired, the team’s capacity to manage the whole system increases. Having one partner explicitly be the “navigator” (versus the “driver” in the Pivotal parlance) helps the team consistently test the system and avoid creating new design patterns unintentionally.

The Agreements That Underlie Successful Teams

To operate effectively, pairs must make and stick to agreements about how it is that they should work together. Though this is negotiated idiosyncratically by every pair, there are some ground rules to get started.

For Those in the Generator Role

These principles help those fearlessly generating ideas be a good partner.

• I will show before I tell

  I understand my role is to visualize the conversation in progress. This includes drawings that illustrate the design, but also that illustrate the conversation around it and the decisions that the team has made. I will not erase or delete drawings, so we can review discarded ideas—and the reasons they were discarded—when stakeholders raise them in the future as possibilities. I will accept reminders to visualize when I get too wordy with ideas.

• I won’t let my ego get in the way

  I am putting my ideas out into the world expressly so that they can be critiqued. I will not take this personally or defend my ideas just because they are mine. The discussion is not about me or my merits as a designer, it is about the best design.

  Nor will I engage in any “scorekeeping.” In a given session, if five of my ideas are found wanting, it does not mean I am “owed” a pass on five other ideas. I will acknowledge my feelings of defeat when I feel them and work to move past them.

For Those in the Synthesizer Role

These principles help those nurturing ideas to be an empathetic skeptic.

• I will be specific in my critiques

  I will acknowledge my “spidey-sense” that tells me when something is wrong about a suggestion and share it with my pair. But if I can’t explain why it is wrong, I will table that feeling so that the design can move forward. I reserve the right to return to the issue if I am able later to articulate a counterargument. I understand that if that counterargument comes too late in the process, we might not have time to make the implied changes in the current project or phase.

• I will build not block

  Knowing that ideas are being put into the world to be critiqued, I will work to keep that criticism constructive. I will not simply say, “No, this is not good enough” and expect my gen to produce something new until I am satisfied. I will explicate the problems that I see earnestly and clearly, and work with my pair to identify what is good about the design, and nurture a solution to identified problems.

For Both

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.

• We trust each other

  It’s a lot of cognitive work to constantly wonder if your partner has ulterior motives, and distrust becomes a self-fulfilling prophecy. For this reason, pairs agree to give each other the benefit of the doubt. We presume good intentions in the absence of evidence.

• We mutually respect each other

  Part of what you trust is that your thought partner respects you. Any criticism or defense brought to bear is about the design we are creating together, not an attack against you personally. Even when things get heated, it’s driven by a passion to create the best design for our stakeholders.

• We will participate in healthy debate

  It is never about being “right,” it is about what gets us to the best design. This means we are forthright and honest in our conversations, use fair tactics, help each other avoid logical fallacies, are mutually open to being persuaded, and are honest if you are convinced.

• We will be deliberate about our relationship

  It’s not enough to make these promises at the beginning and then fall back to old habits. Teams promise to take time out of the schedule to look at the relationship, appreciate what is working, and course-correct things that aren’t.

• Ideas can come from anywhere, but there will be no dueling whiteboards

  Though the gen is responsible for producing ideas for consideration, the team should take advantage of any good ideas, regardless of where they come from. This includes the synth of course, but also developers, stakeholders, users, and coworkers can all have great ideas for how to solve design problems. When one is presented in the room, though, it will be thought through as thoroughly as we can before introducing another idea from someone else, to avoid a competition of egos.

• We will defer to tie-breakers

  To ensure that the project keeps going, we agree to a time limit for being stuck. If after 15 minutes neither of the pair can convince the other on a particular issue, we agree to get another person in the room to whom we can explain the issue neutrally, favoring neither side.

• We will respect the design process

  When receiving feedback, we agree not to try and solve problems that are identified, live before the stakeholder, unless explicitly asked to. This is to ensure that problems are considered carefully and by the team in the same deliberative, acid-tested process pair design is meant to foster.

What Pair Design Needs from an Organization

Some other considerations for designers considering pairing: the teams that we spoke with all recognized that some element of the success of pair had to do with the culture of the organization as a whole. Our interviewees expressed the following as being critical to the success of pair design within an organization:

• 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. Whether because business domains are complex or rapidly changing, some organizations know that they need to foster informal ways to grow, train, and utilize employees. Pair design offers a lot less to organizations that just expect their employees to perform.

• The organization must be quality-focused rather than focused on “shipping” because pair design principally offers major gains in design quality. Across quarters, years, and the lifetimes of products, quality design does yield economic benefits of customer loyalty, brand strength, and less customer support. Crummy design done quick has value to someone, but not to the designer/studio/product line.

• The organization must be customer-focused, and where that focus can drive wins in the marketplace. Of course, this is not to the exclusion of the economic realities that every business has, but an organization that doesn’t deeply value pleasing customers won’t see value in pairing.

• The organization can’t be too vested in its hierarchy or silos. Although there are bound to be levels of expertise among team members, the environment can’t be one in which it’s expected that seniority wins all debates about design decisions. Similarly, pairing might need to occur across organizational units (design and development, for example), and if bureaucratic divisions discourage this, pairs will be unsuccessful.

• The organization must be committed to psychological safety for its teams. (As mentioned earlier in the section on Agreements.) Designers need to feel like they have a space in which they are empowered to propose half-baked ideas and receive honest critique that is leveled at producing the best design rather than at the designer. If teams don’t have psychological safety from management, ideas will be incremental at best.