Who Is on the UX Team?

by Jared M. Spool

When we talk to executives about building out their user experience teams, the first question we’re asked is “who should be on the team?” To answer this question, we studied two types of UX teams: those that are successful at delivering great designs and those that struggle at it. We wanted to see what was different about each type of UX team’s make up.

Embracing the Extended Design Team

The first big distinction between the struggling and successful teams was who they considered as part of their team. When we asked folks who was on their team, the members of the struggling teams limited their list to the other designers they worked with directly.

The successful team members, however, went beyond their immediate circle of designers. They included people we wouldn’t normally associate with design work—the developers, product managers, QA folks, support personnel, and even executives.

While the struggling teams looked only to their nuclear design team, as it were, the successful teams were embracing a larger, extended design team. The extended design team included anyone who made decisions that inevitably affected the outcome of the design and the experience of the users.

For example, one team listed their assigned corporate lawyer as a team member. This lawyer was deeply embedded in the team, sitting in on various design meetings and participating in the online project management forums. When it came time to integrate legal constraints into the design, the lawyer already understood the underlying philosophies and design objectives, and could frame the constraints in those terms. The team also sought to understand the lawyer’s objectives, working collaboratively to create the best design while protecting the company’s legal interests.

The Extended UX Team-of-One

One of the more interesting findings from our research came from the UX Team-of-One folks—individuals that are the sole user experience professionals in their organization. We expected these individuals would have a different team strategy from the larger groups.

What we found, however, was that the successful Team-Of-One individuals were also embracing a larger team to get their work done. They found they couldn’t control every UX decision. To get the best designs, they needed to give the design influencers the right information to make smart decisions.

Emphasis on Skills and Information

If we asked a struggling team manager to describe who was on their team, they almost always answered like this:

We have two information architects, an interaction designer, and a user researcher.

Their answers were almost always centered on the roles of the team members. The successful team managers rarely used roles to describe their team, instead talking about the skills the entire team embodied.

Our team handles the interaction design, information architecture, and user research for the product.

It’s a subtle difference, but an important one. We’ve found the teams that look more towards cross-individual skills are better at producing great designs, giving the team more flexibility.

We also noticed a difference in the attitudes towards training and skill improvement. Teams that weren’t role focused had better programs (both ad-hoc and formal) to improve skills across the team. They had mechanisms for identifying individuals who could benefit from training. They were actively mentoring team members in new skills and sending their folks to workshops, conferences, online seminars, and other training resources.

These attitudes towards training extended beyond the nuclear design team. We observed a culture of learning, through simple, low-cost techniques like brown bag lunches, book discussion groups, and group webinar attendance, which permeated through the extended design team. Everyone was developing a common vocabulary and understanding of what design is and how they could do it better.

Co-location Is Key

One surprising finding was, in our limited sample, that almost every successful team was in a single location. There were many examples of distributed teams amongst the struggling teams, but we only saw a couple of successful distributed teams.

Remote teams deal with more complications to the design process than co-located teams. When people are in the same room, they have a higher bandwidth communication path, which helps them have better conversations faster. It’s easy to put post-its on a wall, share sketches, and critique ideas when you’re just a few feet apart. Doing all that through time-shift electronic channels is difficult, if not near impossible.

Producing great designs is difficult enough without having the added complications of trying to do it with a remote team. Mentoring, cross-discipline training, and the other facets that seem to contribute to the growth of the successful teams are much harder with remote teams.

The few successful remote teams we saw were remote from day one and everyone was spread apart. Hybrid teams, where some of the team is in a single location, have to be careful. Their discussions and activities that the remote members aren’t party to may distance them even further.

While it’s possible to make a remote team succeed, it seems to us that it won’t happen by itself. Special care of the team dynamics is critical. The few successful teams we saw had regularly scheduled in-person meetings of the entire team several times a year. They used these opportunities for group training and intense design discussions.

Who is on Your UX Team?

We often talk of “growing our teams,” using a biological metaphor. What we’ve found in our research isn’t far off of this idea. Those that ended up amongst our successful teams seem to be carefully cared for, by every member.

What we take from this is simple: look beyond your nuclear team to the other folks influencing the design, create a learning culture where everyone is picking up new skills, and focus on the high-bandwidth communication about the design, the users, and what you’re trying to do. It all seems obvious, but we’re surprised at how many teams aren’t doing this.

Published here on June 2, 2011.