The Users: Get to Know Them

When we talk about users, we mean the people who will ultimately operate your product. The stakeholder map (Figure 3.6) refers to them as normal operators to emphasize that we are concerned with people who will have direct contact with the product. For in-house products, the users are usually the people who work for your client. For external products, the users and the customers may be the same people.

Identifying the users is the first step in understanding the work they do. After all, your product is intended to help with this work. Additionally, you have to know what kind of people they are so you can write the correct usability requirements. You have to bring about a product that the users can and will use. The more you know about the users, the better the chance you have of specifying a suitable product.

The purpose of identifying the users is so that you can understand the work that they do.

Different users will make different demands on your product. For example, an airline pilot has very different usability requirements from, say, a commuter buying a ticket on a rail system. If your users are commuters, then a "person without cash" and a "person with only one arm free" would raise their own usability requirements.

Don Gause and Jerry Weinberg give a wonderful example of brainstorming lists of users in their book: Gause, Don, and Gerald Weinberg. Exploring Requirements: Quality Before Design. Dorset House, 1989.

There are always too many potential users, and too many that might be forgotten or overlooked. We recommend that you build a checklist of the categories of people who might conceivably use your product. List their role or work title, or describe their job. Add any abnormal or unusual attributes, such as users who would use your product while driving or simultaneously with another product. Also consider the user's physical locationoutside, on an aircraft, in a public place.

The consideration of potential users is vital for agile development. Too often we see only one user asked to supply the requirements for a product, and little or no consideration given to what will happen when the product is released to a wider audience. We strongly urge you to always consider the broadest spectrum of users and, at the very least, to choose user stakeholders from both ends.

For each of the user categories that you have on your list, identify the particular attributes that your product must cater to:

• People with disabilities:Consider all disabilities. This, in some cases, is a legal requirement.

• Nonreaders: Consider people who cannot read and people who do not speak the home language.

• People who need reading glasses: This is particularly near and dear to one of the authors.

• People who cannot resist changing things like fonts, styles, and so on.

• People who will probably be carrying luggage, large parcels, or a baby.

• People who do not normally use a computer.

• People who might be angry, frustrated, under pressure, or in a hurry.

For the users, write a section in your specification to describe, as fully as possible, all known and potential users and their attributes. For their attributes, consider these possibilities:

• Subject matter experience:How much help do they need?

• Technological experience:Can they operate the product? What technical terms should be used?

• Intellectual abilities:Should tasks be made simpler? Or broken down to a lower level?

• Attitude toward the job: What are the users' aspirations?

• Education: What can you expect your user to know?

• Linguistic skills: Not all your users will speak or read the home language.

We realize that writing all this stuff down seems like a chore. However, we have found that taking the time to write something down so other people can read it is one of the few ways for you to demonstrate that you understand it. The users are so important to your cause that you must understand what kind of people they are and what capabilities they have. To wave your hands and say, "They are graphic designers," falls short of the minimum level of understanding.

Another class of stakeholder in the operational work area is maintenance operators. From these people you will discover the appropriate maintainability requirements.

Operational support is another source of requirements relating to the operational work area. Roles that are sources of these requirements include help desk staff, trainers, installers, and coaches.

People other than the intended users might end up using your product. It is better to identify superfluous users than to fail to find them all.

At this stage, any users you identify are potential users. That is, you do not yet precisely know the scope of the productyou determine this later in the requirements processso at this stage you are identifying the people who could possibly use, maintain, and support the product. Remember that people other than the intended users might end up using your product. It is better to identify superfluous users than to fail to find them all.