Experience Design and Cross-Functional Pairing

User Experience (UX) Design and Usability is often considered something that either a) happens before features are created, b) is bolted on after features are created, or c) happens however the development team decided to create it anyway. That’s unfortunate, because neither A, B, or C are recipes for a good product — but there are other ways to go about it.

In a small but growing number of teams, User Experience Design is thought of as an integral part of development activities, taking place throughout each cycle from idea to shipped product. If you’re asking yourself, “How is this possible, to design while engineering is taking place?” then I’d like to introduce you to an Agile practice we call Cross-Functional Pairing. It’s an activity where two people with different skill-sets work on something together, one “driving” and the other “observing,” knowing that the driver and observer may switch at any time. People might think “different skill sets” means an Info Architect and a Content Strategist, but that’s not different enough. While all kinds of pairings are valuable, an Info Architect pairing with a Java Developer provides a certain kind of collaboration that can collapse traditional process delays of days, weeks, or months down to mere minutes. How? Before I contrast old and new, think for a moment about a game of ping pong.

Traditional Process

Traditional process has us all working separately in what are often called silos of expertise. We meet, we plan, then we go away to work in isolation before meeting again or sending documents. It seems normal and comfortable. It allows us to have some privacy in our work, and it keeps people from getting alarmed by seeing “the meat grinder” of work in progress. We feel good about having time to focus alone “in the zone.” The problem is that this makes for a very slow game of ping pong.


For example: developer makes a prototype for a week (ping), prototype gets reviewed for a day (pong), then UX designer makes a giant spec document for two weeks (ping), then specs get technical review for a few days (pong),designer updates specs for a few days (ping), developer takes first pass at implementing specs for a month (pong), review and feedback from designer for a few days (ping), developer takes second pass for a few days (pong), and so on.

Weeks can go by with only unreleasable code and design documents to show.

Cross-functional pairing

Cross-functional pairing takes a different approach. A designer and a developer take a portion of work and work on it together, at the same time, looking at the same tool (screen, whiteboard, etc.). In contrast to the previous scenario, the prototype is built with the designer’s input in real time; design sessions can be woven in as decisions points are made; less documentation is necessary because they both have more of a shared vision; “review” happens in seconds as they pair, and at the end of a normal development cycle they should have something shippable to show. Very fast ping pong, but what makes it work?


What many teams are finding is that all those rudimentary activities we do every day—the things we think, like “no one but me should have to see this”—those 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. Seeing everything that your team member is doing also lets you understand their needs better and build trust, even if you don’t understand every single thing they’re doing.

We’re also finding that the isolation that makes us feel like our own time is being spent well is often benefiting us at the expense of our project. In other words, we need to think of how our team is spending time—not how each individual person is spending time. It’s a difficult mental bridge to cross, sacrificing “your time” to watch someone else work, but it leads to shippable products sooner. The reason that happens (especially for UX people) is the very rapid ping pong. The time saved by forgoing reviews and not communicating through documents is enormous compared to the time spent pairing.


So how does this break down across different areas of expertise, or functions? What are the specific benefits beyond project time and domino bugs? I’ve been expressing it this way:

UX + Developer = Technically feasible design & Friendly implementation
UX + Tester = Designs more testable & Tests match design evolution
UX + Business = Designs meet biz objectives & Objectives more friendly
UX + Subject Matter Expert = Better informed designs
UX + anyone =

    • Fewer mistakes and oversights
    • More focus and discipline
    • Collective ownership and interpersonal cohesion
    • Better prediction of pairing partner needs and goals

Related to this is general pairing between people with similar functional skill sets, what I’ve been calling Community of Practice Pairing:

Senior UX + Junior UX = Bi-directional knowledge and skills improvement

…and Agile

While this work style can be done in any workflow — I leaned toward this style long before I’d ever heard the word — it fits especially well with Agile principles and technical practices. Agile methodologies alleviate a lot of the potential pitfalls of working so closely with individuals. That’s why I and many other Agile UX practitioners consider Cross-Functional Pairing one of several important Agile UX Practices to utilize for more successful projects. My continued work at SolutionsIQ and collaboration here with Anders Ramsay is focused squarely on empowering Agile teams.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.