4 ways to back up your design decisions

I realized I'd been defending my design taste instead of my design reasoning.

I'd spent three weeks perfecting what I knew was the right solution.

Clean interface, intuitive flow, everything users needed.

I walked into that conference room confident.

Then my product manager said,

💬 "I don't think this is the right approach. Can we move the main action to the sidebar instead?"

Inside my head: The sidebar? That made no sense. Users would never find it there.

💬 I replied: "This layout is cleaner. It's more intuitive. This follows design best practices."

💬 He wasn't convinced. "I just think the sidebar feels more natural."

I felt myself getting frustrated. How could he not see that his suggestion would hurt the user experience? 

I knew my solution was right, but I couldn’t seem to explain why in a way that convinced him.

💬 So I tried again: "Trust me, this is how users expect it to work."

💬 He replied: ”When I use apps, I look in the sidebar first."

That's when it hit me.

I was asking him to trust my opinion over his opinion.

And why should he?

We were both just stating our preferences with no real evidence to back them up.

I realized I'd been defending my design taste instead of my design reasoning.

The worst part? 

I was taking every piece of negative feedback as a personal reflection of my design skills.

When someone disagreed with my approach, it felt like they were saying I couldn't do my job properly.

The frustrating part is that our design instincts are actually based on years of expertise. We've learned patterns, studied user behavior, and developed an eye for what works.

But because this knowledge has become intuitive, almost second nature, we struggle to explain it in the moment.

When someone asks, 'Why is this better?' our brain says, 'because it obviously is!', but that doesn’t help communicate why your suggestion is strong.

We need to learn to explain our intuition and make our expertise visible.

That meeting changed how I approach every design presentation.

Instead of asking stakeholders to trust my ideas, I explain my logic, which naturally leads them to trust me!

Here's how you can make the same shift...

The change: Remove your opinion from your argument

The solution isn't to argue harder for your opinion.

It's to stop making it about opinion at all.

Instead of defending what you think looks good, share the evidence or logical reasoning that led to your decision.

This way, you're not asking stakeholders to trust your design instincts; instead, you’re showing them the clear reasoning that informed your choice.

So the conversation shifts from 'Do I agree with your personal opinion?' to 'Does this reasoning make sense?'.

The discussion becomes about facts and logic that anyone can evaluate, rather than subjective preferences.

For example:

🙎🏽‍♀️ Opinion-Based: "I think the back button should be in the top left."

📊 Evidence-Based: "I placed the back button in the top left because that's the standard iOS pattern. 99% of iOS apps follow this convention, so our users expect it there."

Now the conversation becomes: 

Should we follow iOS conventions or not? (Rather than: Do you like the button there?)

🙎🏽‍♀️ Opinion-Based: "I think we should put the search bar at the top of the page."

🧠 Logic-Based: "The search bar should be at the top because users scan pages from top to bottom. If someone lands on this page looking for something specific, they need to find the search function before they start scrolling through content. Placing it lower means they might miss it entirely and leave the page."

Now the conversation becomes: 

Is helping users find search quickly our priority? (Rather than: Do you like the search bar there?)

🙎🏽‍♀️ Opinion-Based: "I think we should ask for payment information after they've added items to cart."

🧠 Logic-Based: "We should collect payment information after users add items to cart because they need to see the total cost before they can decide how to pay. If we ask for payment details first, users don't know what they're committing to financially. This creates anxiety and increases the likelihood they'll abandon the process to 'think about it' which usually means they won't come back."

Now the conversation becomes: 

Should users see costs before payment details? (Rather than: Do you prefer this checkout flow?)

I typically have four buckets for backing up my design decisions

1. User research & data

2. Business impact and metrics

3. Established patterns and principles

4. Logical reasoning

1. User Research & Data

One of the strongest foundations for any design argument is research insights and data, as facts are hard to argue with. 

🙎🏽‍♀️ Opinion Based: "I think users are struggling with this step"

📊 Data Based: "Our analytics show 40% of users drop off at this step"

🙎🏽‍♀️ Opinion Based: "This feels like where people get confused"

📊 Data Based: "Our survey data indicates this is the #1 pain point for 70% of users"

