I just blogged about The Benefits of Pair Design over at the Pivotal Labs blog:
How is design different for Agile product development?
“Design” can mean many things, but designing products for Agile software development methodologies present distinctive challenges. Engineers build software more quickly (and change it more rapidly) than most…
How is design different for Agile product development?
“Design” can mean many things, but designing products for Agile software development methodologies present distinctive challenges. Engineers build software more quickly (and change it more rapidly) than most, and consequently the demands on design are very different than what most designers are accustomed to. Consequently, the Pivotal Labs Design practice has evolved to focus on the important questions, keep pace with engineering, and build beautiful, functional product. Because our style of Agile focuses not only on execution (building stuff) but also on enablement (helping others learn to build stuff), we’ve also learned to guide and enable clients and client-design teams to do the same. We employ many of the same techniques and philosophies that have made our engineering practice so successful over the years, and while design is a different medium than development, the core principles of communication and tight feedback loops remain; it should be no surprise that pairing is one of our most important tools.
Why Pair Design?
Pair design enjoys many benefits which come over unchanged from pair programming. For the sake of a better product, pairing reduces the cost of change, creates predictability by encouraging Convention Over Configuration in design, and reduces waste. Pairing grows better designers by promoting learning, knowledge-transfer, and continuous improvement. Pairing helps teams to start from a shared foundation, to make creative decisions collaboratively, to externalize and validate thinking, to optimize for progress (not perfection), to remove individual ego and promote shared ownership of product. It also creates a buddy-system for your attention: because your Pair doesn’t care about your Facebook feed, the pair stays focused, avoids distraction, and gets out of the office on-time. Finally, Pairing improves projects by facilitating rotation and fresh eyes, by meshing complementary skill-sets, by creating pressure for easy ramp-up, and by driving towards a better Bus Count.
How do we Pair Design?
Pair design takes a few forms. The three major standbys are:
“Synth/Gen” Whiteboard pairing
It’s very common to pair at the whiteboard: two Pivots, one marker. The “Generator” has the marker in hand, and tends to come up with ideas. The “Synthesizer” stands back, asking questions, probing, thinking of edge cases, keeping the big picture in context. This technique is frequently used to map out feature sets or user-flows at about the epic level of granularity.
Medium-Fidelity Pairing
When whiteboard-fidelity is no longer sufficient to make design decisions, two designers will sit down with two mice and two keyboards at a single copy of Adobe Illustrator (or Photoshop, or Sketch or the like) and work on the design together. This greatly resembles pair programming, and they’ll trade off control of the cursor just as pair programmers do. The designers discuss the design challenge, occasionally turning to the computer to test out a feeling, illustrate an idea, or enshrine a decision. This type of pairing is idea for building a Visual Design System, i.e. a visual metaphor for the object domain that they’re mapping onto the product.
STYLESHEET PAIRING
When it’s time to instrument the design system on a web app, teammates will pair together on styling and front-end code. This most closely resembles traditional pair-programming, with two keyboards plugged into a text editor and browser—and with the notable exception that design testing isn’t sufficiently advanced to do ping-pong pairing.
Stylesheet pairing can either be done with two designers, two developers, or with a mix of the two: cross-functional pairing. Pairing also introduces advantages which aren’t available to non-technical solo designers. When designing in front of working software (rather than static mock-ups), designers are able to generatively experiment and design in real-time. They can play with interactions, make changes at full-fidelity, and be creative in a way that’s impossible in a mock-up.
When do we pair?
Unlike development, which strives to pair 100% of the time, full-time design pairing is rarely seen on the entirety of a project. Pairing is valuable whenever design decisions are being made, but there are types of project work—especially documenting decisions made by the pair—which benefit from solo attention as well. Some solo techniques include:
Converge / Diverge / Converge
When they hit an impasse, they may split up for a short time (usually 10-30 minutes) to work through ideas on their own before converging again, presenting their explorations, and continuing to work the design.
Double-Speed Documentation
Once made, design decisions often have to be documented. Design pairs will split up to create the Minimum Viable DRY documentation. Because there are two designers, they deliver in half the time.
Exquisite Corpse
The name Exquisite Corpse is taken from the surrealist literary parlor game of the early 20th century in which “players draw in turn on a sheet of paper, fold it to conceal part of the drawing, and then pass it to the next player for a further contribution”. In exquisite corpse, designers will set a short timer (usually 10-30m), work on a design direction, and then pass it off to the next designer. Alternately, designers can forego the timer and just say “ready?” when they’re stuck. Ideally, several revolutions are completed each hour, allowing for rapid iteration, idea generation, and refinement.
Switch-Hit Pairing
Sometimes we have an opportunity to split a pair across two related projects from the same client. In this situation, it’s beneficial to include both designers in the Inception and ramp-up for both project. They’ll each be responsible for a single project, and often solo, but because both have context they’re able to support each other as a pair when decisions will benefit from a second person. Often we find it’s helpful to block out an hour a day for pairing—it’s not used every day, but it makes it easy to jump into action when necessary.
Design Is Different
Design is different than development—it has different rhythms, specialties, and affordances—and design at Pivotal is different from design elsewhere. We use this constellation of techniques, which we’re continuously improving upon, to build the best apps in the world (and to teach client team how to do the same), and pairing is a crucial ingredient.
Check it out, and let me know what you think in the comments!
jonathanpberger.com/blog 