Humane Design: Avoiding the term "User"

It was Aral Balkan that put in strongest words that we should avoid the term “Users” when developing free software. That the term “User” is indicative of the dependency relationship that Big Tech and surveillance capitalism has created between people and the technology they use. One that it not dissimilar of a “drug addict doing drugs” i.e. a user of drugs.

The argument is that abstracting people as “Users” in a way de-humanizes them. The thought is that by trying to avoid the term we are automatically focused on the human aspects and people’s needs.

At the time I thought completely avoiding the term a bit too radical. After all in natural language we use things. I “use” a fork when eating, hence I am a “user” of a product. But I also saw the merits, especially in relation to software development where developers are mired in deeply technical fields and creating abstractions everywhere. Consider this blurb of a use case text:

“After the User fills the required fields of the form and presses ‘Okay’ they are directed to the next screen.”

The User is clearly an abstraction, and the way this is formulated considers them passive consumers of our user interface. We can write this in a rush, and return to technnical considerations. But our software may become a big part of their daily life if they have to use it at the office.

Anyway I decided to practice avoiding any terminology with “Users” in relation to software. And I found that this is surpisingly hard. So used are we to talk about “the user” and “end-users” and it was often difficult to find alternative descriptions. Especially in generic reference I fell back to “the people using the software”, which felt clumsy and inefficient in technical descriptions. “Clients” and “Customers” were sometimes appropriate. Recently @CSDUMMI suggested “Utilizer” expressing tht for them the software is “useful, worthwhile, profitable”. It made me think of “Beneficiary” and “Recipient” for generic use.

Also in many cases it helps by explicitly naming who is involved, i.e. use the ‘stakeholder’ name in product management terminology. Once you are able to discern these use case descriptions can be much improved, and be more domain-specific. The example above could be:

“After the Buyer fills in the order details they can check out the basket and specify delivery details.”

But then it struck me that the actual terminology you end up using, isn’t the most important and that sometimes falling back to the word “User” is just fine. What is important, and what makes this a best-practice, is the added awareness and extra attention you give to thinking who you are creating the functionality for. It is the thought process itself that makes the difference, and this is what helps put people’s needs more clearly in focus.

Best practice: By trying to avoid referring to people as “Users” we force ourself to be more focused on their actual needs.

(Image: ‘Addiction Recovery’ by Nick Youngson CC BY-SA 3.0)

The Fediverse toot about this topic as expected led to some lively discussion. Per Axbom posted a really nice article:

(At least) 4 Xs that aren’t UX

The problem with “users”
Much of the controversy surrounds the first half of the term: “user.”
As Edward Tufte famously observed, “There are only two industries that refer to their customers as ‘users’, one is of course IT, the other is the illegal drugs trade.” And in the wake of books (like Alone Together) and documentaries (like The Social Dilemma) bringing to light the habit-forming and harmful potential of technology, the parallel meanings of “user” might seem eerie.

[…] Thus, saying “users” or “end-users” could give the impression that they are “faceless automatons who will accept what is given and do what they are told, brain optional.”1

No less a figure than Don Norman himself, who coined the phrase in 1993, has argued the term is derogatory: “One of the horrible words we use is ‘users.’ I am on a crusade to get rid of the word ‘users.’ I would prefer to call them ‘people.’”2

This wouldn’t be the first time Norman has split hairs on a term he popularized. His distinction between affordances (on physical objects) and signifiers (in digital interfaces) never really caught on.