Why do we call them “soft” skills when they are honestly so hard?

As a designer, one of the most powerful tools we have is the ability to navigate disagreements amongst our team. Keeping a level head is easier said than done. Emotion, opinion, and a buildup of bitterness from frequent disagreements can create barriers to finding a solution everyone is okay with.

I often hear the old trope, “Don’t take it personally.”

Cringe.

Every situation feels personal, no matter how professionally you take it outwardly. Feedback hurts, compromising is exhausting, and miscommunication can make you feel unwanted or unheard. We don’t need to hide our emotions or pretend they don’t exist.

But, we can fuel that energy into a more productive conversation. We can lean on a framework that consistently detangles our disagreements. The goal is to make progress forward together with a reasonable solution that works best for the team, the product, and in many cases, the user.

And you might even learn a few things from each other along the way.

Here is a framework that works for me. (The author says as if she always follows this to a T.)

Step 1: Align on goals

When my disagreements fall apart, it’s typically because I entered the disagreement trying to perfectly craft my thoughts.

My thoughts are well intended. If only they understood me, they would agree with me! So, the problem must be that I’m not communicating well. If I reword what I say, speak slowly and with conviction, I will show them the way.

Forget that. Forget your own agenda for a second.

Instead, ask the other person to step out of the trees to look at the forest for a moment. What goal(s) are they trying to reach? Do they want to provide the best user experience? Do they want to ensure the site is performant? Has the company mission recently changed course and your product needs to pivot?

Ideally, you both share a goal. If so, skip to the next step. You may have slightly different goals, and that’s ok, too. It’s easier to discuss when you understand what the other person wants to accomplish, and you may be able to find a solution that serves multiple ends.

If you have contradictory goals, though, you may need to put aside the topic that brought this discussion about, and spend time here in Step 1, realigning your goals.

Step 2: Gather data together

Bad news: your argument will never end without data. You may think it has resolved, but it’ll resurface again and again in new ways until you use data to inform your team’s decision.

Data doesn’t sound like a creative pursuit, but you may have to get creative to find it. You might need to comb through:

• Past user research
• User demographic data
• Product usage metrics
• Previous similar decisions made at the company
• Competitive analysis
• UX data from the industry at large

If your team doesn’t have data or easy access to it, you may need to work with your partners to fix whatever process or technology that’s a data blocker for you.

You might be one step ahead of me. You already have the data to prove you’re right!

That’s okayyy; it’s a step in the right direction. You have data! But data gathered independently just to prove a point is not as powerful as it could be.

Gathering the data together as a team is going to be much more effective. First of all, everyone, including you, will be more likely to be objective. Each person will be less likely to only pick out data that supports your own argument and ignore the data that doesn’t. Second, the process of researching data will encourage others on your team to be more likely to use data to inform their opinions in the future, preventing future heated disagreements.

Reminder that the following statements do not count as data:

• “If I were the user…”
• “I shared this with so-and-so, and they said…”
• “I tried it, and…”

Step 3: Lean on principles

Your team or company may have principles that you can lean on for support during difficult decision making.

Sometimes these principles might be super clear in guiding your decisions.

For example, let’s say your team is in a disagreement about how much to share with the user about what’s happening behind the scenes while they wait for something to load. If your team principles include transparency, lean toward sharing more details. If your team’s principles include simplicity, lean toward blurring those details.

Other times, your principles might appear in conflict with each other.

For example, let’s say your team is struggle to agree on a solution. One option aims for a grand vision for the long term, while the other offers a more practical solution for the short term. If your company’s principles include both pragmatism and vision, you might find yourself stuck in the middle.

As a designer, you can facilitate a productive discussion around finding balance by asking, “How might we take a pragmatic step toward this long term vision?”

Step 4: Identify the decision maker

This is either the first resort or the last resort. In the best of circumstances, identifying roles and ownership of decisions is done first. From Day 1 of the project, you know what your responsibility is, and so does everyone else on the team. As a project goes through its life cycle, the decision owner will probably change, depending on what type of decision is being made. For example, a visual design decision might be made by a Designer, while a data model decision might be made by an Engineer, and so on.

But chances are, if you’ve made it here to Step 4, you might be in a heated argument without a clear owner. Who gets to make this call? At this point, you may find it helpful to open up a white boarding tool and draw a Venn Diagram. As a team, decide who owns what part of the project.

I had to do this recently with stakeholders on my project. Based on our past experiences working at different companies with different cultures and organizational structures, my team members all had different expectations about who was responsible for what types of decisions. There are sometimes grey areas around what a PM controls versus what a Designer controls. We needed to communicate and collaborate better, but at the end of the day, we also needed clarity on which roles got to make the final call after all the data was on the table.

‍