Illustration by Ollie Silvester for this article.

In Nobody told me UX would be like this, product designer Chris Kiess explains how getting things wrong is a core part of being a designer:

When you evaluate design as an activity, you'll realize that you spend the majority of your time getting it wrong, getting rejecting and getting it wrong again. A very small amount of your time will be spent getting it right. That's what we do as designers.

Chris' words struck as a universal truth that is not often spoken out loud, certainly not in the history of my own career. I wish someone had told me this earlier in my life: the work isn't about trying to prove yourself right, it's about being wrong so you can better inform what is right.

It feels good to be right, and seeking right ideas is more comfortable than seeking wrong ones. But regularly trying to be right (to validate our ideas) only shuts us off from what's actually right and best. The role of designers—and, in some sense, product teams—is that we should work not to get things right but to get things wrong. To make mistakes and find broken ideas. Because if we constantly seek to be right we're missing out on possibilities. If we're trying to prove something right, we're limiting our ability to learn and understand.

Author and mathematical statistician Nassim Nicholas Taleb talks about this from the lens of statistics in his book The Black Swan. Nassim explains that once we encounter something that seems right we easily "concoct an explanation that makes it appear less random, and more predictable, than it was." This limits our learning. From the book overview:

We concentrate on things we already know and time and time again fail to take into consideration what we don't know. We are, therefore, unable to truly estimate opportunities, too vulnerable to the impulse to simplify, narrate, and categorize, and not open enough to rewarding those who can imagine the 'impossible.'

Nassim explains that "we can get closer to the truth by negative instances, not by verification" and that a thousand bit of "right" information can't really prove anything because there will always be something outside the information we're being exposed to.

We can't accurately say "All swans are white" if all we've ever seen are white swans (right information). But we can say "Not all swans are white" the moment we encounter a black one (wrong information). One wrong idea can be more true than a handful of right ones.

If we want to uncover truly good ideas, if we want to make sure we're solving the right problems in the best possible way, or that we're learning and leveling-up not only ourselves but our teams, we should seek to not be right, but wrong. Do not seek validation, seek evaluation. Try to see where your ideas and work break, not where they can stand up against all scrutiny.

There is an important distinction between being wrong and doing bad work, of course.

We shouldn't buck convention just to "be wrong" or purposefully pursue bad ideas in order to learn something. We should still conduct ourselves in pursuit of doing honest work, but when it comes time to evaluate the work (with our team, customers, or others) our emphasis shouldn't be on demonstrating our right-ness but rather: actively seeking to uncover what we've done wrong. This is why it's important to share work early and often, even (or especially) when it hasn't been "fully thought through."

That's where the best work comes from as designers: when we discover we're wrong. When we're wrong, we can course-correct and, as a result, the work we do becomes stronger, not weaker. When we think we're right through validation, we stop trying to improve, we become blind to how wrong we might actually be.