How to be a stronger decision-maker as a designer
How to better influence your team and feel more confident about your design choices.
Like most new designers, when I first started to learn about UX, I thought it was all about prototypes and wireframes. In school, I would spend the majority of my time on sites looking for the hottest and latest UI. It wasn’t until I worked in team projects, got design critiques from my professors, and tackled my first project at my first job did I realize it was the complete opposite.
I spend a large part of my learning switching gears from learning hard skills to rapidly catching up on soft skills as well. And I like to think I’m not the only one.
It’s easy for us to say we care most about our users. It’s easy for our partners to rely on us because we are the “design experts”. It’s easy for us to say we are collaborators because that’s engrained in our DNA, right?
I always vividly remember the moments when I shared my opinions but someone speaks up to challenge it. Scared, I try to defend myself instead of really listening to what they were getting to. To break out of that, I had to understand how I was making decisions and more importantly how I communicated that to my product and tech partners. And that’s when I learned about logical fallacies.
Logical Fallacies
Logical fallacies are errors in reasoning that are based on poor or faulty logic.
For designers, logical fallacies are when we make conclusions about our designs that is not justified by our design decisions and argument. They are gaps in our logic which can cause a lot of our reasoning to reach a false argument.
A design example showing a true logical condition (a valid argument) would be:
- If a user opens the link, then they will view the contents in that link.
- A user opened the link.
Conclusion: A user viewed the contents of the link.
An invalid argument would be the conclusion that the a user did not view the content of the link (that isn’t true because the user opened the link).
Identifying and addressing logical fallacies can help you more confidently defend your design decisions. It may also help with one of the feelings most designers have at some point: imposter syndrome. While I will not be addressing that in this article, here, I’ll provide the most common logical fallacies designers have. We will all make them at some point. Acknowledge them, learn, and continue improving your soft skills in your journey of becoming a super-designer.
Causal Fallacy
Causal fallacy is when you attribute an event or result to a cause that has no correlation to it.
This is one of the most well-known fallacy, which is sometimes called “correlation causes causation”. For example, if you say:
A stranger tested my prototype and didn’t like it, which is why my team gave me bad feedback today.
In truth, there could be many reasons why your team didn’t like your design. However, by assuming it’s because of the stranger that didn’t like it, you’re committing a causal fallacy. Ask yourself if event A really could’ve led to B. If you can’t find a logical connection between both, it’s usually a fallacy.
In this example, it certainly can be a valid reason that your team didn’t like it because you got poor feedback from testing. But it might also be because of 1) When you asked the team for feedback, 2) The way you delivered it 3) A part of the experience that you didn’t test, etc. etc.
Appeal To Authority
Appeal to authority states that whatever claimed is true because authority said so rather than applying any logical reasoning.
How many times have you been in a meeting and you defer to the most senior leader in the room? How many times have you seen people, including yourself, nod at what someone else is saying just because you think the person talking has the most authority over you?
Of course, this depends on the culture of the company. Typically in larger companies there is more ‘authority’, while in startups there may be less bureaucracy (take this with a grain of salt). In order to become effective designers and influence others, we must challenge ourselves and others to provide evidence to support claims, and if there’s isn’t, try to find it or explicitly call out the assumptions.
Appeal to Ignorance
Appeal to ignorance states that because you don’t know anything (or can’t prove it), it must be true or false.
Our users use the menu, which means it brings a lot of value to them!
The new feature we launched is totally amazing because no user has complained about it yet!
Not knowing anything isn’t proof of anything rather than not knowing it. Especially in design, we must focus on WHY people are behaving the way they are.
Ad Hominem
Ad hominem fallacy is when someone attacks the other person’s character, motive, or other attribute rather than attacking the substance of the argument.
I don’t believe what you’re suggesting about this feature change to be true because you’re a designer.
While I hope no one in their career hears something like this and is an extreme example, this statement are based on personal feelings and not based on evidence about design, data, domain expertise, articles, patterns, etc.
It’s usually tough to change someone’s mind in this situation. To help avoid this fallacy, you need to be mindful about how you react when someone doesn’t agree with you. While they may be right, put as much of your focus onto the actual issue as much as possible.
Loaded Question Fallacy
Loaded question fallacy is when you ask a question that includes the desired outcome of the questioner.
This is extremely common in user interviews, which is why we don’t ask leading questions. Examples of loaded questions include:
- Have you been using this feature a lot?
- Are you done completing the task?
- Are you free to discuss this now, or are you too busy completing the task?
- How’s your gaming addiction?
To avoid the loaded question fallacy, recognize what you are going to ask and check if it presumes something that might not be true. If it does, alter it. For example, instead of saying “Have you been using this feature a lot?” you can say “How do you use this feature?”
False Dilemma
False dilemma is when someone asserts there are only two possibilities.
We can either do usability testing or we can test it once we launch.
While this is an extreme example, dilemmas like this are presented as a middle group to keep everyone happy. In this case, the logical resolution would be to test your product and make everyone happy. This type of fallacy is easy enough to recognize because it leans towards the extreme. One way to avoid this is to avoid a third option: “Can we do usability testing and if our results aren’t conclusive, we also do an A/B test?”
Which of these logical fallacies do you fall prey to? Let me know in the comments!
If you enjoyed this article, check out my other ones!
📚 Non-design books for designers
