Three modes of pair design

[[148849]]

Pair programming is an agile software development technique where two developers work on the same computer, with one developer writing code and the other checking every line of code for omissions. The roles of the two developers rotate based on strategy and technical preferences. Studies have shown that when engineers spend 15% more time writing software in pairs, they can reduce the number of defects by more than 15%.

Despite the differences between design and development, the benefits of pair programming can be directly reflected in pair design. A two-person design team focuses on each other's details to avoid the negligence caused by distraction. Each designer must explain the design decisions in real time, and his partner is responsible for constantly verifying the results instead of reviewing previous problems. Working closely with others also improves team morale, broadens the knowledge of the product, encourages ownership and promotes team harmony.

Given the open nature of their work, designers are often accustomed to working in cross-functional teams, most typically gathering a group of people for brainstorming, design critiques, or user research. However, some design leaders can conduct purposeful pair design in different ways (such as wireframe drafts or front-end development), using traditional collective behavior to solve problems that are usually handled by designers alone, which can simplify collaboration, enhance creativity, and improve the output design process.

Model 1: Leaders and Collaborators

Alan Cooper first proposed the concept of pair design in 1997, introducing the roles of leader and facilitator. The leader is responsible for creating as many ideas as possible, while the facilitator needs to analyze these ideas, raise important questions, consider marginal conditions, and bind the solution to the larger user or business context. Cooper consciously recruits leaders or facilitators at the beginning of the interview process based on the personality traits and strengths and weaknesses of the candidates. But in fact, designers often switch between the two roles so that everyone has the opportunity to create enough ideas.

When leaders and collaborators fully collaborate throughout the design process, the difference between the two is extremely obvious in the early brainstorming stage of the project. For example, a leader & collaborator pair often uses a pen to start communication on a whiteboard, with the leader constantly writing and drawing to express various concepts, and the collaborator expressing concerns and optimization points on the side. Compared with working independently or competing divergently, using only a pen can promote focus and co-creation.

Model 2: Leaders and Supporters

Adaptive Path also pairs designers to lead client projects, but the two do not play the role of leader and collaborator, but take turns to be leaders and supporters. One designer is responsible for leading a client project, while in other projects he may only be responsible for supporting work. The benefit of this model is that it encourages each designer to exercise his or her own leadership and communication style, and broaden his or her professional soft skills through mutual learning.

The leader-supporter pairing model is not unlike the mentor-apprentice scenario of junior designers pairing up with senior designers, but designers at any level can benefit from the role switch. Jesse James Garrett, founder of Adaptive Path, firmly believes that "you can continue to grow and mature through practice when you are a supporter. Many designers think that once they are not involved in the vision planning of the project or take on the role of project leader, they will stagnate in their careers. In fact, this is not the case at all." In a special project for a client, Jesse was responsible for supporting his colleague Brandon Schauer, and thus had the opportunity to observe how Brandon conducted a product vision workshop in a slightly chaotic team. It turned out that the problem with the team was that the foreign programmers could not communicate fluently in English and seemed lonely and silent. The end result was that the meeting was dominated by some strong voices.

Through this experience, Brandon demonstrated his unusual ability to knead all communication conversations, suppress strong voices, encourage the silent to speak, control the direction of the topic from beginning to end and drive the conversation to an end. In addition, in order to constrain the scope of the discussion and arouse broad participation, he also introduced a structured exercise - each participant used four sticky notes to write down three effective working methods and one ineffective working method. "If I were a leader, maybe I would only use my own way. Brandon recognized the pros and cons of different tools and solved the problem in his own way, which taught me a lesson."

Model 3: Cross-functional pairing

Although the previous two models usually involve pairing interaction designers or user experience designers, successful pairings can also be formed in cross-functional teams in any design process. Cross-functional design usually occurs between different types of design experts, such as visual designers, interaction designers, user researchers, or information architects. However, pair design can also be a successful strategy for collaboration between designers and non-designers.

For example, when a company is trying to understand potential users, a product owner or executive stakeholder can pair up with a user researcher during the research phase. The user researcher guides user walks, asks useful open-ended questions, and encourages users to tell their own stories, while the product owner observes and takes notes. The advantage of this approach is that both roles observe the same behaviors and come to a common understanding of the users and domain based on this. When important stakeholders are not deeply involved in the research phase, they can become disconnected from the design decisions that designers make based on their understanding of the users because they lack sufficient understanding.

Similarly, designers and developers also benefit from pair design when facing high-precision prototypes or front-end codes. When they design together with dynamic software rather than static prototypes, even if they are not technical personnel, designers can use rich real-time interactions to express their opinions, and developers can also immediately point out the feasibility and relative development costs of various solutions, constantly guiding the formation of feasible design solutions, reducing time waste and communication costs.

Paired design is not suitable for all innovation challenge projects, but if used properly, it can greatly improve the quality of creative output and design efficiency of product teams. Proper delegation of leaders and collaborators can enable them to generate and evaluate ideas faster and more effectively. This approach is more efficient than individual heroism or chaotic teams that allow each designer to take turns to lead according to their own style and methods. The introduction of cross-functional cross-pairing enhances the empathy of other roles, allowing everyone to be exposed to different skills and gain a deeper and more comprehensive understanding of the product.