- The Value of Conflict
- Healthy vs. Unhealthy Conflict
- The Nature of Resolution
- TL;DR
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Nature of Resolution
The next two chapters discuss techniques for assessing difficult situations and coming to a shared understanding. The conclusion of those two things—figuring out what to do and then doing it—yields resolution.
Within the context of a “shared understanding” definition, resolving conflict means achieving a shared understanding. In creative conflicts, there are five kinds of resolution. That is, after a conflict there are five ways people come to a shared understanding:
- Persuasion
- Iteration
- Perspective shift
- Deferred decision
- Common ground
No one type of resolution is better than the other. It’s not like persuasion will always lead to the best design or a deferred decision is always bad. The value of a resolution is determined by the situation and the ultimate outcome.
These types are inventoried here to help teams carve a path toward resolution. By understanding the situation and prioritizing the conflict, members of the team can behave to achieve a particular resolution.
To explain these different kinds of resolutions, I’ll use a sample scenario throughout, showing how different decisions might be resolved:
- Dan and Nathan are collaborating on a web design project for a large publication. The publication has thousands of articles already published online across three different Web sites. Ostensibly, these sites are geared toward different audiences. The scope of the assignment is huge: the publication has asked them to redesign the user experience from the ground up, integrating these sites.
Persuasion: One Adopts the Other
Persuasion is when one person convinces another person to adopt his or her position.
Example: Dan and Nathan have two different ideas on how the publication should be organized moving forward. Dan believes the publication should eliminate the three separate properties. Nathan believes that the publication should preserve the distinctions. After discussing it, Nathan convinces Dan that preserving the separate properties makes the most sense given project constraints.
Iteration: They Reach a Compromise
Iteration happens when participants discuss their ideas, revising and refining them to the point where a new idea emerges.
Example: Dan and Nathan feel pretty strongly about how to organize the new site. After trying to persuade each other, they spend half a day sketching different ideas. (They invite Jody and Veronica, too.) After several rounds of sketching, a new concept emerges. There are aspects of Dan’s original idea and Nathan’s original idea, but this is a new one altogether.
Perspective Shift: One Looks at It Differently
When one person shifts his perspective, he chooses to look at the situation differently. By doing so, he is more willing to adopt another person’s position. This isn’t so much persuasion (as the first person isn’t convinced that the position necessarily makes sense) so much as letting the process take its course.
Example: Nathan has sketched some ideas very early in the project and wants to show them to the client. Dan worries that showing too much too soon will compromise the design process. He believes they need to iron out more of the underlying architecture before exposing the client to screen design ideas. Nathan worries that showing the client abstract drawings of Web site architecture will cause them to “spin” needlessly. Nathan decides that though he doesn’t believe the process works better this way, giving Dan a chance to share architecture drawings will help him learn more about the client.
Deferred Decision: They Decide to Hold Off
When participants opt not to make a decision at all, they are deferring the decision. This may seem like the easy way out, but responsible teams understand that decisions deferred now turn into challenges later. Responsible teams also understand when they don’t have enough information to make a decision. Deferring decisions makes sense when the team recognizes that they need more inputs.
A deferred decision is toxic when the team is simply incapable of making a decision. Deferred decisions are productive when everyone willingly decides to “sleep on it,” and they have a rationale for doing so.
Example: Having zeroed in on the overall structure of the site, the design team needs to make a decision about the underlying navigation. While users will have several ways to filter articles, the team recognizes that they need to prioritize one mechanism as primary. They’re torn between a content type approach (long form versus short form, for example) and a topic approach (environmental news versus medical news, for example). Dan and Nathan weigh different approaches, realizing that they don’t have good criteria for making a final decision. They defer it, giving Dan the action item to comb through user research to identify potential inputs into the conversation.
Common Ground: They Agree on Something
Coming to common ground means going back to fundamentals that everyone agrees on. By reeling back to those items everyone has in common, the design team sets the stage for exploring the decisions again.
This is, in a way, a form of deferred decision. Instead of acknowledging the need for further inputs, though, the team acknowledges that they are at an impasse because they can’t agree on anything. Finding some mutually agreeable starting point gives the team the right mindset for seeking out some solution. At best, it creates a platform for building together, and at worst, it helps them identify where their paths may diverge.
Example: Dan and Nathan decide they can’t resolve their conflict, acknowledging that the problem may be more fundamental. As they’re talking, they open a document that describes the project charter. They review each of the project’s goals, design principles, and high-level requirements. They reaffirm their agreement on these and their respective prioritization.
Evaluating Resolutions
Describing the nature of the resolution is helpful for planning your response to conflict. But none of these descriptors offers a value judgment. How do you know if a resolution is good?
At the beginning of this chapter, I defined the criteria for design decisions. A good design decision must be good and move the project forward.
Resolving conflict is one way of making a decision. Therefore, a resolution can also be evaluated by these criteria. Mapping possible resolutions to these two criteria, there are four possible outcomes (Table 4.5).
Table 4.5. Two-by-Two of Resolution Outcomes
|
Movement |
||
|
|
Good design, poor movementSome resolutions lead to good design ideas, but don’t actually move the project forward. Think: sketching over and over again, burning away budget and schedule, while crafting the perfect experience. |
Good design, good movementThese resolutions produce good design ideas (meeting the goals of the project) and get the project closer to completion. Think: project team that knows what they need to do to solve the design problem and move forward. |
|
Quality |
||
|
|
Poor design, poor movementThese resolutions do not solve the design problem, nor do they represent meaningful steps toward the project conclusion. Think: generating lots of crap, and having no clue about how to move things forward. |
Poor design, good movementSome resolutions yield poor design decisions, yet successfully move a project forward because they hit the “gates” of the project plan. Think: producing a comprehensive set of specifications that describe an utterly unusable design. |
These are the criteria by which you should be judging the outcome of your decisions. To revisit some of the examples, let me elaborate on how they might be good decisions (Table 4.6).
Table 4.6. Example Resolutions
|
Resolution |
Is It Good? |
|
Nathan persuades Dan to separate the publication into three separate properties. |
Quality? The decision adhered to the project goals and requirements. |
|
|
Move forward? The decision allowed the team to elaborate on the design further. |
|
Nathan changes his perspective and agrees to let Dan share architecture artifacts with the client. |
Quality? This is a resolution about process. In this case it is good because it will adhere to client expectations. It avoids potentially confusing them. |
|
|
Move forward? While it doesn’t move the project as quickly (Nathan’s objection), getting feedback from the client will help the design team understand the client’s disposition toward certain kinds of design conversations. |
|
Dan and Nathan decide to defer the decision about the underlying navigation. |
Quality? It’s too soon to judge, but they opted to gather more information before making a commitment. More information will help them determine what is good. |
|
|
Move forward? By deferring the decision, they arguably kept the project stagnant. They understood the risk, however, and chose that path rather than making a hasty decision that was difficult to undo. |
So specific kinds of resolutions do not necessarily lend themselves to bad outcomes. Ultimately, the circumstances (not the type of resolution) determine whether a decision is good or not.