Cross-functional pairing
with User Experience Design
This is about the productivity boost of two people with different skill sets working as “driver” and “observer” together. This boost is counter-intuitive because traditional logic wants us to believe that two people working on one task is slower than two people working on different tasks. It is ingrained in us from a very early age to silo our work but having worked both ways on many projects—I can tell you there is much to be gained by pairing and one of those things is speed.
This kind of collaboration that can collapse traditional process delays of weeks or months down to hours or mere minutes. How? To contrast old and new, think for a moment about part of a project as a game of ping pong:
- Designer makes a spec document (ping)
- Specs get reviewed and feedback is sent (pong)
- Designer updates specs (ping)
- Developer takes first pass at implementing specs (pong)
- Review and feedback from designer (ping)
- Developer takes second pass (pong)
- and so on, and on, and on…
This is a very slow game of ping pong.
Traditional process has us separating everything and filling in the cracks with overhead. We meet, we talk, then we go away to work in isolation before either sending documents or meeting again. Weeks can go by with only design documents and/or un-releasable code to show for it. Participants are waiting for one another far more than collaborating.
Pairing = faster ping pong
Cross-functional pairing has a designer and a developer take tasks and work on them together in real-time. The pings and pongs become an actual conversation as work is getting done. Silo walls melt away to allow better understanding of each others’ work, which leads to even more streamlined interactions while pairing. The pauses, waiting, and overhead previously spent formulating feedback and documentation are no longer necessary.
At the end of each pairing session, the team is one step forward with no steps backward (reviews, revisions, etc.) to take. The design or implementation is DONE when it’s done.
And it’s still faster? How can this be?
The best way I can summarize why this works is to refer again to this fictional chart and to say that:
There is wisdom in considering not how an individual spends their time but how the team spends their time.
“…how the team spends their time.” is a difficult bridge for many people to cross, especially when they’re used to the status quo. It doesn’t mentally compute that paying for two professionals to do one task will result in an overall savings of time and thus, money. I know from experience that it works but it’s hard to try it in the first place—whether it’s your time or the time of your employees that is on the line.
The reasons why it works is because pairing can take care of several things that I think are critical for projects to achieve their budgets:
- Quality — shipping designs without flaws and code without bugs takes far less time with pairing. The time it takes to identify and address the change (or make the change themselves) right there is always going to be less than with the overhead of documents and scheduled meetings. Also more mistakes get caught and corrected as they happen when there’s two sets of eyes on the work. The actual quality of each participants’ work goes up with pairing. Less/no bugs to fix later is a huge time saver.
- Focus — when people pair, it’s a more intense and focused activity than people tend to do on their own. All kinds of interruptions, internal and external, are kept away while pairing. Both people but especially the driver exhibit more discipline and are in a greater state of flow than ordinary. The focus is often so intense actually that it is recommended to take breaks after every 25 minutes of paring in order to make it sustainable.
- Empathy — an often overlooked factor in effective collaboration is having team members actually understand the concerns of one another. When you pair with someone, you see everything that goes into their work and you hear them talk about why they’re doing each thing. You find out what is difficult vs easy and details that never come up in any other context. You discover things you can do to make their job easier and vice versa. You learn what matters to them. The more you both learn, the faster you go.
- Prediction — people who pair get rapidly better at predicting what options or choices are going to appeal to each other and stakeholders. These decisions happen faster and the results get more appropriate because diverse insights can be part of each task.
- Trust — another often overlooked ingredient that can seriously slow down multi-person projects is lack of trust. Pairing allows you to know exactly what your co-worker can do and how they do it. This knowledge results in better trust for what you can do for each other in the future. Time can be used for building on each others’ foundations, vs double-checking and second-guessing.
- Ownership — the more people pair on a task or project, the greater the feeling of ownership becomes collective. They both/all materially contributed to each step of creating it, so they all take responsibility for each step. Buy-in becomes essentially automatic which makes work flow more seamlessly as it switches between skills.
Who can I as a designer be pairing with? What are the benefits?
UX + Developer = Technically feasible design & Friendly implementation
UX + Tester = Designs more testable & Tests match design evolution
UX + PO/PM = Designs meet biz objectives & Objectives more friendly
UX + Subject Matter Expert = Better informed designs
and don’t forget Community of Practice Pairing:
Senior UX + Junior UX = Bi-directional knowledge and skills improvement
So why doesn’t everyone do this already?
There are many barriers to this kind of working style. Some of them are the cultural norms that I mentioned earlier and some of them seem very personal. For instance:
The “meat grinder”
There are hundreds of rudimentary activities we do every day; things that are part of our work but not what we’d choose to show about our work. Most of these activities we assume ‘No one but me should have to see this’ because work in progress is considered scary and/or boring for others to see.
We’ve found though that those kind of assumptions aren’t helpful. Basic activities of work in progress are exactly the things we need to do in the presence of a co-pilot! Something as simple as naming a file can either smooth the road ahead or cause cumulative hours of confusion (or needless domino effect bugs) as work gets passed from person to person.
The comfort zone
The traditional way seems normal and comfortable. “Everyone” does it. We feel good about having time to focus in isolation, working “in the zone” and going with the flow. It makes us feel like our individual time is well spent on achieving our goals. It seems less risky, potentially embarrassing, or even likely to feel “weird”.
The problem is that this personal benefit comes at the expense of our projects. Team time is more important than individual time and nothing truly great was achieved by someone who stayed within their comfort zone. So step outside of that and try something new. Risking comfort to ship a better product shouldn’t really be something holding you back.
What am I looking at?
We often think we need to be able to understand everything a person does in order to work with them. This is not true. While you won’t understand every single thing they’re doing, you will understand as I said-what matters. What is easy, laborious, enjoyable, and stressful. This is some of the most important information to learn while pairing.
Further info
While this work style can be done in any workflow — it fits especially well with Agile methodologies that do a lot to alleviate many pit-falls with working closely with individuals. Specifically for Experience Design / UX professionals, it is one of several Agile UX Practices I’ve collected to utilize for more successful projects and empowered teams.
Originally published July 7, 2013 while I was working at SolutionsIQ.
