Dan Brown

Dan Brown, co-founder of D.C.-based design firm EightShapes and author of “Communicating Design” and “Designing Together,” is fascinated by conflict — but not in the way you might think. Brown has spent years studying how and why conflict arises in the workplace, its centrality to good design, the differences between healthy and unhealthy conflict, and more.

Dan will be speaking at 18F on Friday, May 22 at 1:30 PM (RSVP here.) In preparation for his talk, we began an email exchange with him to get his take on several conflict-related topics — read on for the full conversation.


This interview has been edited and condensed.

18F: We’re all looking forward to your presentation and are keen to get your insights on conflict — how it arises and how it can be used to encourage collaboration. To begin our Q&A, how did you become interested studying and writing about conflict?

Dan Brown: About 10 years ago, I wrote the first edition of my first book, “Communicating Design.” After its publication, I gave lots of talks and workshops. In those sessions, the majority of discussion topics focused on the so-called people issues:

  • How to get people to read the documentation
  • How to get good feedback on the documentation
  • How to facilitate a conversation around the documentation

I always knew the documentation itself was incidental to the process, but those discussions clarified the real challenge. As I noodled on this for years, I realized that we face the same situations on every project. Yes, every project is different, but very few challenging situations are novel. For example, if I said to you “irrelevant comparison,” you’d know exactly what I was talking about. You’d think of that time you were working on a complex transactional site for a dental insurance company and some stakeholder said, “We want this to be like Apple.com.”

So, I did what any red-blooded information architect would do: I made a list of all the situations. I hit up my friends and colleagues and collected situations from them. I also realized that I was at a point in my career where I’d collected a set of techniques I use to defuse or redirect these situations. I refer to them as patterns, simple starting points for changing the conversation.

18F: What have you identified as the biggest source of conflict among design teams?

DB: It’s funny: I don’t think of parts of design as being a “source” of conflict. The process of design IS conflict. We have a negative association with conflict — something to avoid or solve or ignore. But conflict helps design: It is the means for coming to a shared understanding. To be effective, design teams need to be aligned around lots of things:

  • The core design problem
  • The conception of the target audience
  • The constraints of the project
  • The overall design direction
  • The criteria for making design decisions
  • The standard for quality
  • The rationale for design decisions

And so many more. If members of the team aren’t aligned around these — if they don’t have a shared understanding — they can’t move forward. They operate at cross-purposes. But it takes effort to get that alignment.

The hard part to grasp is that “shared understanding” doesn’t necessarily mean “agreement.” Design processes involve decisions and teams can’t be effective if they’re trying to build consensus around every decision. So, I may not agree with the art director’s choices around the brand identity, but I can’t do my job effectively if I don’t understand them.

18F: Are you of the opinion that all conflicts can be resolved and transmutated into positive experiences, or are there any types of conflicts that are a lost cause — that participants simply have to walk away from?

DB: Great question. While I do emphasize that conflict is the engine of design, I also know that not all conflict is created equal. We lump the good conflict and bad conflict under the same general heading, so I’ve distinguished them as healthy and unhealthy conflict. With healthy conflict, the participants have a goal. They have a set of objective criteria for judging outcomes. They have a format for engaging in conflict. These may not be formally documented or acknowledged, but when you’re in a design review, there are unwritten rules for how that works. The conversation that proceeds from the design review, presuming people follow those unwritten rules of engagement, is healthy conflict. They can become passionate. They can nit pick every decision. But if their motive is achieving great design, and that motive is implicit in their behaviors, that conflict is the stuff design is made of.

Unhealthy conflict is conflict for conflict’s sake. It’s personal. It’s counter-productive. It doesn’t contribute to the design process.

Sometimes healthy conflict masquerades as unhealthy conflict. I see this when stakeholders don’t have the right language for critiquing a design, or talking about specific design decisions. They lash out because they don’t have the words. (Parents of toddlers may recognize this behavior. I believe we retreat into immature behavior when we don’t have the cognitive tools to participate in challenging activities.) It’s hard not to take that stuff personally. Even if you know there’s no force behind the words, they can still distract you from the task at hand. The patterns I mentioned earlier are some of the tools I’ve used to deflate those conversations, to transform unhealthy conflict into healthy conflict.

18F: During the last 10 years, what shifts have you noted in our (collective) ability to collaborate, if any? And what might be the causes of said shifts?

DB: I wouldn’t presume to speak for the entire industry. Each person has their own issues to overcome. That said, the nature of our work has changed, and that change puts new pressure on our teams. Since my start in the Web business 20 years ago, I’ve seen websites become far more complex. That complexity requires more elaborate planning and more roles. We need to coordinate many more activities and potentially many more people.

We’re already stunted when it comes to collaboration: This isn’t a skill taught in school. You might get thrown on a group project, but no one explains how to get the group aligned, how to assign responsibilities, how to check in, how to communicate status, and countless other behaviors that make teams effective.

18F: To wrap up, what one piece of advice would you offer a new designer?

DB: Buy my books.

Just kidding. Everyone who answers these questions says that, right? No? Just me?

Designers need lots of skills — people skills, leadership skills, technical skills — but where I see the biggest gap is self-awareness. There’s a general reluctance to admit our own shortcomings. Yes, any skill can be learned, but experience shows that we’re all wired differently, and those differences give us different abilities. I can code, but I don’t because there are people who are much, much better at it than I will ever be.

This extends beyond technical skills, however. Over the years, I’ve come to recognize what situations make me uncomfortable. Moreover, I’ve been able to admit that to my peers. This isn’t weakness: It builds the strength of the team. Understanding where you contribute best and where you need help can drive the planning of a project. Projects stumble because someone is unwilling to admit that they’ve hit their limit on something. Teams falter because someone is incapable of seeing how they’re causing obstacles.

By being self-aware, you can confidently ask for help. And, ultimately, this is the real test of a team, the real essence of collaboration.


If you’re unable to attend Dan’s presentation in person, consider joining us via Hangout. We’ll tweet a link to the livestream just before the event — be sure to follow @18F on Twitter so you don’t miss it!