User vs. You

Ceci n’est pas les useurs. (Is the use of little iconic, anonymous, faceless, android-like icons even more dehumanizing than using the word “user”?)

There’s a huge debate going on in the UX community about the use of the word “user”. Some argue that the word demeans the people we are trying to help, that it distances us from them, and that it makes us unable to truly empathize with their wants and needs. Words like “people” and “humans” are suggested instead, reminding us that our users are, in fact, human beings just like us.

I am at best bemused by the arguments, honestly. They feel a little phony, like a way for traditional usability and HCI folks — or marketing people for that matter — to feel or appear a little more folksy and less clinical about their approach to understanding their, um, users. Calling them by a new, friendly-sounding name seems like an effort to undo a possble perception that one may be out of touch with the emerging power of social media and user(oops, I did it again)-generated content.

Jim Drew on the IxDA List said it best, I think:

I find the push to avoid “user” as parallel to referring to employees as “cast members” or any of the other terms which seem clever the first time and make you roll your eyes thereafter. Some weird combo of branding and political correctness.

Does replacing “the user” with “the person” really an improvement? Does using “the person” endear the user (or person) to a product’s designers any better? Does the word “people” engender more empathy than the word “users”? I don’t think so. To me “the person” is equally dull and abstract than user. It’s more awkward and contrived, too — I mean, who actually talks that way?

Besides, the word “user” is a perfectly decent and useful word for when you want to describe an interaction design in a general sense, such as when describing the way a combo box works. I intend to keep using it. I also intend to use other words whenever they are more relevant and appropriate, such as “customer”, “player”, “reader”, “viewer”, “employee”, “renter”, or whatever other term most accurately describes the person or type of person I am talking about.

I call this kind of description “engagement specificity” — articulating the user’s mode of engagement by using the correct word to describe that engagement’s fundamental nature. This is basic English here: just use the right words at the right time, and don’t resort to buzzwords and catchy truisms. In other words, let’s simply try to write accurately and write well.

And besides, we already have the perfect word, and we use it every day in our informal conversations: It’s you.

The Second Person

When describing how to use something to a friend, you (there I did it) will usually say things like “You press the button on the top, then you slide your finger across the slider at the bottom” or “You enter your name and password in the upper left corner”. This is how we already talk about user experiences and indeed about almost anything descriptive, and it is an immensely empathetic manner of speaking. It is the linguistic manifestation of pure empathy: Me imagining what it’s like to be you, and describing my own knowledge through your eyes and actions, using (in literary terms) the second person perspective.

But the weird thing is that we hardly ever write this way, especially not professionally. In fact, in contemporary writing the second person is limited almost exclusively to Choose Your Own Adventure books. The construction has a juvenile, unsophisticated ring to it. It’s seen by many as overly informal, treating the reader a little too familiarly and casually.

But what if we wrote our documentation with the word “You” instead of all of those other euphemisms for users? A very compelling interface specification technique, suggested by Don Norman among others, is to write the user’s manual first: Document all the features as if you were writing the final instructions for the end user, then build the product described in this pre-emptive manual:

Want to know what designers of manuals should do? They should design and write the manual before the product is designed. Make the manual simple and elegant. Then insist that the designers build it the way they have described it. Then we might actually get usable products. and simple manuals.

The best designed products won’t even need manuals.

And why not take this method one step further: Before designing anything, write the product’s manual in the second person as if you were simply speaking informally to a friend about how to use the product, or describing how it works to a colleague or a family member?

I may try this on an upcoming project. Should be interesting, at least.

(Next User vs. Tron)