The Role of Conflict in Design
- Jun 17, 2013
This is my definition of conflict:
Conflict is the way design teams come to a shared understanding of each decision made in the design process.
Over the course of this chapter, I’ll unpack this statement in more detail, focusing specifically on the phrases “shared understanding” and “decision made.”
Conflict is the engine of design. When designers come up with the initial idea, turning it over and over to make sure it solves the design problem, it is conflict that spurs that process. When designers take that idea and draw it out—fleshing out details, establishing a design’s basic concept—and then take it all the way through to a specification, it is conflict that drives that growth.
These are tough conversations, but they make all the difference in the final product.
I’ve sweated through countless design reviews—and the best ones are also the most challenging ones. Presenting design concepts to a room full of stakeholders and getting blank stares or empty nods is the bane of my professional existence. On the contrary, put me in a room where colleagues call me out on every design decision, demand a rationale for every typographic or layout choice, and throw out lots of new ideas. These are tough conversations, but they make all the difference in the final product.
Conflict is the process through which ideas are validated and elaborated. Through conflict, ideas grow from a spark to a concept to a full-fledged design because
- Conflict validates ideas: Designers working together seek to understand an idea fully, so they confront each other, forcing themselves to justify every decision. They challenge each other to ground their ideas.
- Conflict elaborates ideas: By talking over an idea and disagreeing with it, designers force each other to fill in missing details.
When ideas are tested and expanded to the satisfaction of all involved, this is when conflict works right. Design teams, however, sometimes find themselves in conflict that doesn’t move a project forward. Before explaining where conflict goes wrong, I’ll describe the important role conflict plays in design.
The Value of Conflict
To demonstrate the value of conflict clearly, I’m going to oversimplify the design process. Design is, in this oversimplification, merely a series of decisions (Figure 4.1).
Figure 4.1. Oversimplifying the design process, design is really just a series of decisions.
Decisions may be broad, such as decisions about scope:
- “We’re going to focus on how users navigate product categories.”
Or, decisions can be small, such as decisions about specific aspects of the product:
- “This button should say ‘Start.’”
Making one decision allows the design team to make the next decision. That is, they can tackle the next level of detail, the next element in the product, the next challenge facing the project. One decision leads to the next.
But as most designers have come to understand, one bad decision can have devastating consequences later in the project. A simple example is a decision that implies a convention in the design of the product, like “All buttons will be orange with a white label.” Make this decision when there’s only one visible button, and the team might think all is right with the world. Realizing later they have to design an interface with a dozen buttons, the team might regret that decision. They’re now faced with another challenge: Change the convention? Or establish a new convention for this circumstance?
The design process ends when the team has made sufficient decisions to define the product. That definition addresses all the established goals (decisions early in the project) and respects all the technical constraints (perhaps later in the project). That definition is sufficiently documented for a production team to implement the product. Design is therefore measured along two dimensions: quality and moving the project forward, which I’ll call movement (Figure 4.2).
Figure 4.2. Two dimensions define success: quality and movement.
Decisions made by the design team must do two things, then. A design decision must
- Be good. It meets the goals of the project, for example.
- Move the project forward. The decision brings the conclusion of the project into greater focus, further clarifying the product definition.
OK, so the design process is a series of decisions that increasingly defines the product and yields a good product. These decisions are made collectively by the design team. And the team cooperates to make decisions. Right?
Actually, that’s not true.
Not every member of the team contributes to every decision. Nor does every member of the team agree with every decision. But to move a project forward, all members of the design team must understand the decision. That is, they know
- Why the decision was made
- How the decision impacts their contribution
- How they can incorporate the decision into their work
Enter conflict. By working toward a shared understanding of design decisions, team members enter into conflict. It is through building a shared understanding around decisions that conflict manifests. That is, team members must understand how a design decision makes a better product and moves the project forward.
For example, a design team who has resolved their conflict can answer all these questions the same way (Table 4.1).
Table 4.1. Questions about Quality and Movement
Questions about Quality
Questions about Movement
Do you know how this decision addresses project goals?
Do you know how this moves the project forward?
Do you know how this decision can help improve the design?
Do you know what to do next?
Can you explain how the decision is appropriate to the project?
Do you know how this decision will enable (or impede) your next task?
Does this decision take the design outside the project’s boundaries or constraints?
Do you know how this decision moves the project closer to success?
A shared understanding is crucial for both design quality and moving the design process forward. To get aligned on these answers, team members conflict. It’s that conflict that allows them to acknowledge their lack of alignment and to work together to achieve a shared understanding.
When team members are not aligned, when they do not have a shared understanding, they can’t move the project forward or make the project successful. Teams can (and often do) gloss over the conflict, but the lack of shared understanding of these decisions will negatively impact them later. On the other hand, teams that take the time to align their understanding on design decisions will ultimately bring projects to conclusion successfully.
Design Decisions and Shared Understanding
There are two parts to any design decision: the content of the decision and the method used to make the decision. The content is what was decided, generally about the design of the product itself. The method may be a technique or a rationale. It answers the question, “How did we make this decision?”
In each of the following sample decisions, the content is italicized and the method is underlined:
- We won’t use tab-based navigation for this Web-based application because we anticipate growth, and tabs won’t scale well.
- We will incorporate context-sensitive help in the kiosk because most users won’t be experts on this process.
- We will prioritize information about travel conditions because usability testing indicated that this information was the most important.
In the last example, there could be any number of reasons to prioritize travel conditions, but the method chosen by this design team involved conducting usability testing.
This structure for decisions is an oversimplification. Digging into the underlying structure of a decision, between these two things, the content and the method, there’s a chicken-and-egg relationship. On the one hand, the content may not yet be defined, but the designer knows what he or she needs. That is, the designer knows to ask the question, “What information do I need to prioritize in this kiosk?” The designer then decides upon a method for answering that question: the content comes before the method. Once the designer determines the answer, that’s the content of the decision, and the method is what produced it (Figure 4.3).
Figure 4.3. The chicken-and-egg structure of decisions.
A team’s shared understanding rests on everyone understanding both the content of the decision and the method used to reach that decision. They need to be clear on the decision and aligned in their activities for getting there (Table 4.2).
Table 4.2. A Shared Understanding in Making Decisions
Aspect of Decision
Not everyone is going to agree with every decision (“creative differences“) but team members need to be clear on the content of the decision.
Not everyone needs to agree on how the decision will be made, but they do need to understand the method being used and how they contribute to it.
Note that clarity and alignment don’t necessarily mean agreement. People working on a project team may not agree with the direction set by their leads or managers. They may not agree with how those decisions are made. Designers bristle at arbitrary decisions (like unreasonable constraints in production or bizarre institutionalized business rules) but can generally get behind a decision if it’s clear and they know how it impacts them.
And this brings me back to the definition of conflict. Conflict is the way design teams come to a shared understanding of each decision made in the design process. Conflict in design isn’t always accompanied by negative emotions, hostility, or drama. It isn’t always about disagreement. Conflict is about two (or more) people trying to understand each other, paving the way for future decisions and ultimately the project conclusion.
What Happens Without a Shared Understanding
When teams work from a disparate understanding, they risk becoming further separated as the project progresses. They make decisions individually that seem misinformed or misaligned with the rest of the team. If the team doesn’t understand the boundaries of the design project, they will create concepts that are unrealistic or don’t solve the problem.
Good designers may purposefully break boundaries, seeking to challenge conventions or expose new ideas. But this boundary breaking is counterproductive if they do it in ignorance, naively thrashing about without first ensuring that they have a shared understanding of the assignment. Without being able to position it as boundary breaking, they are unable to tell the story of the design concept to their team or their stakeholders. A design decision that cannot be justified is not one that will move the project closer to its conclusion.
Misunderstanding happens most often with respect to design direction and design scope.
Lack of Design Direction
When designers do not understand direction, they lack clarity on the underlying principles that are driving the design. While not every design process will articulate these principles concretely, the lead on the project is responsible for ensuring that the designers understand them. Good leads help their design teams internalize them, such that they can make decisions relying on those principles. For example, a designer potentially wastes time (i.e., money) laying out screens for a Web site that don’t follow an implicit set of principles determined at the beginning of the project. The lack of shared understanding here might be from
- Misunderstanding the design direction: The creative director did not provide a clear set of principles to drive the design.
- Misunderstanding the constraints: The team didn’t clarify the project’s or the design problem’s boundaries, so the designer produced things that were hopelessly unrealistic.
Lack of Design Scope
A designer could waste time creating designs for the wrong thing. The design team can easily understand that the assignment entails designing a marketing site for a large high-tech product company. But perhaps they aren’t fully aware of which pages to focus on, or that they shouldn’t touch the site’s primary navigation, or that they can’t rely on certain product information being available.
Conflict can be uncomfortable for some people, but recall that conflict is good for design—it’s the engine that makes design productive. As the understanding of a project’s goals or direction diverges, that discomfort becomes more pronounced. Good teams detect and resolve conflicts as they arise. Yes, they understand the risk of not addressing conflict, but more importantly they know that the product is better for it.
Obstacles to a Shared Understanding
Some design teams hardly think of this as conflict; they are used to the dance necessary to achieve a shared understanding. Experienced teams with a good rapport can sense this shared understanding, or lack thereof, and know, almost at an intimate level, what it takes to resolve it.
Rarely do designers have the opportunity to work consistently in such an environment. Instead, new people and new challenges are injected into design jobs all the time. The conflict becomes front and center in these situations. Experienced designers understand they need to go through a learning process: they need to learn how to work with this new set of people.
But cultivating this rapport and empathy takes time. Until then, you may encounter obstacles that prevent you from engaging in productive conflict:
- Misconception: People may think they understand, but they really don’t. That is, they believe they have a shared understanding. Unless you can confront them—test their knowledge, so to speak—you won’t know for sure.
- Ego: People refuse to admit they don’t understand. Call it stubbornness, pride, or just plain old naive optimism; some people’s personalities prevent them from copping to their misunderstanding.
- Disinterest: People don’t care enough to figure it out. We’ve all encountered the colleague who stinks of that classic fragrance, “I’d rather be somewhere else.” Whether they are aware of their own lack of understanding, they choose not to clarify.
Reaching a shared understanding usually means overcoming these obstacles first, and then engaging in meaningful conflict—that is, conflict that produces useful decisions. But these obstacles produce a form of conflict in and of themselves—what I call “unhealthy conflict.”