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)