Title:
Important Lessons in Pairing – From a Designer’s Perspective
Question:
As part of our blossoming partnership with cooper, I had the good fortune to sit in one one full day of cooper’s Kim Goodwin (recent author of _Designing for the Digital Age: How to Create Human-Centered Products and Services) was the instructor. Throughout the class, she emphasized the importance of pairing in design. Some of her advice is spot on with pairing practice in the Agile community. Some, however, was new to me, and quite profound. Here are some “Kimisms” (or cooperisms) that I picked up in the class.
- Start with a pair of peer designers. They may have different experiences, skills, and areas of preferences, but they are peers.
- Give them a shared design task. Both are working together to create the design.
- One member of the pair is designing and creating and the other is helping. Kim referred to these people in two distinction roles – the generator and the synthesizer. The synthesizer helps in three distinct ways:
- Concept midwifery: The synthesizer works with the generator to help them create a fully formed idea, most often by challenging the design from a narrative perspective informed by the personas, scenarios, and workflows created during the research phase of the project.
- Understanding the concept: The synthesizer confirms their understanding of the idea.
- Critiquing the concept: The synthesizer helps to critique the idea by explicitly asking how the primary persona for which the concept has been developed would use this idea. Once this has been handled, the synthesizer continues to ask how other personas would respond, taking great care to avoid their own experience and leverage their personas experience.
- People at cooper pair for a good chunk of time – often a year – but not “forever” as too much time together makes you less effective at critiquing work.Roles are important, and while people tend to fall into common roles that they can skillfully execute, pairs sometimes explicitly switch the roles that they’re playing. This is common in pair programming, too!
- One member of the pair can help the other from being bogged down in too much detail at the wrong time of the design.
While I’ve explained this in pretty cut-and-dry terms, the reality is that pairing is always a fluid process. If isn’t so much as there is an explicit role switch as that whomever is leading is generating and whomever is synthesizing is helping. Hand the marker to me, and when I stand up we fluidly change our perspectives and our roles.This is some great stuff, especially the light process reminder about helping others create fully formed ideas before critiquing them, and when critiquing ideas, remembering to critique them from the perspective of your personas, and not your own experience.