Scenario
Building
Primary Reference Sources
Clark, L. (1991) The use of scenarios by user interface designers. In
Daiper, D. & Hammond, N (Eds.) HCI’91 conference proceedings, pp.103-115.
Nielson, J.(1991) Paper versus computer implementations as mock up
scenarios for heuristic evaluation. In Daiper et al. (Eds) HCI-Interact
’90 conference proceedings, pp. 315-320
Requirements acquisition through scenario building, Spool J., M.
(1994) Chi’94 Tutorial Notes.
Summary description
Scenarios are characterisations of users and their tasks in a specified
context. They offer concrete representations of a user working with a computer
system in order to achieve a particular goal. The primary objective of
scenario building is to generate usability requirements or targets. The
scenarios are created by the members of a development team who then role
play what it is like to be a user in order to form a group-wide user model
based on consensus. Scenarios also offer the opportunity to explore the
implications of design options and communicate interface issues to colleagues
for comment and critical feedback. Actual users are not involved in this
process. Scenarios may be utilised in the early phases of a development
cycle as a means of defining end user requirements. The method may also
substitute for user and task analysis which is rarely carried out in practice.
Typical Application Areas
Scenarios have generic relevance for the design of a broad range of systems.
Benefits
Scenario building encourages designers to consider the characteristics
of the intended users, their tasks and their environment.
Usability issues can be explored at a very early stage in the design
process (before a commitment to code has been made).
Scenarios can help identify usability targets and likely task completion
times.
The method promotes developer buy-in and encourages a user-centred design
approach.
Scenarios can also be used to generate contexts for evaluation studies.
Only minimal resources are required to generate scenarios.
The technique can be used by developers with little or no human factors
expertise.
Limitations
Scenarios are of particular relevance when considering user and task characteristics
rather than the detail of interface design and layout.
Cost of use
The resources required are minimal and scenarios should be quick to produce
(perhaps just a few hours?). An experienced moderator is recommended for
the sessions in which the scenario is explored, and up to 2 hours per session
may be required.
Costs of Acquisition
There are no purchase costs and although running costs should be minimal
a user may require a limited amount of experience in order to become familiar
with the technique.
Suitability for requirements engineering in Telematics:
RESPECT partners
may well have existing experience of employing scenarios, whilst the
transfer of this method to industry should be readily achieved. The method
also bears a close relationship to Usability Context
Analysis as used by NPL. In light of the benefits
of the method it should receive the attention of RESPECT.
How to get it
The method is not proprietary and appears to be widely used in both industry
and academia.
Detailed description of method
The principle steps for this method are as follows.
-
Gather together the development team and other relevant stakeholders under
the direction of an experienced facilitator.
-
Identify intended users, their tasks and the general context. This information
will provide the basis for the scenarios to be created by the development
team.
-
Functionally decompose user goals into the operations needed to achieve
them.
-
Assign task time estimates and completion criteria as usability targets
-
The session can be video-taped for later review or transcribed for wider
distribution
The results from scenario building sessions can be used to plan user-based
evaluations