Blog

The phrase “I am not the user” comes out of my mouth a lot. I don’t mean that I think it, or that I use it in some abstract way as a guiding principle. I mean I actually say it out loud so that I and people around me hear it.

It is very easy, when a problem has been posed to us, to start generating ideas. We talk about them, we interrupt each other with our own improvements on someone else’s idea, we draw visualizations of them on bits of paper and hold those up to our web cameras. We go on and on building these castles of interfaces and because we invented them, because we believe we have ‘solved’ a problem by them, we fall in love with them in a little way and want to see them built. And presumably bask in the glow of appreciation from our clients and customers.

But I am not the user—we are not the user. Even when we have substantial research and accumulated knowledge about those who use our products, we still don’t know everything about them or about how their day flows. We don’t know what interruptions they are subject to, or what they do when they have limited information but still need to face down the problem we are trying to solve.

Calling myself—and us—back to remember the limits of our own knowledge is important. “I am not the user” so although I think this is a pretty good idea to solve the problem we were given, how can we know that it is a good idea? What questions do we still need to ask? What further research should we do to prove our hypothesis that this is a good solution?

I recently read an article critical of the design thinking phrase “How might we:” The most popular design thinking strategy is BS (Wang, Tricia. Fast Company, June 28, 2021). The “how might we” construct is followed by a problem summary, and that prompt—for instance “how might we make it easier for users to navigate to a dashboard?—is used to spark a brainstorm or conversation.

That article is what inspired this blog post. In the article, Wang points out the ease with which the ‘we’ in ‘how might we’ becomes only the people in the conversation, and thereby minimizes or even ignores the reality of the people for whom ‘we’ are trying to solve a problem. In the worst cases, Wang asserts, the ‘we’ becomes only middle-aged, male, white corporate leaders.

Changing who the ‘we’ is, by adding more diversity of opinion, experience, age and whatever elements are relevant to the problem can help, of course. And since most of us product managers, user experience thinkers, developers, directors and VPs don’t spend our days doing what our customers do, adding those customers to the ‘we’ through additional conversations, research and exercises like a design studio collaboration and usability testing is very helpful, maybe even critical.

And that’s the power of saying “I am not the user, we are not the user:” it reminds us (me) very succinctly that “we” must be careful in exercising our power to decide what our users see and do on our product, website or application. We must ask the actual users if our ideas solve their problem.

---

For a more intellectual take on this, see Nielsen/Norman Group’s blog post You Are Not the User: The False-Consensus Effect (October 2017) or the article in Journal Of Experimental Social Psychology: L. Ross, D. Greene, P. House. 1977. The “False Consensus Effect”: An Egocentric Bias in Social Perception and Attribution Processes.

I’m sure that at some point in the last two and a half decades you have made a purchase online (whether pizza or something else). And it’s possible that at some point your transaction has been refused because you mistyped your credit card number in an online form.

