Skip to main content

The Lexicon of the Solution: Eliminate the User

We talked about getting rid of the customer in the last episode, which got a couple of people riled up thinking that I was actually advocating the removal of the role of the customer. I was simply wondering whether we should still be using the term “customer” in the same way we have used it in the past. Now I’d like to go a bit further in our war on words that have lost their meaning and talk about the term “user.” When addressing the issue of the customer, I admit that I don’t have an alternative term in mind, only that the term “customer” has become ambiguous and can tend to establish the wrong relationship nowadays. I have more concrete suggestions when it comes to the word “user.”
The basic problem with the word is that it has been overused to the point of no longer having any specific meaning. “The dictionary’s first meaning is ‘the exercise of a right to the enjoyment of property’ (it’s a legal term). Also there is the meaning understood in the IT world: ‘a person or thing that uses [italics mine].’ I wonder how many of us perceive a ‘user’ in non-human form? And then there is the definition from Dave Barry, the humorist: ‘User, n. The word computer professionals use when they mean “idiot.”’ Putting aside the non-common use of the word, using the term ‘user’ conveys no specific, concrete, consistent usefulness to either the business community or the developers; we’ve just become used to the term ‘user’” [repetitive use of the word is intentional].

The term user refers to a vague, undefined, amorphous something that is interacting with our computer systems or our processes. In other words, specifying a “user” in our documentation does not really specify anything. The individual members of the business community define user to mean how they specifically use the system, and the developers just think, “idiot.”

Start with “User”

When we are starting out defining a system or the problem domain or a business process which we are going to improve everyone on the business side is either a stakeholder or a user. And that is all right. The term can be used as a placeholder until more information is available. But only at the beginning. If we are still referring to users in our final requirements we are essentially admitting we still don’t really know what the users use the system for.

Process Worker

We can start by separating the users, those who physically lay hands on the system, from those who work in the business process but don’t happen to sit at the monitor or interact in other ways with the system under consideration. As business analysts, we should be concerned with the entire business process in which the system under consideration plays a part, rather than just the system itself. We should identify the information that is entered into the system, of course, but also where that information comes from: when, where and how is that information created, and the processes the information goes through before being entered into our system. And, of course, where does information extracted from the system go, what is the final resting place for the information and what steps does it go through to get there? To help us remember the whole picture, the bigger system that our digital part fits into, we call anyone involved Process Workers. This helps us remember that in any business process there are more than users involved: there are customers (the organization’s customers), customer relations agents, salespeople, marketers, managers, mailroom workers, factory line workers, inventory control people, engineers and so forth, all of whom contribute to the overall business process but may not be users. Any changes we make to the “system” may cause a positive or negative impact on any of those process workers. As business analysts we must keep all the workers in mind when we are solving a problem or when our point of contact says “I need….” Remember that the point of contact or product owner is focused on his or her specific area of the overall process; we need to look at the bigger picture.

Consider a requirement that incorporates the term “user”:

“The user enters the name and address of the new account and presses ‘Submit.’

The system validates the information entered and assigns a unique account number…”

(Note that the requirement is purposefully not complete.)


As we begin to gather more information about the business process, the users or process workers become more specific. Instead of a user, the person is an Account Representative, or a Customer Relations Specialist, or some other position in the company. Typically when asked “What do you do?” the responder will start by saying, “I’m a [title of position] and I …” At this point we replace “user” with that position in our notes and conversations. No longer is that person a “user” to be clumped in with all the other “users” of the system, but is now a more specific “user,” one who performs specific tasks and functions with the system. At this point your terminology changes and you make a specific effort to eliminate “user.” Assume that wherever you have the term “user” you are missing information. 

When you replace “user” with the position — and replace the term everywhere, in your use cases, in diagrams, in documentation and in conversation — you informally categorize your requirements and make things easier. For example, when it comes time for review, those sections of the requirements in which Account Representative appears are the sections that will be reviewed by the Account Representatives and the Account Representatives only. You can have shorter, more effective review meetings when you are meeting with only those who have something to contribute about their process.

The agile concept of user stories emphasizes the use of positions or roles. The format of the user story is, “As a [specify role], I want to [specify function] so that I can [specify reason].”

