Editor’s note: The following is a recap from a livestream presented by Mailchimp’s Design Manager Nina Mehta, where she discusses what design pairing is, how to structure it, and tips for convincing your boss that it’s a good idea.
I want to introduce everyone to design pairing, why I love it and believe this can improve the quality and reduce the time it takes to get great work done.
First off, let’s start with defining what design pairing is: two people synchronously solving a design problem together.
Let’s say you’re creating a signup flow. One person designs the account creation flow. Another person designs the onboarding experience. This is called dividing and conquering—not design pairing. Design pairing is when two people synchronously work on the same problem at the same time.
There are a few different styles for design pairing. A lot of people cite Cooper Design as the one who started design pairing with their generator and synthesizer model, where one designer creates a lot of ideas and another turns it into a UX flow.
Adaptive Path is another design pairing advocate with their lead and support style. This style helps level up junior designers to a lead role.
Pivotal Labs, where I previously worked, borrowed a lot from the pair programming methodology of screenshare pairing.
This is me pairing (back in the days when we were in the office):
A typical pairing setup is two keyboards and two mice. We have the same image on both of our displays. In the days of Sketch, we had a cable that connected the two monitors together. Figma came along, so we didn’t have to do that anymore. We now follow each other in multiplayer mode.
To get started, you need first define each person’s role—who will be the driver and who will be the navigator. The driver has control of the Figma file, keyboard, and mouse. They’re typing, clicking, making grids, and doing the physical making—basically normal design work. But the difference is they’re thinking out loud. So the driver is saying things like “I’m going to pull the primary button here because that’s the main call-to-action” or “I think we’re going to need some helper text here because we heard in research that users get confused.”
As the driver talks out loud, the navigator is following in observation mode. The navigator does not type or click. They’re simply following the driver and asking probing questions that would typically come up in design critiques. “I think we have a pattern like this elsewhere in our product? Our users tend to get confused here. How can we help bring more guidance?” The navigator should never be criticizing the work, but rather simply bring up questions that would have come up a week later in critique or a month later when the feature is released to users. This enables the design pair—no matter where in the world each person is located—to look for opportunities and edge cases right in the moment.
One obstacle that tends to come up when designers try to pair design is making the case for it. Someone (aka your manager) is bound to ask isn’t this double the resource? Why would I put two designers on one thing when they can work on two things?
My response is that’s design pairing makes the work go faster and better. Here’s what I’ve seen happen to teams that invest in design pairing:
Last but probably most important, design pairing is great for team morale. And when morale is good, the work tends to be even better. If you haven’t tried pair designing, give it a go and see how it changes your team. And if you want read more, I highly recommend the book Extreme Programming Explained: Embrace Change which provides a lot of great tips on how to build software with people.