Bob Lambert

Jazz on the harmonica

What’s wrong with calling them “users”


To me, calling someone a “user” contributes to the gulf between IT and other business people.

Most of us don’t think about it and say “user” or “end-user”. Those who do think about it say something like client, customer, or business customer, or something similar.  Sometimes these terms work and sometimes they seem contrived, but there’s a better way.

Lior Arussy of the Strativity Group argues that what we call our customers is critical to effectively serving them ( According to Arussy the problem is that many of us use terms for customers “based on their role in our process, encouraging a “one size fits all” approach that treats all customers the same. The diversity and complexity of customers is subsequently ignored and replaced with a customer that does not exist but who fits perfectly within the organization’s business model. The customer is thus subjected to the company’s processes and efficiency needs rather than the other way around.”

When we in IT call them “users” we do the same thing. Rather than thinking about a business person’s role in a business process, we think about them in terms of how they use “our” system. This encourages us to think narrowly about how, for example, a recruiter uses a personnel workflow system. The word “user” encourages us to disconnect from the business process rather than understanding how the system fits into the hiring process as a whole.

Maybe I’m exaggerating and this one small point doesn’t matter much. However, in most organizations there is a a communications gap between IT and business, and as the service provider it is IT’s responsibility to bridge the gap. Communications gaps are made up of lots of little habits of thinking and practice, and this is one of them.

So what should you call the user of a business application? When I’m talking generally about business people who use IT applications, I use the term business people, which after all is what they are. When I’m talking about the users of a specific system I try to use the term that everyone else in the organization uses for what they do, like “financial analyst” or “recruiter” or “production line supervisor.”

I hope that being specific and correct about business people’s role encourages me to understand the system I’m building in business context, making it easier for me to build the application exactly as they need it.



2 responses to “What’s wrong with calling them “users””

  1. Hmmm….that’s an interesting take on the term “user”. I think the most important point you make is the idea that we need to think about “our” systems as customer and business driven, rather than driving the customer (or the business). A huge failing I see in so many attitudes prevalent in the industry today is that of IT being more important than the business–this air of superiority, if you will, that the technological systems themselves are so vastly critical to the business. The mindset needs to be reversed–it’s the business that is so critical, and without it, IT doesn’t exist. As a “gun-for hire” I’ve always held that the business and customer needs dictate what I develop, and not that what I can develop should dictate how the customer operates. Working from that mindset, I naturally componetize the system and generalize the terminology for simplicity. As such, I’m guilty of using the term “user” as the entity that is the operational mechanism driving the manual inputs in the system. However, I think that is justified and helpful and even necessary. As in reality, we do have “our” own process and system for building and producing a product for customers and their business.

    Using your personnel workflow system as an example, in “our” domain it’s important to think in general terms of a “user”. We have to, for instance, realize that a user is a general abstract concept that has concrete realizations. Knowing we have a user that could have a realization of a “recruiter” or a “branch manager” or any other number of role realizations is important in understanding how “our” system must be developed for various roles. We know, for example, that a “user” will be of one or more roles. And that the interface may (or may not) vary depending on the role currently accessing and using the system.

    In fact, taking the example a step further, abstracting out into a “user” provides a benefit that you can’t achieve if you don’t do that–shared roles. The discussion can get more complicated and hard to follow if you stick to a truly role-oriented approach. What if your recruiter is also your branch manager? In abstract terms, you can have a user that is both a recruiter and a branch manager. It becomes easy, then, to talk about the operational parameters for a system in such a circumstance. However, without the idea of an abstract user, how do you talk about a person when all your terminology is role-based with no common ground? What is a recruiter/branch manager? Is it some sort of new role? In reality, your customer is a “user” of the system with the need to see and use the system in a manner distinct from just a recruiter or just a branch manager. Abstracting allows us to think in terms of role and process interaction, Thus, we can develop the functional components of the software around such needs, and develop the usability elements around human needs (irrespective of role needs).

    Certainly, it’s still critical for quality development to understand the business and where the various system components fit within the overall business process and model. A lack of such understanding invariably leads to sub-par systems that don’t quite do what the user needs–often leading to frustration as the users try and adjust their process to fit the software (always a sure sign things were missed in “our” process of construction). However, I think that the abstracting process is important and a key developmental aid during “our” construction process. The abstract entities that we need to think about and deal with don’t normally exist in the business. There’s no concept of a “user”, just a person such as a recruiter. But without that abstraction (which is inherent in object-oriented idealogies) development processes, I believe, would suffer.

    While I don’t think “our” abstraction in regards to terminology is a negative disconnective element of IT construction, I do very much agree with your point that it is common to find communication gaps between IT and business. I think the answer to fixing that gap, though, lies more in shifting the seemingly ubiquitous idea that IT drives business and getting back to the reality that business needs to drive IT. When IT understands that, the abstraction is simply a developmental aid, but one that doesn’t need to impact communication. For what use is a “user” in a system if you don’t know how the concrete realization of that user thinks about and drives the business?

  2. Chris, great comment, I agree with your point about abstraction. Interestingly, you correctly point out virtues in the “one size fits all” approach. Granting your points, I’d still look for that correct name for a recruiter/branch manager, but I wouldn’t make a big deal about it. Another danger in IT/business relations is in being pedantic, which brings us back to the problem with terms like “business customer”.

Leave a Reply

Your email address will not be published. Required fields are marked *