Sometimes A User is Just a User

Every few lunar cycles, we come across another post decrying how UX professionals should never use the term user to describe the people we’re designing for. The authors assert the term is too generic, dehumanizing, and possibly offensive. ”Users are people who are addicted to drugs!” they exclaim.

In one such post we recently encountered, the author said they’ve switched to always using customer instead of user. They want to ensure everyone on the team knows that the people who use their designs have paid for the design.

In our practice, we have a basic principle: Use the term that helps our colleagues best relate to the people whose lives we want to improve. That could be a customer. It could be a doctor. And, sometimes, the best term is just a user.

Not All Users are Customers

Customer is a great term when a person, in fact, makes a purchase decision. But that’s not always the case.

Take, for example, a roadside assistance application that comes as a benefit of an automobile insurance policy. The users of that application could be the customers of the insurance company. At some point, the purchaser of the policy may indeed be in need of roadside assistance.

However, it could also be one of the purchaser’s family members. Often multiple household members share a vehicle. Not all of them are the customer. Only the purchaser is.

This is an instance where user is a better term than customer, because not all users make purchasing decisions. The distinction between a policy purchaser and a non-purchaser household member doesn’t factor into the design choices the design team needs to make. The few times customer would matter is in an instance when the application demands a policy number, which only the policy purchaser may have access to.

Not all Customers are Users

We researched people using roadside assistance. In that research, we found an interesting use case: A parent who purchases roadside assistance coverage for their college-attending child. The parent wants the peace of mind that their child will be well cared for.

In this common use case, the purchaser isn’t covered by the policy, because they live in a different state from the student. Only the student can use the application.

Customer is a meaningful term here, but it only applies to the parent, who isn’t using the application. In this case, user is still the best term for the person who uses the app to take advantage of the roadside assistance benefit.

When There are Better Terms than User

For the roadside assistance application, we could use the term driver, assuming we believe only drivers use the application. If there’s a chance that the passenger of the vehicle might be the person invoking the service, then it won’t apply.

Again, our goal is to help everyone on the team relate to the people we’re designing for. We want to choose terms that give us the best clarity.

In a recent project involving a medical ultrasound diagnostic device, we found ourselves rarely using users because it didn’t help us make our users relatable. Instead, we chose to get specific about who was using the device.

Most of the time, a trained ultrasound technician operates the diagnostic device. However, it’s designed for a nurse or a doctor to also operate it. In some cases, the patient or their caregiver would want to interpret the images on the display. (For example, when a couple is looking at their unborn child.)

For the device’s design team, user isn’t a useful term because each of these people will use the device in a different fashion. The design team needs details about the role each person plays in the diagnostic session. (This is an instance where personas can be useful.)

Shared Understanding is the Goal

User isn’t always the right term to describe our users. Yet, sometimes it is.

Ironically, we need to think of our design team as our users. What will help them understand who they’re creating the product or service for? If there’s a better word than user, then we’ll certainly use it.

But, we don’t want to make things more complicated than they need to be. Getting our teams on the same page is hard enough. We shouldn’t let our language get in our way.


Design teams are most effective when they’re working with a shared understanding.In our 2-day Creating a UX Strategy Playbook workshop, we’ll work together to craft your UX strategy to deliver better-designed products and services for your users. Even if users isn’t the right word to describe them.

Identify the UX strategy your team needs. Choose the right approach from more than 130 strategies that have worked in organizations just like yours. This workshop will kick your organization into high gear. Register today.