Bottom line: “user” should not appear in your finished set of requirements or any diagram or reference to the requirements. Changing the example requirement above yields the following:

“The Account Representative enters the name and address of the new account and presses ‘Submit.’

The system validates the information entered and assigns a unique account number…”


But, you say, Steve, what about those people who use the system that we really don’t know anything about, who don’t have a title or position, like people using our websites? For years, the user-experience analysts have known that it is better to personify those who we expect to use our websites rather than refer to them as generic users. They create “personas.” The persona is a fictional creation that embodies all the characteristics of a typical member of the target audience for the website. The persona has a name, demographic description, and typical style and motivation of use. Personas are used not just by user-experience analysts to help define the look and feel of the web pages, but also by marketing to assist in creating the content.

As human beings, we react better to personalization than to generalization. The developers can design a better website for Rita the 67-year-old grandmother interested in buying gifts for her eight grandchildren online instead of fighting the crowds at the mall, or Tommy, the tech-savvy graduate student in Computer Science who needs more information about Predictive Analytics than for some gray ghost of an anonymous user out there.

We may not want to go as far as specifying the persona name in the requirements, but we certainly can specify the target user, by description, that we expect to be using each function.


Now I’m going to get real picky. In the name of precision and better technical communication, I suggest going one step further. Let’s not stop at the corporate position, let’s move on to the role.

Every position in the organization plays multiple roles during a given workday. Part of our analysis is to identify these roles, especially those played in the business process we are focusing on, and more especially the system. An Account Representative may enter customer information, add a new sale, create a contract, review a sales order, inquire into previous sales information, review new product information, and so forth. When Account Representatives do each of these functions, they are playing different roles. And these roles are ultimately what we want to capture for the developers. 

The system, and the code we are putting into the system, cannot distinguish between Tommy or the Account Representative. (You might suggest that by virtue of the Login Process the system knows who is using the system at any given point. But consider this: Alan, the Account Representative, logs on to the system and then leaves the computer to go to a meeting. Anyone else can sit at Alan’s computer and enter data or perform any function. How is the system going to know that the person pressing the keys is not Alan?) The system knows that a button is pushed, or a mouse click has taken place. Regardless of who pushed the button or what caused the mouse to click, the system must respond in the predetermined way. 

This approach now lines up with the concept of roles in use cases. The role of “adding an account” can be played by anyone with authorization to add an account. That role might be called “Account Adder.” Should we wish to specify this in a set of requirements we might say:

“The Account Adder enters the name and address of the new account and presses ‘Submit.’

The system validates the information entered and assigns a unique account number…”

Note the similarity in wording to that of a use case description Main Success Scenario.

You might think that writing requirements in this fashion perhaps seems a little silly. 

But wait, as they say in the infomercials, there’s more. We have one more step in our elimination of the user.


We’ve gone from totally abstract and generic wording, “user,” to totally specific wording “the account adder.” And since we really don’t care who is actually performing the function, perhaps we should go back to the term “user” instead of a silly moniker like “account adder,” which might sound like a poisonous snake with glasses. 

Rather than return to “user,” for purposes of clarity and specification to the developers, who have to analyze the requirements to produce the software, let’s go one step further and remove the user completely from the requirements. 

All the words about “user,” “Account Representative,” “Tommy” or “Account Adder” are meaningless to the developer writing the code to add a new account, and even less meaningful to the computer, which has to perform the function. Suppose in the requirements we state just what happens rather than who does it.

“When the name and address are entered and ‘Submit’ is pressed, the system validates the name and address and assigns a unique account number…”

When implemented, the code based on this requirement will execute the same as that of any of the previous requirement statements. However, with this stated requirement there is no uncertainty or questions about use.

Requirements are about specificity, preciseness, lack of ambiguity. We all agree that most of the communication problems we encounter that end up with contention on delivery are the result of vagueness and intentional or unintentional ambiguity. By changing a few words and phrases here and there, words we have used for so many years, they no longer have any real meaning, we can eliminate obfuscation and write better requirements, not to mention have more understandable conversations.

Don’t forget to leave your comments below