The Yangtze River stretches nearly 4000 miles across central and eastern China, feeding from glacial and wetland tributaries as it weaves through the Qinghai–Tibet plateau, passing over the ghostly, submerged towns of the Three Gorges Dam, and emptying into the East China Sea. The river provides a home to many residents, including a remarkable fish called the torafugu. It swims through both the Yangtze’s lowland waters and your software projects.
The torafugu, also known as the tiger blowfish, would be unremarkable, save for its two notable features: first, it is delicious and often described as the most flavorful sashimi (similar to sushi); second, it contains a neurotoxic poison called tetrodotoxin that makes cyanide look like salad dressing. A few drops of tetrodotoxin could kill several adults in the most horrific of ways, as it first paralyzes its victims, then it slowly deprives their motionless bodies of necessary oxygen. The poison has no antidote. Luckily, only some parts the fish are poisonous, leaving the rest for the nimble knives of specially licensed sushi chefs and adventurous diners.
Software project teams are like these sushi chefs, capable of creating a masterpiece and of poisoning their customers. With focus and precision, everyone wins. However, without careful attention, poison seeps into the experiences we create.
What is the poison in this scenario? It is the unavoidable bias we introduce into a project: our long-held beliefs, our unfounded opinions, and our hasty generalizations. We carve up a project, and—ever so slowly, ever so unwittingly—biases bleed into the work. We take shortcuts, making decisions based on familiarities and preferences. A familiarity with iPhones may lead us to neglect the needs of Android users. A preference for subtly contrasting colors may lead us to neglect the needs of the color blind. Such biases and countless others permeate our decisions and risk poisoning the experiences we design.
We carve up a project, and—ever so slowly, ever so unwittingly—biases bleed into the work.
How do we avoid poisoning an experience? We simply recognize that we are not the users of the experiences we design. The phrase “you are not the user” is an axiom in the UX community. At its surface, it stands as an indisputable statement: You are you; you are not someone else. Therefore, we can never truly see an experience through another person’s eyes. We can research. We can empathize. But we cannot be users of something we ourselves create.
What is a user?
If you are new to user experience, you may have noticed that the word “user” tends to be thrown around a lot. You will hear, “user-centered design, user goals, user journeys,” and, of course, “user experience.” It would seem that the user is highly prioritized within the field of UX. But even within UX, the user is often neglected. Consider the following statement:
A user is a person having an experience.
The statement is so sparse that it sounds whimsical. Yet, this basic idea is at the core of what a user is. Over time, an artifice forms around this definition, complicating its discourse and draining its value. What was once a simple idea branches off into multiple directions, like a river spreading across a delta. You can surround it with marketing flourishes or embellish it with academic phraseology, but the fundamental idea remains: You must have a user to have an experience, and you must have an experience to have a user. The two are inseparable.
You might see yourself as a potential user when creating an experience, such as a website or an app. For instance, your team may create a gourmet cooking app, full of tasty recipes. You think, “I love food, and I know a lot about gourmet cooking.” But, even though you may use an app, you are still not the user—you are the creator using the app. Even experienced designers sometimes make this mistake. Consider the following hypothetical example:
FishesR’Us wants to create an iPhone app that helps users understand how to cook seafood. You love seafood and cook it often; therefore, you believe you are a user. Sounds logical enough, yes? However, a problem arises in following such logic because, even though you may be a member of the target audience, your mere involvement in the project affects your objectivity. This is best demonstrated by taking the previous example and adding a bit of background information:
FishesR’Us wants to create an iPhone app [and is paying you to provide a solution] that helps users [,who may know more or less than you do,] understand how to cook seafood. You love seafood and cook it often [and you already know how the app works, what it offers and what it does not]… Do you still believe you are a user?
You have a vested interest in designing an experience. You want your client to be satisfied, your company to be successful, and your team to be happy. These concerns can affect your objectivity. They often do. Perhaps your client’s desire to create an app is misguided, and the app should instead be a website, a Facebook page, or a podcast. Perhaps your company wants to “wow” the client and recommends unnecessary features and functionality. Perhaps you want to be seen as a team player and support your team’s cutting-edge ideas. These desires and concerns are understandable, and some may even be admirable. However, the cruel reality is that users do not share these concerns. Users do not know your client, your team, or you. They do not care about your project as much as you do — if they do at all. They cast their attention toward their own lives, their own needs, and their own desires. Their thoughts are filled with private concerns about their jobs and families, as well as their own projects, ranging from the banality of mowing lawns to the excitement of planning vacations. You may eventually lure users into caring about the experiences you create, but a user’s biases and interests will always differ from your own. He or she may learn to love your creation, and he or she may eventually use it every hour of every day, but — right now, at this moment — you are not that person. You are not the user.