If you are looking for a piece that isn’t biased from my personal pairing experience, go away. Shoo fly. If you are okay with me spouting the greatness of having a pair, continue onward my dear friend.
This post also deserves a clarification on my personal background with pairing. My pairing experience has been with another designer and I being completely dedicated to one product. This makes a difference in the amount of benefits that comes along with pairing, but this doesn’t mean that you shouldn’t try it if you can’t have two people dedicated to design on a product or project.
We should talk about what I mean by “design pairing”. Design pairing is when two designers work on a problem together. That could entail any part of a product development lifecycle: from the framing of the business problem and user value hypothesis to a small iteration on a existing feature of a product. It encompasses all the specialities of design, UI, UX, UXA, UXR, Visual, Interaction, Content, etc. When two designers from any of these fields work together, they are practicing design pairing.
Design Pairing is really just micro-collaboration. Here are some of the benefits that both the designers involved, the team in general, and the business will see if their designers work together in pairs.
Having another designer looking at what you are working on, daily, sounds daunting. I know it did to me. However, once I sat with another designer and formed a relationship with enough trust, some magical things started to happen. One of those things was the improvement of my weakest design skills. This balanced my design toolkit.
It is highly unlikely that you are one of those magic design unicorns that knows a great deal about every area of design. It’s likely that your pair will have a different skillset than you. Before pairing regularly my strengths were mostly in the architecture of digital products, as well as the user interface and visual design. I didn’t have that much experience in research, content design, meeting facilitation etc, and was rather weak in those area.
As I paired with other designers, my weaknesses surfaced and I learned to be humble. This leads to the learning process of “I do, We do, You do”.
It’s rather self explanatory, but that doesn’t negate the fact that its an extremely useful process and quick way to learn. First the designer with strength in the skill does the task or act while the designer is present. Then they may do it together as a pair, and subsequently the person who has the skill on lock will have the other do the skill and give them feedback.
Often this this happens less formally.
Example: “Hey, I think we should include an agenda with that meeting invite. I want to make sure that it is all timed out so we have time to review action items and next steps. What do you think we should include in the agenda?” Thus the person with more facilitation experience takes control of the monitors and take part in the “We do”.
Another Example: “Why did you decide to make that button yellow?” a designer new to the team might ask.
“I made it yellow for multiple reasons, one, its our brand action color, and two I want to make sure it stands out agains the rest of the page because it’s the main call to action and will provide the business with the most value. The hypothesis being that the value will come with a higher click through rate to the purchase flow,” the other designer responds.
In this way knowledge gets transferred quickly, not just with skillsets, but also with understanding of the business and user problems.
I have witnessed pairing being one of the best ways to learn and develop as a designer. It promotes learning through collaboration, allowing you to become more like a unicorn on the reg.
A Structured Design Process
In order to work well with another person, you have to come up with game plans. When working alone, one might do this, but you aren’t forced to think through the plan as much as in a pair.
When faced with a problem, the pair needs to decide how to tackle it. What in their toolkit is best for trying to understand or solve for that problem? Should we do a test of some sort? Should we first facilitate a cross team collaboration where we generate a bunch of different ideas for solutions? What is the best way to spend our time to bring the most value to the users and the business? Where in the product process are we and what can we do to move the team forward towards success? What does success look like for us?
All of these questions end up being discussed between you and your pair. This back and forth helps develop a sense of the value that the pair brings to their employer and also a greater sense of the “why” behind their work. It forces the pair to sit and determine what a successful iteration looks like.
Before pairing I would quickly write down a list of things that I needed to accomplish, and often selfishly pick the thing that I enjoyed most, often that was tidying up my sketch file. With a pair, that is much less likely to happen.
If at the beginning of the day I say,
“I think we should clean up the sketch file, its getting a bit messy. I’m having a Marie Kondo moment.”
A pair might respond, “I don’t think thats a wise use of our time, why don’t we check the backlog first to make sure there isn’t anything pressing, also remember we need to test that assumption surrounding log in and churn rate. We really should think of a way to do that.”
Having a pair does wonders for ones focus, a deeper understanding of the design process, and ability to prioritize.
Higher Quality Work
As a solo designer, you have to sit and think about what you are going to do. Do it, and then stop to think about the work more. If you hit a wall, you may go and find others to interact with via a design critique, or a round of user research, or paper prototyping etc. Then you will be able to go back to your work and iterate, breaking past that wall.
When designers pair, they can play two different roles at the same time. One can be the person working on the problem, the other can be the one watching, observing, and thinking of questions to ask about the work. In other words, one can be the generator of the work, while the other can be the synthesizer of the work. The synthesizer can be there to ask questions such as “Is this the best way to solve the problem?” or “I wonder if we can solve this without any actual front end design?”
With one person acting as the generator, and the other as the synthesizer, you end up removing many of those walls that you would encounter as a solo designer. Many times due to the fact that the time you would have spent thinking is already being done for you by your pair!
You also end up reducing the amount of future design debt for the product team because your synthesizing pair tends to make sure design patterns are followed. I can’t count the amount of times myself or my pair has asked “Is there already an existing pattern with our design library or for iOS that we should be following?”
Work being highly scrutinized and synthesized has other benefits as well. You are more often going to be solving the correct problem, and have a higher confidence in your design decisions.
As a pair, you get to also determine when in your process it would be best to work on things, either the same thing, or different things, separately. This decision and act becomes in itself a design tool that you can use. If you want to not bias each other while first attacking a problem, you can separate for an allotted amount of time, work on it, come back together and share what you have created. This often brings out a better solution because you think in different ways and can even combine those thoughts or solutions in a unique way after. In other terms, you can diverge, and then converge, increasing your pairs idea output.
With divergence and convergence there is twice the amount of thought allocated to solving the problem. Thought time is a valuable asset when it comes to product development. And when a design has twice the amount of time to think, collaborate, explore and work on a problem the output of the work becomes exponentially better.
A perfect example of having ample thought time is shown in this video below. When the artist has 10 minutes, he is able to think and work on more than what he could in a minute. They are able to think about shape, shadow, background, context, emotion, layout, etc. In 1 minute, that thought process is down to what is the shape of spider man? Ok, I’ll draw that.
When I am not pairing, and have to work alone on a problem, I find that I have a much more difficult time getting to the level of work that would have been produced with a pair. If I can get to that quality at all within the allotted time! It becomes rather frustrating and is a major downside of not pairing.
More Consistent Flow of Value
One of the main tenants of lean methodology is to focus on the flow of value. To deliver value to the customer and business quickly you must eliminate any sort of waste that stands in the way. Just do a quick google on “lean flow focus” and you’ll see what I am talking about.
The focus of this post is not on the process of creating a value flow, but I do think its important to highlight the benefits that Design Pairing has to this tenant. In order to do this a general definition of what it is would probably be useful. Essentially it’s the entire process from generating a hypothesis for both the user value and the business market fit, all the way to delivering a working solution. That includes all the work that the team does in building, testing etc. Having a set of designers who pair throughout this process help the team deliver value consistently though the optimization of that value being created.
The first benefit to value flow that I can think of for a design pair, is the simple act of getting into a flow state where you can produce work is far easier. From experience, this is rather difficult when you are soloing. Picture coming into work, having a cup of coffee, and chatting with various people. We all know how difficult it is to force your self to sit down and start getting shit done. With a pair, there are unspoken expectations and a pressure to start the day off with focus. You end up coming up with a plan at the beginning of the day, because you are held accountable by the fact that your pair doesn’t care about your other work relationships or your facebook feed.
I’ll show the next benefit though an example. Picture a pair working on a story from their products backlog. Two monitors are up, the pair is working in sketch and exploring paths for an on boarding flow. All of the sudden the pair is notified that there is an urgent 15 minute meeting with product leadership. They know nothing more. A quick discussion ensues…
“Should we attend? I hate not having an agenda or not knowing what its about. It feels like it could be a waste of time,” a designer might say.
The other designer responds, “I agree, I hate that too. However it does say URGENT in the headline, and it is only 15 minutes. How about one of us goes, the other can keep exploring various on boarding options.”
This situation shows the fact that when there are two designers, it often means that work doesn’t have to stop when it’s interrupted. The “flow” of work doesn’t stop because of the interruption. Thus, the amount of work being done to help the product managers do their job, and the product developers do theirs isn’t hindered. This keeps that body of work from becoming more expensive for the organization. In other words, keeping work flowing reduces the cost of delay. The sooner value goes through the team and out to the customer, the sooner the business sees that value.
Another situation where pairing comes in very useful for flow state and the business is the conceptual space surrounding bus count. To steal from wikipedia, when I say bus count I mean, what is the measurement of the risk for the business resulting from information and capabilities not being shared among team members?
If you only have one designer, what on earth are you going to do if that team member finds a new job? Or decides to go on a month long vacation to Norway? (It was a blast, thanks for asking.) How on earth is your team going to keep delivering value to the business if a key part of value chain is now missing? Pairing fixes this by having two people on the product. You now have a more reliable bus count and your team will continue to deliver value.
Having two designers on every product, also allows you to rotate them on and off projects. When one joins, it is quicker to learn the product and get up to speed due to the fact that you already have someone doing the job, right next to you, available for any questions you may have. It takes a fraction of the time to understand a new project.
With pairs, it also means that it is much easier for the business to rotate their designers between projects. This is because when you take one designer off, there is still one on the project that carries the contextual knowledge forward. Bringing in a new designer through rotation helps bring fresh perspectives to the value stream or “flow” of work. A new person comes in and asks many of the questions that you mulled over when first designing the product. This uncovers past solutions that may have different answers to it due to the passage of time. Fresh perspectives are always helpful.
There we have it. My case for why anyone, and everyone should pair. If your business can’t see the value, and wont fund a pair of designers for every product or value stream, the best you can do is to try to show them the value it could bring. Try doing this through finding time to pair with people on their projects as much as possible. I often view it as a continuum where there is no pairing, all the way to full time pairing. Depending on where you land on this continuum you may experience more of these benefits or less. But the more you do it, the more the benefits will show and the more the business may notice.
To conclude I say…
Recap List of Benefits:
- Balancing a Designers Toolkit
- Design Humility
- Lots of Feedback
- Knowledge is Easily Transferred
- It Promotes Learning Through Collaboration
- Provides Focus
- Provides a Deeper Understanding of the Design Process
- Forces Prioritization
- Reduces the Amount of Future Design Debt
- Teams are More Likely to Solve the Right Problem
- Designers Will Have a Higher Confidence in Your Design Decisions.
- Gives the ability to diverge, and then converge, increasing your pairs idea output.
- Output of the Teams Work Becomes Exponentially Better.
- Designer can Access Flow State Easily
- Designers are Held Accountable By Themselves (no micromanaging needed)
- Work Doesn’t Have to Stop When it’s Interrupted
- Keeping Work Flowing Reduces the Cost of Delay
- Teams and the Business has a Reliable Bus Count
- Allows new designers to learn the product and get up to speed quickly
- Allows rotation to bring fresh eyes and perspectives