In a previous position at a startup, I was always really curious when the engineers would run pair programming sessions. At first, I thought it was a way for the engineering managers or lead engineers to keep an eye on the work that the junior engineers were doing, so they could easily course correct and have an understanding of ability and growth. I also thought that it was a bit of a silly idea, as you were wasting two people’s time on one task. It was only when I was asked whether I’d like to pair design with one of the engineers that I realized how wrong I was.

What is pair designing and where do I start?

So first off, what is pair designing? Like pair programming, the idea is that you complete a task in pairs, using two screens, two keyboards, and two mice, with whatever you’re working on being mirrored. Remote working and zoom, along with multiplayer in Figma and Sketch, have made this pretty easy. One of you then acts as the ‘driver’, with the other acting as the ‘navigator’.

The driver does the hands-on work, whether that’s drawing the flows and wires, designing UI and layouts, or potentially even coding the designs. While doing whatever they’re doing, the driver should be thinking out loud, explaining their actions. Meanwhile, the navigator follows in observation mode, asking questions, looking for opportunities, identifying edge cases, and critiquing what is being made on the fly. Their role is to focus on the driver and probe just enough that whatever is produced ends up being better for it.

Why does it work?

It might be obvious, but having two people talk through what they’re doing as they’re doing it ends up answering a lot of the questions that would normally come up further down the line in critique. Because you’ve got two eyes working on a single problem, you’re also more likely to catch gotchas and cover the bases on edge cases. There’s also a confidence that comes with two people having validated what you’ve created.

The other big benefit (and the biggest benefit I found) was knowledge exchange. Not only can you share specific design expertise between designers, but you can also set up pairing sessions with anyone who touches design, whether that be engineers, product, or content. It ends up building a shared vocabulary and understanding between people, that might otherwise take months of concerted effort.

Also, one unexpected benefit for me was that I got more done. Because I was working on a problem via a zoom call, I was way less easily distracted by Slack notifications, emails, Twitter or the fly that just flew into the room. It’s harder to break attention away when you’re doing it with another person.

So how does it work?

The first step is to establish what problem you’re trying to solve. Knowledge exchange via exploring tangents is great, but for pair designing to increase efficiency, you should set some guardrails. Similarly, set a time limit, so you know how much you can realistically achieve.

Step two is to decide who will be the navigator and who will be the driver. If you do this regularly, maybe alternate roles. Especially if you’re doing cross-disciplinary design pairing, guiding someone through how you do your job as a designer can be super rewarding because they have a deeper understanding of what you do (and how hard it can sometimes be).

Finally, stop if it’s not working. It’s ok for it to not feel natural, and it shouldn’t be forced. Pairing isn’t for everyone. Another similar point is to consider running quick ‘what went well, what didn’t’ style retros on the sessions. Just a quick conversation can help guide how you improve it later!

The benefits for design systems

While most of my experience of design pairing is in product teams, I think there’s a real opportunity to leverage design pairing in systems teams. One of the biggest issues we hear from customers is that there is tension between design system teams and wider product teams. That contributions are low and a lot of product folks don’t really ‘get’ the value of the design system. Pairing is a way to not only show a skeptic what goes into building a well-functioning design system, and acts as a way to gather feedback on the fly from the primary users of your system, but also builds empathy between the teams, making sure that they understand what you do and where the value stems from.

Want to read more about pair programming and the methodology behind it? Check out Kent Beck’s Extreme Programming Explained: Embrace Change.