User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
People - as Don Norman says in this video at UX Week 2008
See also - I am not a user.
Manufacturers often refer to end-user, but I really don't like that term actually. Personally I've no beef with user in a tech environment, but I do use people as a generic term when talking to...well...people! I use the term you often when speaking to someone, and in some scenarios customer is appropriate.
I'm not sure the situation crops up often enough to have to differentiate "People who use the product" and "people who don't use the product", by having to use different terms?
Having laid the groundwork early on in a discussion as to whether you are talking about you or [other] people who use the product, then you can variously refer to them as you, they, people, them, etc... and not often should you need to chop and change the subject between those that do or don't use the product. I'm sure there's exceptions - but I'm speaking generally.
Note, you should avoid the he/she approach - as discussed in this ux.se question
Update: One of the above links goes to a website called 'I am not a user'. They have a poll where people can vote on whether being called a user is ok - or not.
At the time of the OP's question (May 2011) their poll said 52% of people were happy to be called users!
Nearly 6 years later (Jan 2017) there is a swing the other way and 59% of people do not like the term user.
Whether this website attracts a fair audience or not is of course unknown. There is no way to know if this site has attracted an unfair interest from people who don't like to be called 'user' but the biased subject matter of the site should not be dismissed as irrelevant!
Your users have a point here. Being called a 'user' is similar to being 'the patient with the broken leg in room 213' instead of Mr Smith (or even worse: just 'the broken leg'), or a 'test subject' in a psychological experiment.
Don Norman recommends calling them 'people', it's a very general term but it works. Depending on the context you can also consider task-based role descriptions, such as participants in a discussion, authors/editors when it comes to text, or visitors/guests for a website.
Your users may have their own ideas, too. Next time you hear someone complaining about the term 'user', why not ask them directly for a better suggestion?
Not clear why "user" is dehumanizing. I never heard of a user that wasn't human, although I guess it's possible. Is it also dehumanizing to call someone who operates a car a "driver"?
Maybe "user" has acquire certain negative connotations in your organization because of the attitude of certain (perhaps former) members of IT --those that say "user" with a rhymes-with-loser tone. Maybe the attitude is the root of the problem, not the label. If so, you need to fix that first or else whatever substitute term you use instead will soon acquire the same negative connotations.
However, if you want to signal that IT is different now and recognizes it's job is to support users to make their job easier, then how about calling them "clients"?
I guess that makes you a "server." Kind of an apt metaphor.
If you're referring to them as people, then "people" works. If (as I suspect) you are looking for a word that captures the sense of "users of our service", how about "clients" or "customers"?
I don't know what they are complaining about, traditionally in psychology they are referred to as 'subjects'!
When I've come up against this problem before I've used 'participants'. This has the connotation of 'active involvement' which is what they do in real life, and which you'd like them to keep doing when you're testing them.
At my last job, with an online University, our "users" were "students". Could you do something like that? Are they Analysts? Programmers? Writers? Might that help?
I have in the past taken a slightly entertaining approach and referred to user groups as Kind and Gentle People, Project Enthusiasts, Willing Participants, Avid Fans ... you get the idea.
In general, to counteract the impression of dehumanization so common in software, I recommend erring on the opposite side - create a unique voice and tone. Anything that breaks the monotony of reading endless lines of undifferentiated text, any phrases or words that will bring a smile to people's face, and anything that reminds folks that real people created this software for other actual humans is generally well received.
In some contexts, you can refer to them as "actors", but I don't know if that's any better given the connotation of that word. Perhaps you can gently remind them that "user" is less dehumanizing than "nodes".
You could call them either one of the following words, which are all valid for describing people in a system, though I wouldn't say they will feel them more humanized:
More appropriately, call them based on who they really are! Be specific.
What is their field? What are their activities? If they are researchers, call them as such. Think in terms of their positions, roles or responsibilities.
User is a standard term and you should not hesitate to use it. Not everyone associates user with negative connotations.
If you have a more specific term that refers to all of your users, by all means use it. Sometimes the user base is so heterogeneous that the only thing they all have in common is that they use your application... hence the label.
People who support and use something, such as the arts, are often referred to as patrons.
You can refer to them as individuals, if you're worried about dehumanising them.
Can you make it more specific to the product?
If they are buying something then you could refer to them as customers? If they are user of a VLE/LMS they could be learners or tutors?
Or if you are using persona's you could refer to "them" using the name you gave the persona?
I suppose that I use other terms when I am talking about the people who use a specific application. So I might refer to them as "the Architect" if it is an architects application, and will often want to distinguish between, say, architects and secretaries, and so would use appropriate terms for the types of users.
Having working on e-commerce sites, I try to distinguish between "clients" - the people paying us to build the site - and the "customers" who are the people who will use the site at the far end.
This is probably a better approach than just considering them all as "users", because it distinguishes between different types of people using the system. It means that the different types of user can be distinguished, and addressed in different ways - all types of user are not hte same.
What about "computer operator" or "the operator". These terms sound more technical or sophisticated, and it may be that "user" is undesirable in part because it makes the person sound like a passive drone.
Other suggestions, depending on how much you want to play to their ego: controller, director, administrator.
(There is a movie I think called The Right Stuff where astronauts object to being called something, like "subject" or "passenger" and getting stuck in a capsule with no windows, no manual emergency controls etc. They push to be called "pilots" instead and for a simple window and some overrides.)
I see Cos Callis also suggested Operator about 20 minutes ago, sorry Cos! To retroactively rationalize my post, I will point out the distinct "computer operator" suggestion.
I don't think there is anything wrong with the term 'user', for example if you say 'advanced user' or 'novice user' that sound absolutely normal. An employee of some company who might have some associations with the term 'customer' as in 'our customer', that might be a kind of an offensive term for them, since they have a bad attitude to their customers. Same with the term 'user', if you presume that users of your product are dummies, well ... may be that's what they are or, in fact, you could be underestimating!
Also, say for example 'FreeBSD user' or 'Pro/ENGINEER user' what do you make out of that? Or just 'Ubuntu Linux' user' vs 'Senior Debian Linux User'? Should I pick more for you ... well, hope that I won't have to and you already have the idea I'm trying to deliver, and the world 'user' expanded to something you haven't though of just yet :)
We use the term "member" on our sites.
I personally like "Actor". This is the term used in Use Cases. Actor implies activity and interaction, and it also implies that actors may have different roles. "Participant" is probably the next closest, yet it doesn't have the advantage of an easy association with roles.
"User" does have negative connotations, but possibly more importantly, it has the implication the system is static and the sense of interaction is low, particularly "end user", whereas "actor" suggests actively engaging with the system.
"Client" and "Customer" both have the implication that you are providing a service for remuneration. That is often not the case. Often it is the actors who are being paid to use the system. Also one of the challenges is in user acceptance of the system. "Client" and "Customer" suggest 'we've paid for it and now you must deliver', which is not conducive for developing the Use cases and information gathering that you need to design a system.
"People" also suggests nothing in relation to the system. It only affirms that you are a human being, which hopefully you are not doubtful of. It is also true that actors interacting in a system may not be people.
What you need are "Actors". People or things that can take different roles in interacting with a system or software. "Actors" implies that the people who are going to use the system need to get actively involved in process of developing it - which they most certainly do. The more active involvement you can get from your prospective actors in development, the more likely you will have a better user experience over the whole lifetime of the system.
Well, a user is a person who uses something, so "People who use our system"?
It may depend on the context in which they're being called users, though, some uses of "users" might be acceptable. Is there a difference between a blog bragging about X daily active users vs text saying "Search for a user" vs ....?
It all depends on the context. I any case I prefer "end user" to "user" because it is more specific. In some discussions I use the term "customer" to emphasize the fact that we have certain obligations towards this person (such as delivering quality products).
If the person in question might buy something, client works.
If the person in question might be chosen, selected, or elected, then candidate is a good choice.
In UML use cases, someone or something who interfaces with your system to do work is an "actor". This actor can be a human or another machine or piece of software (many programs launch other pieces of software either with specific predefined goals or to take control of them with scripts or other automation).
From a more business-related perspective, if your software is used primarily or exclusively by people who work for or have a business relationship with the company that will "own" your software, you might consider using the person's job description or other business role (such as "customer" or "visitor"). There are as many euphemisms (and dysphemisms) for "worker" as there are companies, so this may be confusing if your terminology will be exposed to people outside the corporate culture, but "CSR" (customer service representative - the generic term for the human user of a CRM software package) and other relatively neutral terms are usually fine to have in software documentation, provided there is a footnote somewhere defining the term.
ITtypes :)