Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the navigator, reviews each line. The roles switch frequently as the pair takes turns focusing on the strategic and tactical aspects of their work. Studies have shown that while engineering pairs spend 15% more time to build the same software than individuals, their output has 15% fewer defects.
While design is different from development, several of the benefits of pair programming translate directly to pair design. A team of two keep each other focused and less prone to distractions. Each contributor must explain decisions in real-time and the pair can validate work continuously instead of retrospectively. Working closely with another person also improves morale, broadens knowledge of the product, and encourages collective ownership and team cohesion.
Due to the open-ended nature of their work, designers are usually used to working in cross-functional groups which are typically pulled together for purposes like generative brainstorming, design critiques, and user research. However, there are multiple ways design leaders can implement intentional pair design to these traditional group activities as well as in functions that are typically done solo, such as wireframing or front-end development, to streamline collaboration, increase creativity, and improve the output of the design process.
Model 1: Generator & Synthesizer
Cooper pioneered the concept of pair design in 1997, introducing the roles of generator and synthesizer for design pairs. The generator’s responsibility is to be maximally creative, generating as many varied ideas as possible. The synthesizer’s role is to analyze the ideas, ask important questions, consider edge conditions, and tie solutions back to the broader user or business context. Cooper specifically recruits designers to be either generators or synthesizers from the very beginning of their interview process based on personality traits and strengths and weaknesses, but in practice designers often switch roles so that each partner has the opportunity to generate as well as evaluate ideas.
While generator and synthesizer pairs can partner throughout the entire design process, the difference in their roles is most apparent during brainstorming and ideation phases. For example, a generator / synthesizer pair will often whiteboard with just a single marker, with the generator actively drawing out concepts while the synthesizer vocalizes concerns and improvements. Using just a single marker encourages focus and co-creation rather than independent or competitive ideation.
Model 2: Lead & Support
Adaptive Path also sends designers out in pairs to work on client projects, but instead of using generator and synthesizer roles, designers alternate between formalized lead and support roles. A designer leading one client project may act as support on another. The advantage of this model is that individual designers are encouraged to develop their own leadership and communication styles and to expand their own soft skill toolkits by learning from each others’.
The lead and support pair model is natural for mentorship scenarios where a junior designer is paired with a senior one, but designers at all levels benefit from switching between the roles. “Being in a support role grows and matures your practice,” says Jesse James Garrett, founder of Adaptive Path. “Many designers feel that if they don’t own creative vision or take a leadership role then they are stagnating in their career, which is not the case at all.” On one particular client project, Jesse was asked to support his colleague Brandon Schauer and had the chance to observe Brandon lead product vision workshops with a particularly difficult audience. The audience in question were foreign developers who struggled with communicating in English and tended to be stoic and silent. The result was that meetings tended to be dominated by a few loud voices.
Over the course of the project, Brandon demonstrated an extraordinary ability to finesse these conversations, calming loud voices and encouraging quiet voices, all the while reining in tangents and driving conversations to closure. Additionally, he introduced structured exercises — such as one where all attendees got four sticky-notes and had to write down three things that were working and one thing that was broken with the current software — in order to bound the problem space and elicit broad participation. “If I was in a lead role, I would have just used my own toolkit. Brandon recognized the need for different tools, brought them to the table, and taught me.”
Model 3: Cross-Disciplinary Pairs
While the previous two models usually involve pairs of interaction or UX designers, successful pairs can also be made from cross-functional teams at all stages of the design process. The most common type of cross-functional design pair occurs with different types of design experts, such as a visual designer and an interaction designer, or a user researcher with an information architect. However, pair design can also be a successful strategy for collaboration between designers and non-designers.
For example, a product owner or executive stakeholder can be paired with a user researcher during the research phase when a company is trying to build understanding of potential users. The user researcher leads the interview, asking effective open-ended questions and encouraging authentic stories, while the product owner observes and takes notes. The benefit of this is that both parties observe the same behavior and build a shared understanding of the domain and the users. When important stakeholders are not deeply involved in the research process, there is often a disconnect further down the line when designers justify their design decisions based on user understanding that the stakeholder lacks.
Similarly, designers and developers benefit from pair design when working with high fidelity prototypes or front-end code. When co-designing with live software rather than static mockups, designers can experiment with rich interactions in real-time even if they are not technical. Developers can immediately point out the relative implementation costs of various design possibilities and continuously guide the pair towards viable solutions, reducing wasted work and communication overhead.
Pair design is not a solution for all creative challenges, but if applied effectively the practice can improve the creative output and efficiency of design and product teams. Assigning generator and synthesizer roles enables a pair to create and evaluate ideas more quickly and robustly than either an individual or a disorganized group while having designers switch leadership roles allows each to develop their own style and soft skills. Introducing cross-functional pairs improves empathy for other roles, exposure to different skill sets, and a better overall understanding of the product.