Brainstorming User Roles and Scenarios
By Jörg Beringer, Stephen Corbett, and Günter Schmidt, SAP AG
This paper is outdated.
Abstract
The technique described in this article is an approved way to gather important information about the users who should be supported with your software. It comprises the identification of the task sets which define the user role as well as the user profile which defines the design relevant characteristics of these roles.
The aim is to design an optimal tool for a certain group of persons who want to perform a certain set of tasks.
An important measure for increasing the usability of a software product is therefore to find out which users should be supported in which tasks with a software application.
This enables you to design the tool so that the user can perform his tasks effectively and without interference.
You should share the knowledge about this context in the development team and improve communications within the team by holding one or more brainstorming sessions that define the actual or planned user roles and describe these roles with realistic user scenarios.
Who Should Take Part?
To take advantage of all existing sources of information, this meeting should include a diverse group of participants. People from such groups as development, documentation development, product management, marketing, consulting, and training should be invited.
User Roles and Tasks
In this meeting, the participants jointly identify a list of user roles representing the potential software users. The user roles should be defined by the intentions, objectives and responsibilities, and not simply by global job descriptions. It is important that the tasks be described by the intentions they represent, and not simply as working steps.
When brainstorming user roles, the participants should list the user profiles and tasks that can be expected in an application area. When you encounter a typical user role, you should consider which tasks this user role should perform.
At the end of brainstorming, the entire target market of the software application should be documented for each of the user roles. If there is sufficient knowledge about the work organization, the user roles can also be represented in a communication network, which shows the user roles as nodes and links them with communication paths.
User Profiles
Every user role is described by the set of tasks to be performed and by the user profile. The user profile describes the design-relevant characteristics of the user role, such as occasional or continuous use, trained or not trained.
The user roles can be communicated more easily with the team members if realistic user scenarios (short description of how the software program is typically used) are written down for the most important user roles. These scenarios describe what is meant with the particular user role and what is characteristic about it. Scenarios can also be used as the starting point for later testing and as examples in the documentation, and can therefore be reused.
Results
Brainstorming sessions about user roles and scenarios help to record and communicate implicit knowledge about the users, their characteristics and their tasks. This ensures a knowledge transfer between team members having a "good" knowledge of the market and those without customer contact who are primarily concerned with technical aspects.
During brainstorming, it is important to collect the knowledge from the different team areas and to write down all open questions and important findings. In addition to the user roles identified, the results should also show what the team knows, what it does not know and what it would be important to know.
The user/task model explicitly defined in this way helps to adjust the application to the user requirements and the structure of their work during design. The model, however, is only based on the assumptions made by the team and the collective knowledge about the market. As a result, it is possible that only the typical and not the atypical cases are described, and that the assumptions made about the end users are simplified and too narrow in scope.
You should therefore see the brainstorming sessions as a basis and preparation for a series of customer visits in which certain customers and users are selected to analyze real work practice based on the user roles and open questions.
