The Agony and Ecstacy of Pair Design
Working at Pivotal means working in their signature method: pairing. Nothing would have prepared me for how revealing this process is about myself as a designer, correcting lapses in design process, or how heavily it would lean on everything I’ve experienced practicing design, namely communication.
If design pairing is unfamiliar, here’s the idea: the design work involves two designers, one computer, and two monitors. The person driving the computer and operating all the software has a co-pilot, sometimes called a synthesizer who is there to watch out for lapses, raise good points, and otherwise be a supporting presence as design happens; both are expected to continually talk, discussing what they’re doing and why. Typical fare is working through an interaction flow, wording an email, or concocting questions for user testing.
Some take this description literally and interpret it as designers being attached at the hip for 40 hours a week doing everything together; this is misguided and painful to watch. Careful designers are keen to understand the problem space before crafting approaches, and design pairing is no different. Pairing is a sometimes solution great for some problems, pointless for others and it’s important to understand the difference.
Some disclosure and thoughts about experimentation
Where did this all come from? Simply put: Pair programming. At some point it was determined that since pair programming worked for programmers , then it would work for designers. It’s important to fully disclose a few key facts about pair design: 1) The origins don’t come from design, it comes from programming. As such, I tend to see pair design as experimental. 2) For the few shops that employ pair design, there isn’t much in the way of quantitative data to support it, so we rely on qualitative feedback. 3) Pair design in environments where programmers also pair sees designers treated the same as programmers.
Pair design as an experiment: Neil Armstrong piloting the experimental Lunar Landing Research Vehicle.
So, great, I’m framing this article with design pairing as an experiment. That said, design pairing can be highly effective when used properly, so let’s dive into how it’s used and why. Pairing isn’t easy but there are some aspects that greatly improve the design process, and help designers get to a deeper understanding of themselves, their process, as well as work smarter.
Disruption
Pairing agitates the traditional understanding of a designer, typically seen as a person seeking moments of quiet flow in which to ply their trade. There is a time for this, but pairing brings a social aspect into design process. When paired, designers engage in a highly social, collaborative relationship that shines light into the darkest corners of the creative process. With pairing, the critique and review of design work happens continuously. As a result, we gain unprecedented insight into what we’re made of and where we can improve.
Detecting defects in logic or judgement
The closeness in pairing also invites discussion around how we solve problems and apply design thinking to daily challenges. In being prompted by your pair to explain aloud what you’re thinking and why, you get to explain yourself as you work, which is something missed by the traditional design review process. Explaining how you think as you think is incredibly valuable in hearing your own logic, and having someone provide feedback.
Mentoring
Having a good pairing partner can be some of the best mentorship you can find as a designer. They don’t need to necessarily be more experienced, but a complimentary pair can be honest and insightful when you need it. So much of how we evaluate design is in retrospect, what if you found a mentor willing to sit with you for 3–4 hours as you drove the software, having them evaluate your thinking or technique?
Maintaining honesty
The physical and psychological closeness of this process is a state of vulnerability not often found in design except for maybe design reviews. From how we organize ourselves, to how we think through the challenges every project brings, pairing puts another human being at the forefront of our thinking and doing. As such, we are required to be as authentic as possible in our explanations because it’s all too easy to call bullshit when we’re shortcutting, not explaining ourselves clearly, or not backing up our ideas with enough rationale. This isn’t to say our guts aren’t trustworthy and that some inspiration comes from a vague place, it’s for those moments when we really can’t back something up that should be challenged.
Discouraging behavior that doesn’t move projects forward.
As designers we can be obsessive and detail oriented, sloppy and creative, distracted and overwhelmed, and this manifests itself in how we get things done. Working with a pair, for better or worse, underscores these behaviors. If you’re not working through a problem quickly enough, your pair should be able to help you reflect on this. If you’re moving too fast and missing too many details, this is an opportunity to understand how you missed them. The idea here is to enable each other to surmount working style inefficiencies by talking about it.
User testing and synthesis
The research heavy aspects of some projects make pairing a perfect approach. Between recruiting, on-site visits, interviewing, synthesizing, recording and editing video, and sharing out user intelligence, four hands are better than two. With user research it’s very easy pair on interviewing and synthesis and I‘ve found this a great way to use the process.
Onboarding
Pairing new hires is a great way to be onboarded and ideally the pairing will happen consistently all day for a the first few weeks, depending on the person. This helps new designers get a deep dive into company culture and process that is way better than reading tons of outdated documentation, or being left alone to figure it out.
Skill transference
When it comes to a designer who wants or needs to learn a new process, pairing to the rescue. Take your experienced designer and pair them with your process newbie, after a few weeks or months of work together you’ve transferred the needed skills. Articles, books, and classes are fantastic supplementary activities, but don’t compare to pairing. Sitting next to the local expert in whatever your trying to learn is hands down the best way to learn.
Prioritizing design tasks
Shared priorities are an important part of the agile methodology and it’s no different for designers. Making sure you’re routinely checking in on your efforts is important. In most projects my pairing partner and I will keep a Trello or some sort of list of our tasks. Most mornings we’ll spend the better part our first hour discussing what we did the day before, strategy updates, and what the priority is for today.
Hiring designers.
The above aspects of design pairing are penetrating ways to gauge the temperament and integrity of designers around you, so when you apply pairing to the interviewing process, you may never be the same.
When your designer comes in for an interview, have them work on a real project pairing with another designer. Have a problem or task queued up ready for execution, and get to work. Have them work on that problem for a couple hours. Have them drive, then have them do some synthesizing.
Truth be told, there are sensitivities around having designers work on client work both from the standpoint of designers doing work for free, and client privacy. Next time you’re considering a designer candidate though, think about these specific areas that you will get to the bottom of very quickly if you do a pairing interview:
How do they follow through on their ideas? What’s that like?
Do they know their shit? (material, marketing, landing pages, conversion, ios, android, testing, research, etc.)
Can they focus for an hour? Two? Three?
How do they give and receive feedback?
Can they make good points when justifying their work?
Do they align themselves more often with facts or opinions?
Do they talk in absolutes, or are they able to entertain variability and chance?
What are their tangents like, and where do they go?
Are they obsessive in productive ways?
What’s their overall bedside manner like?
How do they register the stress of this approach?
How quickly (or positively) do they grasp and act on a completely new objectives with little context?
Did the interviewer learn anything new about design as a benefit to pairing with them?
Are knowing these worth the ask? No designer is going to score 100% awesome across these traits, and there’s still dozens more to think about but the value is obvious, pairing is a big huge picture window into the landscape of another person. For me, interviewing designers will never be the same and definitely worth the ask.
This brings up something worth an article by itself…
What if you find out a designer isn’t working out? This could be an article by itself and with interviewees it’s easier, you can tell them thanks but no thanks.
If we’re talking about designers on staff it’s a topic outside the scope of this article, but I will say if a designer you’re pairing with creates an unsafe psychological space through bullying, not being sufficiently self aware, or is simply an asshole then I encourage you to deliver the qualitative data you’ve collected while pairing to their manager in a kind, yet direct fashion.
How do we provide feedback when we notice deficits?
In solo design, there isn’t always a clear way to put the defects in someone’s approach under a spotlight. As such, we can settle for less than stellar performance from designers simply because we lack the ability to identify and observe the sources of some issues. Working as a pair surfaces issues quickly, but that’s not enough and to pair effectively — you must find ways to raise issues.
This is where pairing has leaned so heavily on my ability to articulate my motivations and feelings, and provide kind and timely feedback. A quick and easy way to engage this is to spend 10 minutes at the end of every day doing a mini-retro where you surface what was good, what was meh, and what can be improved. Forming this habit from the beginning of your working relationship is the best down payment on making tough conversations easier when they pop up later.
Open, direct communication.
Even for good communicators, pair communication is a massive challenge. Just because you get over the fear of providing difficult feedback doesn’t mean that’s the end of it. As if to add insult to injury, you sometimes have to provide the same feedback over, and over, and over.
It’s not that people are dense, it’s that we’re often not used to getting feedback on our performance while in the trenches. Sure, we have critiques and reviews but we rarely have someone observe the route to those milestones. When we pair, issues become apparent early and often, and direct communication about the issues opens up the possibility of solving and working through them as a pair.
Who should drive and who should co-pilot?
If you’re aware (or become aware through pairing) of your deficits, you should be the one driving and the pro should co-pilot. You know how it’s harder to remember how to get somewhere if you’re not driving? Avoid that. Something we do at Pivotal is an “I do, we do, you do” approach where one designer will lead (usually with newcomers or greener designers) and gradually abdicate leadership as the less experienced designer catches on.
You don’t have to pair all the time
In pair programming it’s typically ideal to pair all day every day, however designers are a different case and a pragmatic approach is in order. Again, take time to understand what problems need pairing. Are you facing a big problem? Are you in unfamiliar territory? Is your pairing partner brand new to the company? Do you need to do a ton of synthesis? Then take a couple days to pair on those big issues.
On the other hand, are you typesetting? Are you working on a layout, or editing some video? Do you have more than one design problem to work on? These are prime soloing activities where pairing up later for some feedback or validation works great. In this case, you’re dual-streaming on different types of work, arguably being more productive than a single designer, certainly a selling point of pair design, but like I said at the beginning not always quantitatively proven.
When you do pair, don’t forget about pacing things out
Take time off from pairing during the days you go at big problems together for long periods of time. Go take a break, a walk, work on something different. Pairing can be very tiring, particularly for those that aren’t used to working side-by-side all day with someone else.
Another trick for long pairing days is to get away from the computer. Stand up and take to a whiteboard and draw together. Move around and physically emote, wave your hands, be expressive.
Pair cross-functionally
Does an engineer look like they could use some help understanding your decisions? Does the P.M. need greater insight into how research is applied to interface designs? Grab them and pair! You can learn so much by exposing yourself to domain knowledge found throughout any team. Tangentially, this is very fertile ground for designers to grow and become more integrated with their teams.
Are you producing your best ideas while working alone?
The only way to answer this question is to contrast soloing with pairing through hands-on experience. It’s easy to think the solo designer has all the answers but it’s precisely this type of hero-centric view that pairing attempts to challenge. When The Hero absorbs all the experience, presentation, and responsibility there isn’t going to be much knowledge transfer, checks and balances on logic or approach, and few opportunities to get a clear understanding of what makes a designer successful, or difficult to work with.
If you could shine a light on the creative process and observe it in real time, isn’t that worth getting a line of sight into? Pairing can be that light, but just like any process or tool it’s thickheaded to use it all the time so take care to understand where it comes from and why it’s used as you experiment.
⍲