🙎🏽‍♀️ Opinion Based: "Users probably don't notice this feature"

📊 Data Based: "Heat map data shows users aren't seeing this important feature"

When you present user behavior data, you're showing what actually happened, not what you think might happen.

2. Business Impact & Metrics

Connect your design decisions to the targets and goals the business is trying to achieve.

Examples:

🙎🏽‍♀️ Opinion Based: "This design should perform better"

Business Impact & Metrics Based: "This change could improve conversion by reducing form abandonment."

🙎🏽‍♀️ Opinion Based: "I think this will help with engagement"

Business Impact & Metrics Based: "This design pattern increased engagement by 23% when Airbnb tested it"

🙎🏽‍♀️ Opinion Based: "This feels like it would reduce support burden"

Business Impact & Metrics Based: "Simplifying this flow should decrease support tickets as we’re solving [x problem] mentioned in 20% of tickets"

3. Established Principles & Patterns

Reference proven design principles and industry standards for when you don’t have data.

Examples:

🙎🏽‍♀️ Opinion-Based: "This feels overwhelming"

💡 Principle-Based: "This follows Hick's Law, reducing the number of choices from 7 to 3 should decrease decision time and analysis paralysis."

🙎🏽‍♀️ Opinion-Based: "I think this follows best practices"

💡 Principle-Based: "While we haven't tested this specific pattern, Baymard Institute's research across 50,000 users shows that this checkout flow reduces abandonment by an average of 18%."

🙎🏽‍♀️ Opinion-Based: "This seems like a safer approach"

💡 Principle-Based: "According to Jakob Nielsen's usability heuristics, this approach improves error prevention"

4. Logical thinking

 

This type of reasoning works because it follows basic cause-and-effect logic that anyone can follow. 

You don't need design expertise to understand 'if users can't find something, they'll give up' or 'people need to know the cost before they pay.' The logic is universal and immediately makes sense.

Examples:

🙎🏽‍♀️ Opinion "I think the price should be bigger"

🧠 Logic-Based: "The price is the most important decision factor for users on this page, so it should be the most prominent visual element"

🙎🏽‍♀️ Opinion: "This confirmation step feels better"

🧠 Logic: "Adding a confirmation step prevents users from accidentally deleting their work, which would be frustrating and potentially costly to recover from."

🙎🏽‍♀️ Opinion: "This feels cleaner"

🧠 Logic: "Showing all 50 options at once forces users to process too much information. Categorizing them into 5 groups of 10 reduces the mental effort required to find what they need"

🙎🏽‍♀️ Opinion: "This order seems more intuitive"

🧠 Logic: "Users need to select a product before they can choose delivery options, so the product selection step must come first"

This is the approach I normally take as I don't often have access to research or data. It works! 

All four remove personal opinion from the equation.

They're all ways of showing your reasoning rather than just stating your preference.

Try this next time

• Identify your design decision

• Ask yourself: 'What evidence or logic supports this?'

• Replace 'I think' with one of these starters:

  • 'Based on [data/research]...'

  • 'This follows [principle] because...'

  • 'This makes logical sense because...'

  • 'This supports [business goal] by...'

• Explain the reasoning in simple terms anyone can follow"

What Changes When You Use Clear Reasoning

When you consistently back up your design decisions with evidence and logic, the entire dynamic changes:

1. Stakeholders start trusting your process instead of questioning your taste and they see you as someone who makes informed decisions, not just aesthetic choices

2. You become known for thoughtful reasoning rather than someone who argues based on personal preference

3. Your recommendations carry more weight because they're grounded in data, logic, or proven principles rather than opinion

4. Pushback becomes collaborative and about improving the reasoning or finding better evidence, not overruling your design instincts

Conclusion 

The goal isn't to win every argument. 

It's to elevate the conversation from "Do you like this?" to "Does this reasoning make sense for our users and business?”

When stakeholders push back, they're not attacking your design skills, they’re just checking if your logic fits their priorities and constraints.”

That's a much more productive conversation that often leads to better solutions.

It builds your credibility as a strategic thinker rather than just someone with design opinions.

It also makes it feel like you're not being criticized.