[The term “user”] splits people into two discrete groups – “programmers” and “users”, … the unhelpfully divisive “us” and “them”

User interface, user experience, user story, user error. Application programming is devoted to helping users. But while there have been objections to the term user, and there have been suggestions to humanise the term by encouraging developers to consider people, as opposed to ‘users’. But even then we are just changing the term, not fixing a problem. There is no generic term for people that is adequate, as all people interact with the world differently, and as such people interact with software in different ways and expecting different interactions.

To see this, lets look at the first example of a user story on the Wikipedia page: As a user, I want to search for my customers by their first and last names.

As a developer, if I were to pick this up I have no clue as to what kind of interaction I need to provide. Is this “user” a business clerk looking as sales customers, or a MMORPG administrator looking for game players, or veterinarian looking through a list of pets. In each of these cases there are subtle differences, where customers can be people, avatars or pets and as such each set of information may need to be presented differently.

While the term user, may be appropriate when we discuss the broad fields of user experience and user interaction, acting as a catch all for all possible users of software. But when we begin looking at specific classes of people we want to assist with software it ceases to be a helpful term and it splits people into two discrete groups – “programmers” and “users”, “IT-side” and “business-side”, or the unhelpfully divisive “us” and “them”. Who is “us” and who is “them” generally depends on which side of the table you are on, but it remains that the term “user” draws a clear line in the sand, between our group and the dreaded “others”. Worse still, the term for the others is so unhelpfully vague that we can only think in metaphors or stereotypes. By the way, have you ever noticed that programmers type (Ctrl+i)like this(Ctrl+i), but users type (clicks Bold)like this(clicks Bold again)?.

The solution: Stop using the word “user”

As soon as you think about a “user”, immediately stop and mentally replace the term with an appropriate noun.

As a new years resolution, I want all programmers, developers, business analysts, and so on, to try something. As soon as you think about a “user”, immediately stop and mentally replace the term with an appropriate noun that mentions whose needs are being met by the tool you are designing. Regardless of how contrived or long winded that noun needs to be, replace the term user EVERY TIME it enters your thoughts, even before you write it down. Even if you weren’t going to write something, the second you think “the user wants…” or “a user will see…” immediately go back and replace that term.

So see why this is helpful, I propose another user story: Clicking the button will allow the user to save their work.

And picture how this interaction may take place and answering some of these questions: What does the button look like? How will the use know to click that button? How will the interface react when the user clicks the button? Given the vagueness of the story, they may be really tough questions to answer.

Now, contrast this with the following by answering the same questions about the following three user stories:

  • Clicking the button will allow the author of a novel to save their work.
  • Clicking the button will allow the programmer to save their work.
  • Clicking the button will allow the child who is drawing to save their work.

When you pictured these interactions, did you visualise them differently? Did you picture different images on the button shown to the author and the child? Is the size of the button different between the child’s button and the others? More than that did the user story sound unnecessary, for example, does the idea of a programmer clicking a button seem to make sense, or would they be more likely to just use a menu or even keyboard shortcut?

By forcing ourselves to go back and reexamine the “user” of any given piece of work, or line of code, it forces programmers to think about what they are trying to achieve. While it might be conceivable that a “user” might want to do some given action, it is a helpful mental exercise that forces us to step back and really contemplate if the user really will want or need to do something.