The U in Team

13 Principles of Effective Design Teams

This post is repurposed from my book Designing Together: The Collaboration and Conflict Management Handbook for Creative Professionals. I was inspired to dig it out by Peter Merholz’s recent post on principles for great design team. I’ve made some edits here from its first appearance in 2012, but the principles themselves remain intact.

A design or product team is more than just the people on it. A team includes the people, the roles they play, the team members’ objectives, the tools and methods they use, and the project structures in which they operate.

Within each of these four elements, there are principles that establish parameters for success — the underlying factors that make some teams work better than others. They influence whether a team is positioned to take advantage of collaborative behaviors and whether they’re set up to make the most of conflict.

ROLES AND RESPONSIBILITIES
Project teams almost always assign roles to team members. These roles come with responsibilities, the set of tasks and activities different people participate in. My experience indicates that most design teams normalize on four general categories of people on design teams:

• Designers: People responsible for generating and documenting ideas about how the product works, looks, or behaves. In many areas of design, there are designer specialties. A project may require more than one specialty. One of these people may be designated as the “lead,” the person who owns the creative vision.
• Managers: People responsible for ensuring the project team delivers on its obligations, creates plans to do so, and successfully executes against those plans. Different projects assign the manager role differently: some consolidate it with the lead designer, and others separate it.
• Subject Matter Experts: People — sometimes designers, sometimes not — responsible for contributing information to the design process. These may be people who are the users of the product itself or who have some special insight into the users or the project constraints.
• Stakeholders: People ultimately accountable for the success of the project. They hold the purse strings and become the ultimate internal owners or champions of the product.

The roles themselves are interesting really only on the surface level and, at least in the world of Web design, have been examined ad nauseam. For me, the principles governing how people are assigned to a project are more interesting.

1. The Principle of Multiple Hats

The people on a project may play multiple roles, but too much consolidation of roles can compromise the value of collaboration.

Roles and people do not have to be one-to-one. A single person may play as many as three roles: design lead, designer specialist, and research assistant.

That said, some roles don’t mix well. Successful projects don’t usually allow a project stakeholder to also be a designer. This isn’t to say never in the history of the world has a designer been a business stakeholder on a successful project. For the most part, however, teams value distinguishing a “design” perspective from a “business” perspective.

2. The Principle of Minimal Internal Risk

The people on a project should not introduce any additional risk to the project based on their personality traits, working styles, or preferences.

Projects encounter so many risks from external factors that they should avoid further risk through the personnel assignments. External factors introducing risk include changes to requirements, goals, priorities, or parameters.

Personnel assignments can introduce risk when bringing on people who are incapable of doing their assigned tasks. Personnel assignments also introduce risk when using people who struggle to deal with certain known project parameters, like the inability to juggle multiple projects.

3. The Principle of Professional Growth

The people on a project should find the project fulfilling because it introduces challenges that help them grow.

At minimum, designers expect every project to add an entry to their port- folios. Their participation in a project holds at least that appeal, if not more based on the type of work they get to do.

4. The Principle of Ownership

Ownership — a contributor’s feeling that he or she has a stake in the success of a project — helps team members understand their purpose on the project.

People like knowing their roles because they explain their purpose on the project. They feel more committed to a project when they have areas carved out for them to own and drive.

5. The Principle of Diverse Composition

Project teams succeed when people who bring diverse perspectives and approaches can work toward a common goal.

The simple truth is that projects require a lot of people, and everyone is different. While its easy to point to diversity as potential weak points in a team composition, different perspectives bring even greater strength to a team.

GOALS AND PRIORITIES
Project goals not only entail the end state for the project — a product defined, design specified, a campaign launched, a building built — but also the change made in the world.

6. The Principle of Meaningful Mark

People like working on projects that are going to make a difference in people’s lives, no matter how small the consequence.

The portfolio value of a recognizable consumer brand may be tempting, but designers also like telling a good story about designing a volunteer management system for their favorite nonprofit. Most designers I’ve met prioritize making a difference in people’s lives over other kinds of rewards.

