UX folks like to talk of the "end user" (examples in 1 2 3), because that is whom they are advocating for. However, the term is somewhat ambiguous: assuming I write an UI library, is the end-user the programmer who uses the library, or the person which uses the product which, in turn, uses the library?

I'm also asking the question because, as far as I know, Human-Machine-Interaction was initially developed for pilots during the 2nd world war, where the term "end-user" seems misplaced.

So is there a good definition of end-user within the context of UX/Usability? Or some historical context why this term came up, which point it tries to make?

  • 4
    Programmers are end-users too. For one they are end-users of their development environments. If they use a library to take care of something they do not want to code themselvs, they are the end-users of that library. The end-user of the software these programmers create couldn't care less how they put it together or how easy or difficult your library is to use. Commented Aug 22, 2011 at 10:36

5 Answers 5


The end-user is a tricky term which has a variety of meanings depending on when and where it's used.

Whereas in economics the end-user is the person who uses the product, in contracts this term usually refers to the non-reseller, who does not necessarily consume the product at all.

For example, if Cheesecake Inc. sells cookies to your grandmother, who then brings them to you, and you eat them, the end-user would refer to you in economics, but to the grandmother in most contracts.

In UX design, the term refers to the former, and so it's you who the baker would have to take into consideration when designing the cookie. However, for the designer of the cookie packaging—considering that you grandmother takes the cookies out of the packaging before presenting them to you—, the end-user may very well be the grandmother.

When it comes to UI libraries and similar content, the question becomes that much more difficult and really has no one correct answer. Like in the cookie/packaging example above, I'd divide your UI library product into two imaginary parts, one of which will have the programmer as the end-user, and the other the user of their creation.

For instance, the code and APIs of the UI library will only ever be used by the programmer. He is thus the end-user of this part of the product, and should be the one you take into consideration when designing the product. On the other hand, the presentation of the individual UI components will be used by someone else, and so the end-user of this part of the product is that someone who will use the final product of the aforementioned programmer.

  • Like your Cookie-Example! They wouldn't call it UX (rather Product Design / Branding etc.), but it's the same idea.
    – giraff
    Commented Aug 22, 2011 at 10:47

End-user is, I think, a very clear term with hindsight, although it is much harder with foresight. In simple terms, the end-user is the person who will be utilising the facilities that you provide. And, as others have mentioned, there can be multiple end-users for facilities being provided to a development environment. In fact, there are often multiple end-users, because different people have to use different parts of software written.

So for a ui library, the end users are the developers who have to use them - they should have a development facility, and this require end-user work for a developer. There are also, possibly, systems people and developers who may have to install the facilities - these are also end-users for the installation tools provided.

And there are the people who use the interface when it is written, who are also end-users. And these may be different types of users - those who produce layouts, for example, and those who display the results.

So I think you need to consider that you have a range of interfaces with your tools, and each of these is an end-user for an interface. Each needs to be considered as a different type of end-user, and designed for explicitly.

What is the point in the term? Well it serves, I think, to focus developers on the person who will eventually be using the code - as opposed to the testers or the immediate client ( who may be defining some of the functionality ). It means that we sometimes focus on people we might not meet, but who will be using the facilities regularly and repeatedly. If we get it right for them, then what we do will be making a positive difference to peoples computer usage.

The installation interface is probably the most interesting one to look at, in some ways. If software installs easily and smoothly, without causing problems, without demanding other software, without breaking anything else, without doing an Adobe and insisting on being updated every day, then nobody will comment on the installation, and the installation end-users wil be happy, meaning that the UI is correct and working. The end-users are generally technical people, but who want to run the installation and move on, nad never have to worry about it again. So design the installation around these end users.


What "end user" means is entirely dependent on what the product or service is. It's also a term that straddles the digital and physical worlds (although, in the physical world, it's probably quite clear who an end user is).

Answering this question for your own context is one of the first, key aspects to designing anything.

(By the way, what's the purpose of your linking in "like to talk"?)

  • Oh I added these links to underline how common this term is ... but it wasn't important enough to start quoting.
    – giraff
    Commented Aug 22, 2011 at 10:43
  • I agree with: getting the audience right is key. But so what's the point of inventing the term "end user" for that?
    – giraff
    Commented Aug 22, 2011 at 10:44
  • 1
    "End user" is more descriptive of the level of interaction. "Audience" connotes a consumer, someone who just absorbs something (at least to me, anyway). The concept of "user" describes more the type of relationship an individual will have with your product or service.
    – Sam K
    Commented Aug 22, 2011 at 13:10
  • I think why I prefer "intended audience" is because, as a designer, you always try to serve a "target group", not "any user of this site".
    – giraff
    Commented Aug 25, 2011 at 6:35

It seems pretty clear cut to me to be honest.

When it comes down to it. The End User is always the paying customer. If the UI collection is for sale, your customers (developers) who are paying and using it are the end users.

If its for your company's internal use, the end user is always the customer. This is because everything your company does is (or should be) geared towards the customers satisfaction, everything else is just schematics.

If the item is purely (if such a thing is indeed possible) for public usage with no chance of monetary benefit, the end user would be yourself. This is because the sole purpose of the item would then be to make YOU happy. :)

  • 1
    IMHO this is a very bad way of looking at it from a UX perspective... So if a product is paid for by one group of people, and given away for free to another group, the usability needs of the latter should be neglected? It makes economical sense, but I believe that this should not be a decision made by a UX designer. UX designers should try make the product useful for everyone who will be using it. The only reasons to neglect one part of the userbase should be economical, and so the respective decisions should come from other departments. Commented Aug 22, 2011 at 11:45
  • @Philip Seyfi "but I believe that this should not be a decision made by a UX designer". I guess this is where we disagree :) I'm of the opinion that every single person in the company should always consider economic impact.
    – Permas
    Commented Aug 22, 2011 at 13:34
  • 2
    The end user (and I really dislike the term 'user') is often not the paying customer. In medium to large organizations it's not uncommon for the people who make the decision to buy a given product to be different from those who actually have to use it. For example, the manager of an accounting dept buys the software but the staff use it most, or a factory owner buys a given machine but the workers are the ones who use it. What's tricky is that buyers and end users will have different needs, priorities and measures of success. Commented Aug 22, 2011 at 15:47
  • Well, when the manager "BUYS" the software for the staff to use, then the overall entity that is the COMPANY is the end user. Just because its a manager that makes the choice doesn't make mean its HIS money. From a provider point of view, is your main purpose to satisfy the bookkeepers using the accounting software? The manager who made the choice? Or the COMPANY that bought it, including its management, bookkeepers and other operational staff who are affected by how your new software now affects their work processes? I put it to you that it is always the last.
    – Permas
    Commented Aug 23, 2011 at 1:23

It means,

"Wake up! You are not like your real users! And if you are, you are not all of your users. Go and find some other people who aren't on the design team and don't sit in a cube down the hall."

IME 'end-user' is a back-formation because developers would argue that they were users too. You are--but you're not paying users, you generally don't represent all of the use cases for the software, and you generally are not representative of the skills or work context for all users.

(And I say this as someone who designs software for developers...)

  • Alternately "target users"
    – Ben Brocka
    Commented Aug 23, 2012 at 16:08
  • Yeah, but then some clever guy draws a user in a cross-hair, and it all gets weird... Commented Aug 23, 2012 at 17:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.