Design pairing is a method of collaboration where two designers work closely together to solve design problems, ideate, and execute design work. In some environments it means two designers working on the same project in real time. In leaner environments — which is the more common case — it means two designers meeting regularly to share their work, surface blockers, and support each other through hard problems. Either way, this structured partnership taps into the diverse skills and experiences of both designers to produce more innovative and well-rounded outcomes.
Compared to a peer review, this is more focused on specific issues instead of higher-level review. The result is more time to solve problems.
Julia Cheng, Senior UX Designer
I ran a pairing pilot with two senior designers on my team, Julia Cheng and Merve Ayomak, over several months. What they found confirmed what the research suggests: pairing doesn't just make individual work better — it changes how a team thinks and shares knowledge.
Key Idea
Design pairing works two ways — and both make harder work easier to sustain.
- Shared problem: Two designers work on the same challenge together in real time — more directions explored, less rework, faster decisions.
- Peer network: Designers each own their work but meet regularly to share progress, get specific on blockers, and learn from each other. This is the most common form.
What Design Pairing Actually Is
Design pairing is not a review. It's not a critique. It's a regular, structured relationship where two designers invest dedicated time in each other's work — whether that means jamming on a shared problem or each bringing their own hard problems to the table.
What sets it apart from other feedback loops:
- Peer review evaluates finished work. Good for catching errors, but the design is already baked.
- Design critique is a group conversation about possibilities. Valuable, but general and infrequent.
- Design pairing is specific — focused on the exact problems a designer is wrestling with right now, with enough depth to actually solve them.
Why It Works
Productivity increases, not decreases
The reasonable concern: if two designers are on one problem, you're covering half as many problems. Research on pair programming — the software engineering equivalent — reframes this. Pairs generate more solution directions, catch issues earlier, and arrive at simpler designs than individuals who review each other's work after the fact. The output quality gain typically outweighs the apparent throughput cost.
The reason is compression. Instead of a cycle of build → review → revise → review again, pairs collapse the loop into a continuous dialogue. Less rework. Fewer handoff gaps.
Productivity boost from two people jamming on a problem. I always leave with something valuable and can do something with the info.
Merve Ayomak, Senior UX Designer
Knowledge transfers in context, not in a doc
Most knowledge-sharing mechanisms are deferred: documentation, lunch-and-learns, Confluence pages. Pairing transfers knowledge while the work is happening — which is when it actually sticks.
Most knowledge-sharing mechanisms are deferred: documentation, lunch-and-learns, Confluence pages. Pairing transfers knowledge while the work is happening — which is when it actually sticks.
Merve experienced this directly. She was leading challenging discovery work on her own and was stuck on how to approach it. Watching Julia work through a straw man in a pairing session gave her a concrete process to draw from — she identified the parallels and built her own steps from it. No knowledge transfer session. No documentation. It happened inside the work.
We all do good individual research, but the organic sharing of this…helps it stick.
Merve Ayomak
It builds skills that reviews can't reach
Pairing develops capacities that individual work and retrospective critique don't touch — specifically articulating design decisions in real time and navigating different working and thinking styles. For junior designers, pairing with a senior provides a live model for how to approach problems. For seniors, it surfaces assumptions that have become invisible through habit.
I learned a lot about triad relationships — the soft side of our work. This is a big part of our job.
Merve Ayomak
Hard challenges have somewhere to land
Design is a challenging job. Complex, ambiguous problems are hard to navigate alone — and can stall for weeks when there's no one to think through them with. Julia put it simply: the obstacles in their sessions came from the work itself, not from the pairing. The structure didn't create friction — it gave those real challenges a productive place to surface and get solved.
Obstacles came from the work, not pair design.
Julia Cheng
How to Run It
Step 1 — Set a cadence and protect it
Julia and Merve started weekly and kept it that way. Consistency mattered as much as content. Weekly is a useful default — frequent enough to stay current on each other's work, not so frequent that prep becomes a burden.
Keep the momentum going. Once they got topics, the weekly cadence worked well.
Julia Cheng
Step 2 — Come prepared, stay flexible
Each person should arrive with a specific problem or question. The most productive sessions start focused and shift as one insight unlocks the next. Don't over-schedule — leave room for the conversation to move.
Come prepared for what you want to get out of it, but have some topics ready to jam on.
Julia Cheng
Step 3 — Be clear about what you need
Before diving in, clarify what kind of support you're looking for. Validation on a direction? A fresh eye on something you're stuck on? A jam session on a problem that's open? The session goes further when both people understand the goal going in.
Step 4 — Protect the social layer
Merve and Julia kept an informal, conversational tone. That wasn't a distraction — it made the collaboration sustainable and surfaced ideas that a strictly transactional session would have filtered out. Pairing over time builds context and trust, and that context compounds across sessions.
I enjoyed the social aspect of the weekly recurring meetings.
Merve Ayomak
Common Mistakes
- Treating it like a review. If one person presents work and the other reacts, you're doing a review, not pairing. Both people shape the work together — from the beginning.
- Pairing on the wrong problems. Simple, well-defined tasks don't benefit much. Reserve pairing for complex, ambiguous, or high-stakes design decisions.
- Pairing people who are too similar. The value comes from complementary perspectives. Two designers with identical strengths will converge quickly rather than challenge each other.
- Letting one person dominate. Pairing works when both designers are actively contributing — questioning, pushing back, building on each other's thinking. If one person is just reacting, you've lost the collaboration.
- Letting sessions drift into status updates. Regular cadences can slip from active problem-solving into check-ins. Keep the focus on decisions that need to be made right now.
Quick Reference
Use design pairing when:
- You're stuck on a complex or ambiguous design decision.
- The problem spans product areas or needs complementary skill sets.
- A junior designer needs to build skills alongside active work.
- You need to transfer system knowledge quickly.
- Retrospective reviews keep surfacing the same categories of issues.
- The task is well-defined and low-stakes.
- Both designers bring nearly identical perspectives.
- The work is in a refinement or polish phase.
Skip it when:
This post is based on a design pairing pilot I ran with Julia Cheng and Merve Ayomak at Copperleaf. Quotes are drawn from interviews conducted during the study.