9. Being wrong

Most of the stakeholders (and about half of the designers) I’ve worked with are biased against research (either generative or summative) for some reason or another. They’re either convinced that they know better, or that they understand the breadth of user experience because they have been a user before, or they hide behind apocryphal Henry Ford or Steve Jobs quotes as a way of dismissing the idea that they could learn anything new by talking to users.

I always chalk this impulse up to fear. Well…fear and misaligned incentives. Okay, fear, misaligned incentives, and laziness. Okay, fear, misaligned incentives, laziness, and negative previous experiences. Okay, okay, okay. Fear, misaligned incentives, laziness, negative previous experiences, and a poor understanding of statistics, but I digress.

Mostly, it’s the fear of being wrong. The problem stems from assuming you’re right in the first place, which is something designers have an interesting relationship with anyway. In order to work productively with clients, we need them to trust us and let us do our jobs. To do that they need to think we’re right. But, you need to know that you might be wrong pretty much all the time.

To combat this, I’ve heard designers use the phrase, “Design like you’re right. Test like you’re wrong.” But, I’ll take it a step further.

I just assume I am wrong.

That doesn’t mean that I lack confidence in my decisions, or can’t follow my instincts, or suffer from paralyzing imposter syndrome or whatever; it just means I know that, unless I test it, every decision I make is Schrödinger’s Design Decision. That means every design decision is simultaneously wrong and right until you open the box and find out.

The problem with a mindset where I assume that I am right is that learning that I am wrong can undermine a lot of good work, get my (or my stakeholder’s) ego bruised, and wreck a roadmap full of dependencies. This disincentivizes me from learning during research and amplifies confirmation bias.

If, instead, I assume that I am wrong, the goal becomes learning how I am wrong as early as possible and fixing them. When I design for being wrong I reduce dependencies so that learning I am wrong doesn’t crater the whole project. I do research early, and often, and as cheaply as possible. If I am designing with the mindset that I am wrong, everything I design becomes focused on how it might be tested.

That has led me to practice Test-Driven Design (my own adaptation of Test-Driven Development), which lets me focus on learning what affects outcomes, and spend less time on subjective judgments. After all, Design is full of subjective judgments, personal preferences, and pragmatisms adopted from adjacent disciplines. A big part of our job as UX designers is seeing through that stuff to the things that matter, and “How would I even test that?” is an excellent yardstick.