Design Pairing: Two Designers, One Screen, Better Work

Design pairing puts two people on the same problem at the same time. Mailchimp’s Design Manager Nina Mehta argues that this synchronous collaboration improves the quality of output while cutting the time to get great work done. Here’s how she structures pairing sessions and makes the case for them to management.

What Design Pairing Is (and Isn’t)

Pairing is not dividing a feature into pieces and assigning each person a slice—one designer tackling the account creation flow while another handles onboarding is just parallel work. True design pairing means two people are synchronously solving the same design problem together, in the same file, at the same moment.

Several models exist. Cooper Design introduced a generator/synthesizer split, where one designer produces a broad set of ideas and the other shapes those into a UX flow. Adaptive Path’s lead/support style pairs a senior with a junior to bring less experienced designers into leadership roles. Pivotal Labs, where Mehta previously worked, borrowed the screenshare approach from pair programming.

Roles and Setup

The practical setup is simple: two keyboards, two mice, and the same image on both displays. Before multiplayer tools, pairing required a cable joining two monitors; in Figma, the pair simply follows each other in multiplayer mode.

Before starting, the pair must define who drives and who navigates. The driver controls the file, keyboard, and mouse—making grids, clicking, and doing the physical design work. The critical difference from solo work is that the driver is thinking out loud: verbalizing decisions such as pulling the primary button because it’s the main call-to-action, or noting that users may need helper text based on research findings.

The navigator stays in observation mode, never typing or clicking. Their job is to follow the work and raise the probing questions that would otherwise surface only in a critique days later or after release. That might mean pointing out an existing product pattern that conflicts with the new design, or asking how to add guidance where users tend to get confused. The navigator is not criticizing, but surfacing opportunities and edge cases in the moment, wherever each person is located.

Practical Tips for Your First Sessions

  • Agree on the problem you want to solve before starting; a quick sketching session or inspiration hunt helps align the pair.
  • Decide who drives and who navigates first.
  • Set a duration that fits the task—there’s no too-short or too-long pair; 10 minutes or a full week both work.
  • Take breaks; pairing is mentally tiring because you’re generating and synthesizing constantly.
  • Swap roles partway so each person experiences both positions.
  • Adopt improv rules: support the idea, move the work forward, and defer saying no until later.
  • Expect it to feel awkward at first—being watched while you work is exposing. Treat that discomfort as a non-moment.
  • Close with a quick retro: what felt good, what felt off.

Arguing the Investment Case to Leadership

The standard objection is that pairing doubles the cost for a single deliverable. Why put two designers on one thing when they could ship two? Mehta’s answer is that pairing makes the work both faster and better. Teams that commit to it see:

  • Instant feedback on work in context, not days later.
  • Fewer interruptions from Slack, email, and other noise.
  • Faster knowledge distribution in context; less need for documentation.
  • Fewer meetings to set context on the project.
  • More ideas and possibilities generated.
  • More errors, bugs, and edge cases caught before handoff.
  • More organized files.
  • Greater confidence in design decisions.

Finally, and perhaps most importantly, pairing builds team morale—and good morale fuels even better work. For a deeper grounding in collaborative practice, Mehta points to the classic Extreme Programming Explained: Embrace Change, which covers how to build software with teams.