Theoretical highlight 10: Users, Tasks and Requirements
Part 2: User analysis
User analysis should answer questions about who the users are and what characteristics they have that might be important for the computer system. It is also important to learn about the environment where the users are working or using the system in. This includes both aspects on the physical environment as well as organizational issues.
Who are the users?
A modern switchboard used in small or medium sized offices has a whole range of technical features. For example, the users can, through their phone, register in the switchboard that they are out for lunch or out traveling. They also can use a built-in answering machine, and of course, use their phones for ordinary calls.
In the office entrance, the secretary sits in front of a computer display with a switchboard control application. In the computer application, the secretary can see when the staff programs their phones for going out for lunch and when they are supposed to come back. The secretary can see when a person is occupied and not able to take incoming calls and also choose to take a message or let the answering machine do that. People outside the office might come across some of the automatic features of the switchboard when they are calling, for example the automatic messages that the person they are looking for is out of the office, or 'talking' to the answering machine.
Sometimes it obvious who the users of a certain system are, but often, there is other groups of users that are harder to identify. In the example above, there are two obvious categories of users:
- The secretary operating the switchboard.
- The rest of the staff using the phones.
These two groups of users are of course necessary to study in depth and also find out what they need from a new system. A somewhat less obvious category of users, are all those who calls office from outside and have to interact with the features of the switchboard. These users must also be considered when a new system is developed. It is possible to find more groups of users, who are not included in the example, e.g. service personnel who are responsible for installation and maintenance of the switchboard system and support technicians from the manufacturer of the switchboard.
In the example, we can understand that the different users both have common needs as well as dissimilar requirements. But, what are the specific needs that distinguish, for example the secretary, from the others?
The users are categorized by different characteristics. Which characteristics that are important to examine, depends on the sort of information system to be developed. Some typical characteristics are:
- Goals and tasks - the users' comprehensive goals of using the system; personal, practical, organizational, main work tasks.
- The composition of the user group - age, gender, number of users.
- Cognitive and physical conditions and limitations.
- Education and experience - background, knowledge of the work, languages, computer experience and other skills.
- Aids and tools available - support, manuals and other documentation.
- The usage of the system - how often, how long, mandatory to use or not.
- Organization - division and organization of the work.
- Environment - in what context is the user interacting with the system: indoors/outdoors, mobile or stationary, in an office, control room or in cockpit of an aircraft. Are there any disturbances or special attributes in the environment?
Knowledge about users comes from different methods, for instance:
- Observation of users in their natural context or in a lab.
If it is possible, the most reliable information comes from meeting and studying real users in their normal context. But this is not always possible, as when completely new consumer products are developed. In these cases, the users are still unknown. Instead, other methods such as market surveys have to be used in order to map out potential users. Alternatively, there might be possible to find users of resembling or previous products. User studies in labs have to replace users in real environments.
Regardless of methods used, the purpose of the user analysis is to get knowledge about users, and categorize them according to background, personal conditions, work tasks and requirements for the user interface. The analysis results in:
- User profiles (user categories/classes),
- design conditions and recommendations, and
- a basis for requirements specification for the user interface and the system
Example user profiles - Laundry room booking
A computer based booking system for a common laundry room in a typical Swedish apartment house, where there are about 200 possibly users. The tenants consist of young and old people, as well as single households and families with children. The users can be categorized according to the following table:
|Young||Family with children||Older|
|Type of Household||1-2 persons||2-5 persons||1-2 persons|
|Computer literacy||Large||Medium - Large||Small|
|Laundry experience||Short||Medium - Long||Long, fixed habits|
|Laundry habits||Small amounts, irregular times, evenings, unplanned laundry||Large amounts, often and regular, afternoons, evenings, weekends, 'panic' laundry||Small amounts, regular, daytime, regular times / fixed laundry day|
Swedish is spoken and understood well by almost the entire user population, although there are a few users with only basic knowledge in Swedish. Therefore, the language in the user interface must be easily understood and complemented by graphical symbols.
Some users have disabilities such as visual and hearing impairment, color blindness.
Tenants moving in/out
The rate of movement in/out of the apartment house is relatively low. Most tenants moving is young singles/couples.
Today, booking of the laundry room is made on a notice board. The vision of the new system is that bookings could be made via the apartment house's intranet. The majority of the tenants have access to a personal computer of varying age, varying operating systems and web browsers. Some tenants have no access to a computer, so the system has to available in some way to them.
External circumstances - rules
Today, the laundry booking is restricted by the design of the notice board. There are four washing machines and one tumble drier in the laundry room; these are possible to book in periods of two hours. The laundry room is available between 7 am and 10 pm. There's a janitor to call if there's a problem with any of the machines.
The laundry room is booked relatively rarely; at most one or a few times every week. Every booking occasion lasts for a quite short time, a few minutes.
Developers are not users
It is important to realize the difference between real end users and on the other side, developers of different types: programmers, designers, usability experts, project managers, business analysts and domain experts. Developers are not users. They are always characterized by their role of being a developer. Domain experts are often users that have a lot of knowledge in the area of the new system, and are therefore used as experts in the development project. Their knowledge are often very important as sources of information, but as experts they are not typical users and after a short while, they are becoming more involved in the development process and distanced from the needs of the real users. Therefore, the knowledge of the domain experts must always be complemented with studies of the users that work daily with the system. The real end users are the best source of knowledge of how to design a specific system that is truly usable.
More information and examples of user categories: Getting to know your users.
An alternative or complementing approach to user categories is to use 'personas'. The concept of personas has been developed by Alan Cooper (1999) and is a part of a design approach that he names goal-directed design.
A persona is a representative model of users that are focused on the individual's goals and what she/he wants to achieve. When users are not available or even unknown, the persona represents these users. Cooper means that by designing for this particular model, the persona, the product can be usable for the real users.
Read more about personas in a separate document: Persona - an overview