How to pair design (and convince your boss to invest in it)

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.

You can watch the full presentation on YouTube or grab a copy of her presentation slides here.

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.

What is design pairing

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.

Styles of design pairing

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.

Setting up for design 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.

A few tips as you start design pairing

1. Define the problem you want to solve. You and your pair should discuss and agree on this upfront. I like to do a quick sketching session or an inspiration hunt to get us on the same wavelength.
2. Decide who’s going to be the driver or navigator.
3. Talk about how long you want to pair. 10 minutes, 1 day, 1 week—there’s no such thing as too short or too long.
4. Take breaks because pairing can be tiring. You’re talking, generating, and synthesizing a lot of ideas.
5. Swap roles as some point so you each play different roles.
6. Practice improv rules. This is incredibly important here because you’re generating a lot emergent ideas with another person. You want to be supportive of your pair and move the work forward. There’s plenty of time to say no later.
7. It’s okay if it feels weird. When you design pair, you are very exposed when someone is watching. Celebrate any weirdness and make it feel like a non-moment.
8. Run a mini retro at the end. What felt good? What felt off? Just have a quick conversation about it.

How do you convince your boss to implement design pairing?

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:

• You get instant feedback on the work in context.
• You’re less likely to be distracted by Slack, email, and other interruptions.
• You end up distributing a lot of knowledge in context faster.
• You don’t have to document as much.
• You don’t need as many meetings to set context.
• You’re generating more ideas and possibilities.
• You tend to catch more errors, bugs, and edge cases.
• Files tend to be more organized.
• You feel more confident about your design decisions.

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.