Design as a conflict resolution tool

When faced with interpersonal issues at work, I'm leaning on the same techniques that are useful for designing for end users.

At its core, a design process basically has three steps:

  1. Learn everything you can about your audience.
  2. Generate possible solutions.
  3. Pick a solution and iterate on it.

A common mistake is to skip to the 3rd step before tackling the first two. That is, we skip to feature requests. For example, "Hey! We need a PDF export of that report."

I've learned to always ask "why" when confronted with feature requests. Why is the audience trying to achieve? What's their context? What possible solutions exist?

In matters of people, though, I've started to discover that the same instinct is necessary. A few times, I've noticed that someone's work doesn't match what I expect. I figured it would be best to give feedback as bluntly as possible. "You aren't doing what I want. Do it better."

Having gone down that road a couple of times, I saw a pattern. I'd hurt the feelings of the person I gave feedback to. They'd react with anger and frustration. And I'd find myself backing up to step 1 and just calmly listening as my colleagues told me why they were upset.

And then I started to learn. My mental model of what they cared about was wrong in some significant way. As often happens with users, their mental model of themselves was wrong too. I couldn't just skip to step 3 and do what they asked for.

The same principle applies to me too. I'm not always clear about my own motivations. What I ask for doesn't always reflect what I really want.

When it comes to troubleshooting personal conflicts, I'm learning to seek clarity, both in what I ask for and in what others ask of me.