Cross functional pairing

When many teams think of User Experience (UX) Design and Usability, it's often considered as 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 some rare but a growing number of teams, this kind of 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 can 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. Many people might think "different skill sets" means an Info Architect and a Content Strategist but that's not different enough. While all kinds of pairing 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, 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.) Contrasting to the previous scenario, the prototype would be getting 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: '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 the us at the expense of our project. In other words, we need to be thinking 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 because of 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 =

  • better quality and fewer mistakes
  • 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've leaned toward this style long before I'd ever heard the word—it fits especially well with the Agile Principles and Technical Practices. Agile methodologies alleviate a lot of the potential pit-falls with working so closely with individuals. That's why I and many other Agile UX practitioners consider Cross-Functional Paring one of several important Agile UX Practices to utilize for more successful projects. My work at SolutionsIQ and collaboration with Anders Ramsay is focused squarely on empowering Agile teams.

{{ message }}

{{ 'Comments are closed.' | trans }}