Building a Cohesive Design Team

Design is a team sport. Look at any great design, even those designs with a strong designer personality as the hero/spokesperson, and you’ll find a team of people who made that design come to life.

(Even amongst the tiniest of startups, it’s rare a single person makes everything happen. And in those rare instances where it is a one-person operation, that never lasts for long. Success has a way of demanding help, and failure doesn’t need anyone.)

As we’ve been studying how to bring great products and services to market, we’ve learned the importance of having a strong, cohesive team. The most successful teams that repeatedly deliver great products share some interesting characteristics. Let’s explore some of the most important ones.

Defining the Team Inclusively

One question we found to be quite telling was when we asked, Who is on Project X’s design team? There were two types of answers. Either they’d say the design team consisted only of those people with the official title of Designer, or they’d give us a long list that included everyone working on the project without regard to their job title in the organization.

Inclusive teams make an effort to have people with non-traditional design jobs involved in the process. Several teams we talked with shared that their company’s legal counsel was part of the team, to ensure the presentation of compliance information was as well designed as possible. Among many teams, developers were considered design team members, even when they’d previously not played a part in product design. Some teams included key field management, like retail store General Managers, as they were rolling out integrated store and e-commerce designs.

When we looked at our data, we found a strong correlation between these larger, more inclusive teams and the teams that produced better designs. The teams that make everyone part of their design process benefit from getting the different viewpoints in place faster. Inclusive teams produce better results.

Designing with an inclusive team is not design by committee. In the inclusive teams, we saw a clear decision making structure in place. Early in the project, everyone knew who would decide what. (Apple, for example, has a well-publicized process that appoints a person as the DRI or Directly Responsible Individual for every aspect of the project.)

To decide who to include, the team looked at who would have influence over the final design. We found that inclusive teams recruited individuals within the organization that could change the user’s experience.

Building Up Skills; Ignoring Roles

Bigger teams bring more diverse perspectives, which work to the advantage of those teams. They can view the problems and potential solutions with more creativity and experience.

The most successful teams celebrated that diversity amongst its members. Yet those same teams didn’t let roles get in the way of getting things done. Someone else does that, was not a refrain we heard when we talked to the members of these teams.

We noticed the leaders of the most successful teams would frequently assess their team members’ skills. The leaders would go through the team’s roster and look at the total scope of what each individual brought to the group. The leaders would then assign training and practice activities to upgrade those team members with certain weaker skills. The entire team would go to classes and conferences together, talking about what they learned and how to apply it to the project at hand.

In many organizations, skill building is a secondary activity, done only when project work is in a lull. However, amongst the most successful teams, it was a primary activity that was scheduled with the project work. One manager told us, When the [team members] come back from training jazzed to apply a new technique, that’s when we see real benefits.

In order to bypass roles, the most successful teams would use techniques for facilitating discussions that equalized the power in the room. For example, using a technique like a KJ Analysis can get everyone’s thoughts on an issue, regardless of their importance in the organization. These teams reveled in collecting as many equalizing techniques as they could.

Deep Focus on the Problem

We uncovered another interesting difference between the most successful teams and all the rest: the proportion of the project time spent understanding the problem. We found the teams struggling to put out great designs often were the first to jump to a solution and run with it, without exploring other options. (The worst we saw were projects that started with a predefined solution as the sole requirement.)

Those teams delivering great designs spent more project time gathering information about their users and their challenges, and about what’s been tried in the past. These teams saw their initial design work to be less about coming up with the best solution and more about poking holes in their theories about why they were designing.

Interestingly, spending more time on the problem doesn’t seem to lengthen the overall project. In some cases, in fact, it can shorten it. By spending more time on understanding the problem, the team reduces the subsequent back-and-forth caused by uninformed opinion wars. Better understood problems means the team produces better designs, which means less work needs redoing because users didn’t like it or couldn’t use it.

Great design is about considering the problem’s subtlety and nuance. The most successful teams dig deep into the problem, using detailed scenarios that help define what users are trying to do. They apply potential designs to the scenarios, to see where there are still rough spots and complexities.

Develop a Common Understanding Through Language

Listening to each team, we noted some teams developed their own dialect. They were using special words and phrases, with meanings known only to them, that described particular things they had learned about the design.

Sometimes these words and phrases represented design principles the team had come to. Other times, the words represented things the team had seen in their research or problem exploration.

The bigger teams took great care to make sure everyone on the team understood the dialect. They would frequently share examples of what the words and phrases meant. This constant reinforcement helped show everyone the right direction to go in.

It was in critical design activities that the special language showed its value. When the team was working through design ideas in a design studio, or delivering critique on some facet of the design, the new language helped direct attention to the specifics of the design.

Researching Together

Research was another common characteristic amongst the most successful teams. While there were many teams that never did any research, or did very little, all of the most successful teams regularly executed some form of user research. This could be from quick, informal usability studies with rapidly produced paper prototypes or it could be a carefully executed field study.

Better designs emerged when each team member was directly involved with much of the research. This was easiest to accomplish when the team had trained almost everyone on basic research skills and techniques. They knew how to ask questions and observe participants to generate the best insights.

Because each team member had direct, repeated exposure to the users, they could bring what they saw directly to the design discussions. The team bonded around what they were seeing and this contributed to their understanding of the problem.

Building a Cohesive Design Team

Creating a design team is not much different than creating anything else. It starts with thoughtful intention. What kind of team do we want? What do we want that team to achieve?

When we sat back and looked at the attributes shared amongst the most successful teams, we were surprised at how unsurprised we were. We knew that exposure time to user research was critical. Being inclusive, focusing on skills, developing a dialect, and focusing on the problem were all things we intuitively knew.

What makes these findings most exciting is how actionable they are. Team leaders can take small steps in the direction of success without having to stop what they’re doing. That gives us great hope that we can see even the most dysfunctional teams start to improve themselves, and see better designs as a result.