It is more gratifying to think 'I possess the truth' than to see only darkness in all directions. — Friedrich Nietzsche

All tech teams aspire to build great products and services, but consensus on the best methods and principles remains elusive. This article will introduce and unpack the concept of user-realism and make the case that it should be viewed as a core design principle all teams should embrace. Many tech teams today, I will argue, fail to take user-realism seriously. This is not the same thing as being averse to user research. The article will also attempt to diagnose some underlying factors preventing user-realism from becoming a standard principle across departments and organizations.

User-Realism and User-Non-Realism

Realism is a philosophical term that broadly means there is only one reality and it exists mind-independently. Philosopher John Searle gives a compact definition: "We live in one world and... that world is intelligible." I'm borrowing realism not as a metaphysical doctrine but as a label for a mindset toward inquiry: the conviction that there are truths to know about users (anything, really), and that disciplined investigation moves us closer to those truths. I have found many design circles to be weirdly resistant to these sorts of claims, but I hope to show why underlying philosophical commitments about truth and reality actually make a world of difference in practice.

I start with a bit of esoteric musing to help me draw a dichotomy between two types of tech teams: user-realists and user-non-realists. These are poles of a wide continuum, but positing the poles helps me clarify the argument. No team or department is actually one or the other; I treat them both as ideals that never quite touch solid ground.

Being a user-realist means you hold a particular attitude toward truth and reality: that they are worthy of pursuit. A user-realist thinks that if we ask questions and think critically about certain target user groups, our understanding of them will get incrementally better. We will be able to ask more incisive questions, build new assumptions on firmer foundations, and get a better lay of the land. Moving closer to this truth tells us how we should be designing and what problems need to be addressed because it allows us to know things we didn’t know before. That’s the key point: knowledge about users can advance. User-realist teams know that learning about their users gives teams concrete direction and can actually speed up design and the product decision-making process. They take whatever signal the research is picking up seriously and are not in the business of conducting research for research’s sake.

User-non-realists act as if their beliefs and assumptions about users are 'good enough' and do not need updating. They behave as if there are no new, big truths to discover about the psychological, behavioral, and social realities of their users. I mean, what can possibly be learned of consequence? As Marty Cagan said, "bad teams think they are the customer."

Consider Amazon's Fire Phone. By most accounts, the product's defining feature — a 3D "Dynamic Perspective" display — existed because leadership was enchanted by it. Internal teams reportedly struggled to name the problem it solved. The phone shipped in 2014 at flagship pricing, sold dismally, and Amazon wrote down $170 million on unsold inventory within a quarter. This is user-non-realism with a price tag: a team of brilliant people building in the dark, certain they already knew.

Or take a more personal case. I was living in Dubai and leading research at the region's largest bank. A group of executives came to my office with a perplexing question. They first explained that every bank employee had their salary paid into a company bank account. Then, based on their figures, about 40 percent of the money in those accounts was transferred out to other banks within a week of being deposited. To their credit, they were unsure what was happening and wanted to know why.

With a few dozen cash gift cards, a group of researchers and I got to work. We first planned interviews with employees who regularly transferred money and who were willing to talk about it, to identify and pull apart the different motives and reasons for the transfers. We then followed this up with a survey of about 3,000 employees to make sure what we uncovered would generalize. After about a month, we came back to the executives with a cluster of reasons and a bunch of statistics that made a whole lot of sense. For example, many employees were expats who sent money home every month, and other UAE banks offered much cheaper remittance rates — so they moved their money to where sending it cost less. Our research helped the bank create a multi-layered mitigation strategy (some of which we helped devise) that substantially reduced the number of transfers and also gave many employees just what they wanted.

Explaining User-Non-Realism

What is more important than recognizing that there are two idealized poles is realizing what is preventing teams from moving toward the realist pole. Not being sufficiently user-realist can result in lackluster launches, copycat roadmaps, and expensive lessons the Fire Phone way. What stops user-realism from being baked into every tech team's DNA?

Factor 1: Resisting "I Don't Know"

It is hard, given the kinds of creatures we are, to admit we are ignorant and need to work harder to reach a better understanding. In some ways, it is unnatural, and a large body of psychological work on bias supports this (Rozenblit & Keil, 2002). Organizational structures and quarterly pressures compound this natural aversion. On user-non-realist teams, control and appearances can come to matter more than truth and inquiry. Not knowing isn't seen as an opportunity for learning and value creation. At worst, it can be viewed as a weakness that might threaten a leader's authority. It is politics. After all, how many people in charge do you know who actively seek to disprove their own assumptions and beliefs? In some organizational cultures, appearing completely knowledgeable matters far more than learning, discovery, and progress — all of which are kick-started by the phrase: "I don't know." 

Factor 2: Widespread Research Theater

There are plenty of teams who conduct reams of research, have dedicated insight departments, and claim to be user-centered but are still very much user-non-realists. Much of the work done is at best research theater — more about box-ticking, validation, and feel-good bandwagoning than changing a team's collective understanding in some important and novel way. Embracing user-realism requires staffing specialized and motivated teams that share a common conviction that learning about users will unearth insights valuable enough to inform the way the product takes shape and functions. It is a mindset shift and teams must be open to this possibility. And these research specialists should actually know how to generate new knowledge and communicate it in a way that supports integration into the product and engineering strategy. No small thing. Other cases where research is impotent are less about theater and more about a lack of resources, which prevents trained professionals from conducting their work in a rigorous and timely manner.

Factor 3: Peace of Mind

Embracing user-realism means questioning deep-seated beliefs, facing unpleasant facts, and wading into the unknown, uncertain of what one will stumble upon. This is unnerving for most folks. Journalist Jonathan Rauch wrote, "The process of social learning—creating knowledge—is good, healthy, and important, but it cannot promise to be reassuring, affirming, or safe." User-non-realist teams think they know already because it is less scary and much easier than the alternative. People are tricky and frustratingly hard to pin down. Colleagues get testy when research rains on their product’s parade. Embracing user-realism requires not only investment, skill, and humility but also enough courage to push against the current when the time comes. 

User-realism means treating your understanding of users as revisable and allowing new evidence to alter both that understanding and the product that follows from it. It doesn't mean "more research." It means letting new knowledge challenge your assumptions and change what you build. This is an essential ingredient if your goal is to make things that are useful, usable, and adapted to the user.

Conclusion

Do teams want to know more about their users? Do they allocate resources for research conducted by specialists? Are they willing to let data falsify the assumptions behind their coveted new feature? Are design choices and product features based on a knowable external reality, or are they driven by gut feelings, common sense, or a keeping-up-with-the-Joneses mentality? How teams answer these questions reveals much about their ability to build excellent products and deliver value to their users and organizations. It also tells you where on the user-realism spectrum they fall. 

We may never possess the whole truth about our users. But that is no argument for choosing to stay in the dark.

Works Consulted

Friedrich Nietzsche. Human, All Too Human. (1878)
Marty Cagan. Inspired: How to Create Tech Products Customers Love. 2nd ed. (2017)
John Searle. Mind, Language and Society: Philosophy in the Real World. (1998)
Jonathan Rauch. The Constitution of Knowledge. (2021)
Leonid Rozenblit & Frank Keil. "The Misunderstood Limits of Folk Science: An Illusion of Explanatory Depth." Cognitive Science, 26(5), 521–562. (2002)

‍