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.
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:
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:
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. |