One of the important heuristics we use in thinking about user experience is whether the system helps the user avoid making mistakes. (Similar to #5 in this list from Nielsen/Norman Group)

I was buying something online a few days ago and came across this credit card entry form:

The designers and developers of this form must have wanted to protect the site’s customers from having their credit card information stolen. Rather than showing the numbers as I entered them, the field for number input is treated as a password field and the entry is obscured by dots. So that’s great, very secure, nobody is going to read that number over my shoulder and steal it.

But let me point out that … I was at home, by myself. If anyone—other than my wife, I suppose—had wanted to steal my credit card number by reading it off the screen, they would have had to break into my apartment and sneak up behind me in order to do it. And my apartment has creaky floors: even the cats can’t sneak up on me.

So the main effect of this particular ‘protection’ was that I could not be sure that I had entered the right numbers after I typed them. Safer from my cats ordering a bunch of cat toys, but at more risk of having my transaction refused and having to re-enter it. Protecting me from one harm exposed me to another.

Thinking about this through a usability lens, I would ask: in what context and environment is the user when entering their credit card number? What are the possible perils, and what is the probability of each? And finally how should we address them?

Given endless resources and no deadline, we might learn about and even interview the actual users of this particular site. Are they going to be in a public space like a busy coffee shop when completing this form? Or at home? How adept are they at reading a string of 16 numbers and keying it in? Is their eyesight or dexterity importantly different from that of a ‘general’ internet user? Are they an enemy of a state with a highly sophisticated intelligence service? (Okay, I’ll stop with that )

We might find some cases where the most likely danger is having the number read over the user’s shoulder. But I’ll assert that mostly, this is a problem that doesn’t happen in the great majority of instances of online shopping. I think it more likely that one misreads or miskeys the numbers. I would choose to make it easier for the user to avoid the annoyance of re-entering their credit card information.

The better usability solution is to not obscure the numbers because the more likely problem is that the user will mistype them. Leaving them readable will make it easier for the user to avoid an error. Another mitigation strategy would be to offer a method for the user to view the numbers (an icon of an eye is often used as a switch to reveal the numbers) when they wish to.

Usability and security are not really opposing forces—no cage match needed. If security is needed, there are ways to maintain good usability. But in the case of this form, the security concern was overplayed to the detriment of usability.

What are your thoughts? Have you found examples of usability compromising security or vice versa? Share in the comments! 

This will be a bit of a rant. I don’t want to say I’ve seen it all—I am sure that I have not—but I have seen enough to want to rail against the idea that a good user experience can be crafted by consultants brought in for a short or even medium-term project.

I am a big believer in doing direct research with actual users to learn about them:

• Their needs, or the tasks they wish to accomplish using your application.
• The pressure they are under to get their work done, to be accurate and whatever other criteria determine their success or failure.
• The physical environment and tools they work in and use.
• Their own experience using software tools.
• Their mental model for the work they are doing.

I’ve worked for small software development shops where my opportunity to do user research consisted of an hour during a project kick-off meeting where I got to ask the project stakeholders questions about users. Tell me: how many questions have you successfully had answered by a small roomful of people who are sitting around a conference table waiting to have the catered lunch delivered?

At the other end of the spectrum, I have moderated task-focused usability tests where for 40 minutes or so I have the full attention of a single user to work with a fully-designed prototype of a series of pages, asking them to try what I hope are real tasks, to see if the interface made it possible for them to succeed. And I and a small group of colleagues have observed carefully what happened in that session, and the nine others we did that week. And repeated that process every two weeks on a regular schedule. And when that application went into production, we kept tabs on the analytics of page views, time on page and completion of tasks. This is commitment to understanding users!

I believe you will have made a correct decision about which approach to understanding users yields higher-quality, deeper knowledge and enables better decision-making about the user interface and interaction for those users. 

Relying on ‘best practices’ only goes so far, but that is the best a consultant can do when working on the basis of a few weeks’ acquaintance with the project. The relationship between your user experience team and your users is not speed dating, it’s long term.

Like this post? You could send me flowers and chocolate. Or tell a colleague about this post and this “portfolio.”

The question is coming up a lot recently “what is user experience?” And in the same breath—promoted by the alliterative experience of saying “UXUI”—”what is the difference between UX and UI?”

I’d like to try to answer this with an analogy to the act of building a house.

To build a house right, you need to know what your house is going to be used for. The house also needs to be strong and sturdy, and—to be enjoyed to the fullest—it needs to be pleasantly decorated and furnished. In my analogy, that comes down to three roles:

• You hire an architect to plan the house.
• You have a structural engineer to make sure all the supports are in the right place.
• You hire an interior decorator to specify colors and finishes and fixtures.

In my analogy, the interior decorator is the user interface designer (UI). The structural engineer is a lead developer. And the architect is a user experience (UX) practitioner.

An architect will ask you questions about the requirements and conditions for your house:

• How many people will be living here?
• What are these people like: young, old, tall, short, given to entertaining or quiet and reclusive?
• How will the occupants use the house?
• What is the climate like where the house is to be built?
• What is the site like: is it hilly or flat? Wooded or wide-open? What direction does it face?

Based on the answers to these and other questions, an architect will design a home for you with a set number of bedrooms and bathrooms, kitchens and office spaces and playrooms as needed, and windows as desired to take advantage of the site. There will be indications about the location of doors and the sides on which they are to be hinged. Needs for power outlets and the suggested placement of plumbing fixtures will be described. These are user experience elements: they define how spaces will be used in a way that is about function or interaction. And although they can be changed they are mostly fixed.

The engineer would make sure that the planned spaces could be built and wouldn’t collapse. Mostly these elements are unseen by the user/resident. Some decisions about the experience will force structural requirements. Sometimes limitations of the structure will require rethinking of the exact details of the experience. (And sometimes capabilities of the structure will offer up new ideas for the function.)

The decorator would plan textures and colors for walls and furnishings. This is the user interface (UI). The user interface is touched and observed by the user. It can be changed superficially without impacting function or interaction. Sometimes it can change the interaction in modest ways. It is a major component in how the user/resident feels about the space.

(Note that there can be overlap across the three areas: Ideas about the colors of a wall might suggest a decision about the placement of a window which could set up certain structural requirements. Furnishings (UI?)—couch versus bed—certainly imply the function (UX) of a room, even in opposition to its location (UX?)—near the front door or upstairs in the back! And sometimes an architect (UX) designs special furniture (UI) for their creations. This overlap is one of the benefits of a small team working closely together, feeding each other ideas and not locking one element entirely before getting input from the others.)

But if your architect (UX) forgot to include a bathroom, no amount of work by the decorator (UI) could make living in that bathroom-less home a better experience. Or if the engineer noticed that the plans didn’t include a kitchen, she might find a place to fit one in, maybe in a place that was structurally simple but not ideal for use by the occupants. No amount of user interface can improve the experience of a home without a bathroom.

So user experience is different from the user interface. The two go hand-in-hand, since the user’s experience of a home will be affected by both the utility (dare I say “usability?”) of that home and the aesthetic aspects of design.

And user experience and development need to work together. While any good architect will have an understanding of physics and gravity and such, it’s not their specialty. And while no good engineer will let a house be built without a bathroom, there are finer points about homes—such as the direction doors should swing—that are irrelevant to the structural component of building.

In summary, User Experience takes a broad set of requirements, adds detail through research, and generates a plan for a piece of software—the house’s rooms, hallways, doors—which meets the needs of the user. We are aided by User Interface design, but UX and UI are not the same: a good user experience is not created by good visual design alone. And a good experience for the user is vitally supported by good development, but even brilliantly-coded software does not guarantee that the user can reach their goals. By understanding in some detail their goals and tasks, we deliver a plan for software which satisfies the explicit and implicit needs of the user.