How we relate to things is dictated by how we think about them, which is strongly influenced by how we communicate about them… and the words we use for that purpose. Terminology matters beyond mere semantics. How we think about how our products are used, and the people who will be using our products, shapes what we build. I don’t care how obvious this may be, it’s still useful to say it, to be mindful of it.
We are people, not users.
When we “use a car” we think of ourselves as a person who drives, not “the user of a car”. You drive. The act of driving is not intrinsic to you, it’s temporary, just something you’re doing. When you use a pen, you are writing, when you use a brush you are painting. So what are we “users” of software and services (and all things that make up the Internet) doing? And what does “user” mean, anyway?
Let’s look at the dictionary definition of ‘user’:
user |ˈyo͞ozər| noun
1 a person who uses or operates something, especially a computer or other machine.
• a person who takes illegal drugs; a drug user: the drug causes long-term brain damage in users | a heroin user.
• a person who manipulates others for personal gain: he was a gifted user of other people.
So according to this, if you’re a user you might be using a computer ‘or other machine’, a drug addict, or possibly a sociopath.
We can’t erase the other (pre-existing) interpretations of “user” from our heads, so just on this basis ‘user’ is not a great term. But let’s set that aside anyway and put things in context. Where did this specific use (ahem) of the word come from? How did it come to be used in computing? For those who don’t know what “Multics” means, The Jargon File –and if you don’t know what that is, wikipedia, as always, can help— sheds some light:
1. Someone doing ‘real work’ with the computer, using it as a means rather than an end. Someone who pays to use a computer. See real user.
2. A programmer who will believe anything you tell him. One who asks silly questions. [GLS observes: This is slightly unfair. It is true that users ask questions (of necessity). Sometimes they are thoughtful or deep. Very often they are annoying or downright stupid, apparently because the user failed to think for two seconds or look in the documentation before bothering the maintainer.] See luser.
3. Someone who uses a program from the outside, however skillfully, without getting into the internals of the program. One who reports bugs instead of just going ahead and fixing them.
The general theory behind this term is that there are two classes of people who work with a program: there are implementors (hackers) and lusers. The users are looked down on by hackers to some extent because they don’t understand the full ramifications of the system in all its glory. (The few users who do are known as real winners.) The term is a relative one: a skilled hacker may be a user with respect to some program he himself does not hack. A LISP hacker might be one who maintains LISP or one who uses LISP (but with the skill of a hacker). A LISP user is one who uses LISP, whether skillfully or not. Thus there is some overlap between the two terms; the subtle distinctions must be resolved by context.
Early computers were large, expensive systems that needed “administrators” and naturally people who could “use” but not “administer”.
“User” did not originally indicate a person. In a networked environment, at the network management level it may, for example, make sense to label a computer as a “user of the network”. In fact, UNIX considers any actor in the system, whether human or synthetic, to have a user (and a group) attached to it as a way of indicating access privileges to different functions or services. The “user” in UNIX is really a property that can be attached to things to indicate permissions and other relevant information (for example, a user will typically have a password, used for authentication, a home directory, etc).
Over time “the person named Joe Smith has a user in the system” turned into “Joe Smith is a user in the system.” We started to mix the concept of a user being a virtual entity controlled by a person with a way to refer to the person themselves.
This use of terminology migrated from terminal-based systems (UNIX, et al) to desktop computers and beyond. An iPad, for example, has no need to distinguish between a user and an administrator. We are, in effect, “administrators” of our iPads, but we still call ourselves “users.” Incidentally, that’s what anyone building software for it calls us, and themselves, as well.
This is one of the reasons why so much of the software we use everyday feels impersonal: it was built for a “user”, a faceless entity that may or may not be human. If you happen to build software and disagree, I challenge you to visualize what comes to your mind when you think of the “user” of your software. For most of us it’s not a person, no face, no arms: a shapeless blob of requirements that, somehow, can manage clicks and taps and keypresses. It will take a concerted effort on your part to picture an actual human doing something specific with your software. And it should be the other way around.
So, why is this a problem?
We are more than what we use, and because we have purpose we are doing more than just using.
Homer is baffled when he can’t find the ‘Any’ key.
The effects of ignoring this simple truth seep in at all levels of language and thought, and ultimately define and constrain what we build. We think of “the user” of software. The user of a piece of software. Who’s unique in that sentence?
In general, we talk about what a person does, we describe their actions, we don’t define the person as a generic, interchangeable element while giving the privilege of specificity to the tool. Except in software.
In software, the designer of a word processor would generally refer to the person using their software as “the word processor user.” (let’s ignore, for the moment, the insanity of calling a tool for writing a “word processor.”)
Someone designing a hammer would not call the intended audience for their product “hammer users.”
They would give them purpose and a name. Carpenter, Sculptor, and so on, and in doing so they would be defining a context in which they intend their tool to be used, context which would then aid in making the design better adapted to its intended task.
The designer of a pen would think of a person using the pen, not a “pen user”. A “user” uses the pen to let ink flow from the pen to the paper, permanently marking it in a way that may or may not make any sense. A person who writes has a purpose: a memo, a letter, a book. In that purpose you also discover design constraints. A pen used for calligraphy is different than a pen for everyday use, which is different than a pen used at high altitude, or in space, or for drawing.
Beyond “purpose” there’s something else that a person has that is frequently ignored by software: a life.
Just thinking of “the user experience” is not enough. A lot of software, and certainly the vast majority of dominant software and services, appears to rely on the Donald Trump principle of design: it screams ME, ME, ME. You want to shut down your computer? You can’t: your “word processor” demands that you make a decision about saving or not that file you were editing. Are you highly stressed while driving your car because you’re late to a job interview? Deal with it: your preferred social network wants you to check out the photo of a friend having lunch while on vacation, while you’re also being told that there’s a great offer on coat hangers at a nearby mall, and your calendar is alerting you that you have lunch with a friend soon, even though it’s set for 6 pm and the appointment was mistakenly set for the wrong time, then duplicated for the right time, leaving the old one intact. And who has lunch at 6 pm anyway?
How one would fix this problem is a good question. The answers will be heavily dependent on context. My point is that it’s a question we’re not asking as frequently as we should, if at all. And calling people ‘users’ gives us a pass on that.
Profile photos or friends are used frequently to lend an air of ‘humanity’ or ‘personalization,’ but strip that away and it’s the same content, the same links, the same design, the same choices. Conveniently, it also creates a barrier, and in the process defines a type of human-machine dialogue that puts the weight of decisions and results on “the user” while software absconds, claiming nothing is its responsibility.
We can do better than that.
For a while now I’ve been avoiding the term ‘user’ in everything I write, be it code or prose. It’s hard. And it’s completely worth it.
We are people, not users, and what we build, how we build it, and why we build it should reflect that.
PS: There’s other aspects to this that I’ll expand on in future posts.
PPS: One of those topics is, specifically, how the more recent software development practice of creating “user stories” fits into (and affects) this practice is a topic for a future post. Spoiler alert: it’s not enough. 🙂