7. The Principle of Personal/Professional Alignment

People derive more professional satisfaction from working on projects that align with their own beliefs.

Design teams sometimes take on projects that, though meaningful, have the right impact on the wrong people. Or the wrong impact on the right people. Such political views may be personal, but they can influence the team’s satisfaction or sense of reward from working on the project. Great design that serves the wrong purpose may not feel like great design at all.

8. The Principle of Discounted Novelty

Designers don’t like to work on “new stuff” as much as the world thinks they do.

Though designers have a reputation for preferring to work on high profile consumer brands and radical product ideas, most designers just want to do interesting work. That means complex design challenges for the benefit a specific target audience. Even working on an internal application for two dozen claims processors at a small dental insurance carrier is appealing when it makes a significant impact on their day-to-day job satisfaction.

TECHNIQUES AND METHODS
A team is defined by the tools it uses to solve design problems, including:

• Methodologies: Schools of thought or design philosophies that drive the approach teams take to meet project goals.
• Processes: Step-by-step flows of activities that define what the team pro- duces and how team members reach their goals.
• Techniques: Activities to achieve specific outcomes, like user research or design studio.

9. The Principle of Appropriate Activities

Projects should use the right techniques for the right activities.

Every activity should clearly move the project closer to its goals. As self-evident as this principle is, many design teams structure their projects around activities they always do without considering the specific objectives of the project.

10. The Principle of Novel Use

Projects should challenge the team to configure existing techniques for new situations.

Good tools have levers you can adjust for various situations. Such levers on a technique vary depending on the type of activity, but could include

• Scale: How big you make the activity
• Formality: How formal the output is
• Depth: How detailed the team gets
• Participation: How much participation is expected from outside the core team
• Dependencies: How much the technique relies on other activities or outputs

For example, user interviews are a common technique in Web design to capture user needs. User interviews permit a wide range of novel applications. The basic activity remains the same — talking to the target audience — but there is flexibility in the number of users, what you talk to them about, what prompts you use in the interview, the people who participate, and how the data is analyzed.

PROJECT PARAMETERS
Project parameters are the array of constraints that establish boundaries for the project. They generally fall into one of three categories:

• Scope: Product-specific boundaries or requirements, like which parts of the product designers should focus on. In the case of Web designers, projects are typically scoped in terms of Web pages or aspects of an application, or features.
• Time, money, and geography: The “physical” constraints of a project, like how much money can be spent and when it’s due.
• Context: The arena in which the product will appear. This can be technical, like a particular network of servers; or physical, like a building site; or virtual, like the area of an organization that will get a new business process.

Great teams will ferret out definitions of these parameters in the earliest stages of a project.

11. The Principle of Full Definition

The project parameters should be fully defined as early as possible in a project.

The better defined the project parameters are at the beginning of a project, the more effective the design team will be. Design teams forced to deal with shifting project parameters take energy away from solving the design problem. In such situations, teams find themselves retrofitting once-great solutions into spaces made for a different solution entirely.

12. The Principle of Reasonable Constraints

All parameters and boundaries should make sense and aren’t arbitrary.

Designers thrive when the design challenge has constraints [what I’ve called enablers elsewhere]. But arbitrary constraints, those that don’t have a legitimate grounding, just cause frustrations. Nothing is more irritating than seeing an obvious solution for the design challenge, only to find it’s just out of reach because of some silly business rule or technical issue.

13. The Principle of Parameter Flexibility

Project teams will measure the flexibility of a project parameter on a scale, not as “yes” or “no.”

Constraints should not be totally immobile. Successful projects depend on varying degrees of wiggle room on at least some constraints. For example, deadlines and milestones may have fixed dates (binary) or reasonable ranges (First half of June).

This excerpt was lightly edited from Chapter 1 of Designing Together, which has much more on team dynamics, collaboration, and conflict management.

The heart of Designing Together is a set of several dozen essential behaviors for collaboration and dealing with difficult situations.