See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/277721066

Grounding Design Work with Scenarios: A Process Control Case Example

Conference Paper · July 2004

CITATION READS

1 46

Some of the authors of this publication are also working on these related projects:

Qualidat - Quality of Data for Valid Decisions View project

DiWa (Digital War Room for Design) View project

All content following this page was uploaded by Marko Nieminen on 14 June 2015.

The user has requested enhancement of the downloaded file.

Toni Koskinen, Elina Jormanainen, Heini Korpilahti, & Marko Nieminen

Grounding Design Work on Scenarios:

User-Centred Design Framework in the Finnish
Process Industry

Toni Koskinen, Elina Jormanainen, Heini Korpilahti, & Marko Nieminen

[firstname.lastname@hut.fi]

Information Ergonomics Research Group (IERG)

Software Business and Engineering Institute

Helsinki University of Technology
P.O.Box 9210, FIN-02015 HUT, FINLAND

Keywords: Scenarios, User Centred Design, Prototypes, Usability evaluation, Process

Control

ABSTRACT
This paper presents a design framework that supports the creation and construction of
user-originated product features through utilizing and combining a variety of usability
engineering methods. The framework is focused on the early stages of design. It emphasizes
active user involvement as the foundation for design. The framework identifies scenarios as
essential elements of design. These scenarios need to be grounded in existing situations in real
work environments. The framework has been created and applied in the Finnish process
industry, where design accuracy in system design is essential, since the tasks carried out with
systems are in some cases safety critical.

1 Introduction
In recent years, a significant amount of research and development effort has
emphasized use- and user-oriented perspectives in the development of computer applications.
One of the most recognized
models emphasized in the user- Identify need for
oriented perspective of human-centred
design
application design is the
international standard ISO 13407
Understand &
(1999). It is a general reference specify the
model that introduces user- context of use

centred design principles and

processes (Figure 1), describing System meets
usability principles, activities, Carry out specified functional, Specify the user
user-based user & & organizational
and planning. No specific assessment organisational requirements
requirements
usability methods are presented
in the standard, since the focus is
on providing guidance for user- Produce design
centred design (UCD) processes. solutions

ISO 16982 (2002) presents

several specific usability Figure 1: Key activities of ISO 13407: Human-centred
methods supporting UCD. It design processes for interactive systems.
Toni Koskinen, Elina Jormanainen, Heini Korpilahti, & Marko Nieminen

provides an overview of the most frequently used usability methods that can be used in the
various stages of the design process. According ISO 16982, these usability methods are often
classified into data-gathering methods (interviews, contextual inquiries, and questionnaires)
and evaluation methods (expert evaluation and usability test of a design). These methods
either provide information as to whether the user-centred design goals are met or provide
requirements and suggestions that can be evaluated during later stages of UCD.
One complementary approach to producing requirements and suggestions for
computer systems is to use scenarios. Scenarios are “descriptions of required interactions
between a desired system and its environment, which detail normative system behaviour”
(Sutcliffe, Maiden, Minocha, & Manuel, 1998). Scenarios are usually in the form of 3-4 page
textual narratives (Gough, Fodemski, Higgins, & Ray, 1995) or storyboards. However, the
interaction can be presented in forms of video mock-ups or role-plays as well. (Carroll, 1995)
Whether analyzing an existing artefact or an artefact in design, a set of task scenarios
are usually created. Each scenario is a description of the possible activities of a user. A set of
these scenarios is a concrete representation of the overall use situations of the artefact. The
number of use-situations for any reasonably complex system can be virtually endless,
therefore the set of scenario representations are always incomplete. However, despite the
weaknesses of these representations, they are considered powerful in terms of communicating
the design representation of an artefact. The scenarios can be also used for usability
evaluation purposes and for composing task-oriented instruction or other support material.
(Carroll & Rosson 1992; Carroll & Rosson 1990)
The title of this paper refers to the argument that design work can be grounded on
scenarios. Kyng (1995) explained that users’ skills are not in evaluating complex and abstract
specifications, but in working in certain work contexts. Designers need to create work-like
contexts (scenarios) in order to utilize user participation in the design process. These
scenarios need to be grounded in existing situations in real work environments. This
grounding of scenarios supports real-world preferences and therefore enables users to evaluate
scenarios in accordance with the reality behind the scenario. Secondly, when grounding the
scenarios in real work environments, designers can avoid the blindness of choosing test cases
without the solid connection to the application area. (Kyng, 1995)

2 Aim of the Study

In recent years, one of the most recognized challenges in UCD has been to consider
how to transform the information about users and their work into an effective application
design (Wood, 1998; Graefe, 1998). The standards and methods presented above, as they
stand-alone, bring very little light to this issue. The aim of this study is not to provide an
exhaustive answer on how to bridge the gap between user-requirement documentation and
application design, but to present a design framework that identifies this challenge and
supports the creation and construction of user-originated product features through utilizing
and combining a variety of usability engineering methods. In addition, the framework also
empowers users and designers to participate in the UCD process right from the early stages,
enabling them to create insight into the design. It emphasizes scenarios as the foundation for
design. The idea of the early evaluation is to identify shortcomings proactively before the bind
assets of the design process make the modifications expensive to fix. Since the utilization of
the framework is still on-going, this paper focuses on the first stages of the framework.

3 Scenario Based Design Framework

The scenario-based design framework includes eight steps from present state context
of use analyses to usability evaluation of prototypes (Figure 2). It specifies results from
different steps as well as identifying possible evaluation objects. The topics of the steps are:
Toni Koskinen, Elina Jormanainen, Heini Korpilahti, & Marko Nieminen

present state analysis; identification of development subjects; scenario construction;

prioritisation of scenarios; sequence analysis; user, functional, and technical requirements for

STAGE RESULTS EVALUATION OBJECTS

Context of use descriptions, (Consolidated)

Present state analysis (Consolidated) communication flow models
communication flow models

Identification of Requirements for future

development objects scenarios

Scenario construction Scenarios

Activity scenarios
process

Priorisation of scenarios Use Scenario topics

Sequence analysis: why, Use Scenarios

Use Scenarios
how, when

User, functional, &

technical requirements of Requirements specifications Requirements specifications
use scenarios

Prototype construction Prototype Prototype

Usability evaluation of Evaluation report, revised Revised requirements

prototypes requirements specification specification

Figure 2: The different stages of scenario based design framework.

use scenarios; construction; and usability evaluation of prototypes. The framework is iterative,
enabling the utilization of data from each stage in the case needed. The early stages of this
framework utilize ethnographic interviews (Anschuetz & Rosenbaum, 2003) and work models
alike the ones in Contextual Design (Beyer & Holtzblatt, 1998). The middle stages of this
framework resemble the scenario-based framework presented by Rosson and Carroll (2002).
The Final stages of the framework utilize traditional usability methods (prototyping and
usability evaluation) and use case approach from requirements engineering.
The present state analyses define the context of use of the future product. At this stage,
ethnographic interviews are used as the data gathering method. In ethnographic interviews,
the team approach to contextual inquiry is applied in order to collect extensive data in
inquiries of up to two hours. Small teams share the activities of interviewing, note taking, and
photographing or collecting artefacts (Anschuetz & Rosenbaum, 2003). The gathered real-
Toni Koskinen, Elina Jormanainen, Heini Korpilahti, & Marko Nieminen

environment data is qualitatively analyzed and classified. The interaction flow models are
created to describe the work context of users, in this case process control workers (Figure 3).
The interaction flow models from different users can be joined together to describe larger
organizational units. Flow models also point out problems in existing work environments.
These models can be evaluated together with the same users that were originally interviewed.
This enables the end-users to provide realistic comments within the design process and share
further knowledge about their work context.
Identification of development subjects can be carried out in workshops. This is carried
out after all data has been analysed. Workshops can include members from researchers,
system developers, and users. The aim of this stage is to identify and share main findings
through the creation of different views and representations of the data. The results of this
stage define a starting point and boundaries to the scenario creation process.
The aim of the scenario construction process is to create realistic descriptions of
possible ways of working that take place in the future. At this stage, the scenarios focus more
on the working practices and activities and do not pay too much attention to details such as
the preferred appearance of the applications and user interfaces. Again, since the core of the
scenarios is in narrative form and does not contain any technical terms, they can be evaluated
together with both users and application developers.
During the next stage, the high-level scenarios are prioritised and further focused. The
aim is to identify and create more-specific use situations. During this stage the mechanisms
for accessing and manipulating the task information and activities are also identified. These
use situations are further analysed through asking Why? When? and How? questions. Use
scenarios are in narrative form and therefore easily understood by users. After the use
scenarios have been created, the focus turns towards user, organizational, and technical
requirements. User and organizational requirements are created from the present state
analyses. Use case presentation of the use scenarios can be created for the needs of software
engineering. Use cases are meant to present the basis of how the system interacts with its
environment (Kulak and Guiney, 2004). The technical requirements are specified against the
users’ existing environment.
The next stage is the prototyping of design ideas, based on the requirement
specifications. It can contain the construction of both hi- and low-fidelity prototypes.
Prototypes are evaluated by the users against requirements, while the specifications are
focused according to the evaluation results.

4 Ongoing work: Applying the Design Framework in the Finnish Process Industry

4.1 Background
In the area of distributed and collaborative process control, different stakeholders are
beginning to interact with each other through computer-mediated communication. Process
control work requires successful, real-time cooperation between different heterogeneous user
groups such as operators, maintenance personnel, remote experts, supervisors, and shift
foremen. Also the utilization of significant amounts of fragmented and networked expertise is
required in order to manage the production process. Due to the complex nature of this process
control domain, a significant challenge for system design is to keep end-users’ perspectives
and rich-use contexts actively involved throughout the different stages of system design and
development. The challenge is timely, since the responsibilities of individual process control
employees are increasing continuously, while work coordination increasingly requires
cooperation among people that are located in different places. The need to design systems that
support users’ intentions, distributed collaboration and cooperation, and social practices is
becoming increasingly important. The framework has been created and applied in the Finnish
Toni Koskinen, Elina Jormanainen, Heini Korpilahti, & Marko Nieminen

process industry, where design accuracy in system design is essential, since the tasks carried
out with systems are in some cases safety critical.

4.2 Applying the framework

The scenario-based design framework is applied to creating technology-mediated
interaction applications and practices for the future. We gathered data from eight sites in the
Finnish process industry during the winter of 2003-2004. The industrial sites included two
power plants, one pulp mill, one paper mill and four remote expert centres. The subjects of
this study were plant supervisors (N=3), control personnel (N=18), maintenance personnel
(N=14) and specialists (N=11). The specialists in remote expert centres were specialized
mostly in the specific issues of production process.
The data from existing contexts of use were gathered using semi-formal interviews
and ethnographic interviews. There were one to four persons interviewed at a time by two
interviewers. One interview took approximately two hours. The interview themes and
questions were planned beforehand. The topics of the interview included current work
environment, communication, artefacts, decision making, problem solving and cooperation-
related issues. The themes and questions were asked in variable order, depending on what the
interviewee was doing at the moment. During the interviews, the interviewees were asked to
show the artefacts that they use in their work and how they are used. Screenshots and
printouts of these systems and pictures of the work places were also taken when possible.
The data was analyzed and the flow models (Figure 3) were created. The idea of flow
questions about
Expert (remote) the situation
Shift foreman
- monitoring customer plants
information -coordinating sifts work
- replying to customer requests about changes can be forgotten
- monitoring current state of the process
- reporting findings - connections to outside sift personnel
- writing instructions
can include
Reports misinterpretations if
some data is missing
support
Paper requests
uncertainty about
documentation billing principles
- manuals requests for
can suppress some participates help when faults
- guidelines requests disturbance are noticed
Operator descriptions
- controlling the process help and support during
Notes on monitors - monitoring municipal district heating peaks in workload fault
network Weekly reports
- adjusting fuel usage meetings
normal Diary system sudden
entries Meeting Maintenance situations
agenda database can not be
predicted
read-only
Process control access
Intranet
system - plant specific List of
documentation, faults
checking alarms news, etc. maintenance
Maintenance
in problem works only
-repairing and replacing
solving situations during office
devices
-predictive/preventive hours
maintenance
system accessible
only in control room

Figure 3: A simplified example of the flow model.

models is to show communication flows and artefacts shared between persons and
workgroups. At first, a model was created after each interview. After all the models of one
case study were drawn, the models that represented the same work group – for example,
remote experts – were joined to form one model. Later on, the flow models representing
control personnel, maintenance personnel and remote experts of one case study were joined to
form one extensive flow model. When appropriate, a walkthrough of flow models together
with the users was arranged. The flow model presentation proved to be understandable by
users; it facilitated lots of in-depth discussions about the work context. Users were able to
point out errors and provide supplements to the model. The flow models were used in creating
Toni Koskinen, Elina Jormanainen, Heini Korpilahti, & Marko Nieminen

the requirements for scenarios. The flow model presentation was considered useful even
beyond initial expectations: one site considered using them as training material for new
employees.
After the case studies, an analysis workshop was held with the research participants
that had been involved in data gathering. At the beginning of the session, all participants
wrote the most important insights on sticky notes, so that one insight was on one note. Then
the notes were grouped on the wall in two ways. In the first diagram (“raw data”), the notes
were grouped according to the working group participants were close to (control personnel,
maintenance personnel, remote experts and customers’ customers). The second diagram
(“analysis/affinity diagram”) was formed on the basis of the themes that the notes were
representing. The themes that were identified in the selected case were service concept,
technology, organization of work and direct task-related issues.
Analysis methods provided two different kinds of views of the data gathered. The
diagrams provided the big picture of the data and helped to identify the most important trends
and development objects within the selected application domain, the process industry. The
diagrams were used in deciding themes for scenarios. The flow models, as detailed
descriptions, provided views into the real work domains. These details were used in scenarios
to keep them realistic. The workshop results were presented and further elaborated in
workshops that included members from system vendors and case organizations.
On the basis of the different views of the results, requirements for four high-level
scenarios were created: the organizational memory of specialists, the work context sharing,
and making specialist work apparent to the network of expertise of customer and building
specialists. Scenarios were constructed and grounded in existing real work environments.
Scenarios included background information, narratives (ways of working), visualization of
narratives, benefits compared to present situation, and requirements related to scenario.

4.3 Example scenario: the organizational memory of specialists

In this chapter, the basic structure of the activity scenarios is presented. These scenario
documentations are quite extensive, containing much information that can be utilized and
further focused in later stages of the framework.
The organizational memory of specialists represents a description of the information
support system that enables an organization to retrieve and utilize their past experience when
carrying out present tasks. The scenario document begins with the definition of organizational
memory and other essential terms, then listing the needs of specialists recognized from the
data gathered, and then describing the specialist group as an identified user group. In addition,
the reliability and accuracy of information was considered.
The example scenario includes three narratives that describe different aspects of
organizational memory. The first deals with using historical data in problem solving, the
second with receiving support for getting up-to-date with work tasks, while the third is about
saving a new report to system. Narratives describe situations that the specialists may face in
their work. The details for narratives have been picked out from flow models to keep
narratives realistic. Action sequences of the same narratives are also visualized with graphical
representations. Early experiences seemed to indicate that system vendors (developers) paid
more attention to the graphical representation of scenarios.
In the section of benefits compared to present situation, the scenario benefits are
considered at three levels: individual, organizational and business. At the end of the scenario
document, the generic requirements for the scenario are discussed. These requirements will
help to shift the focus towards the more detailed analyses of scenarios.
The utilization of this framework is still on-going; during the next stage, the scenarios
will be prioritised and further focused in order to identify more specific use situations.
Toni Koskinen, Elina Jormanainen, Heini Korpilahti, & Marko Nieminen

5 Conclusions
The early experiences of applying the framework have shown that different
representations of the data should be applied, depending on whether it has been presented to
the system vendor or user. The techniques used in this framework are relatively low-cost; the
early assumptions of design suggestions are expected to change. The key issue is to make sure
that different representations created with these methods enable users and designers to have
sufficient insight into the design. Users like to see the design suggestions (scenarios) tightly
coupled to their work environment and tasks. In order to create this sense of real world one
should consider using on-site data gathering methods, like ethnographic interviews. Equally,
system vendors might be more interested in seeing the same use situations transformed to use
cases or system descriptions.
It is obvious that paying this much attention to the early stages of design is laborious
when compared to the traditional, more straightforward, design models. However, in the
process industry, the costs of system delivery products are usually high, while the early design
stages form just a small fraction of the overall costs of the design and development process.
The accuracy during the early stages of design can be expected to cause considerable savings
in the total development process.
The early experiences of applying this framework also indicate that creating a user-
tailored representation of the data seems to empower users and system vendors to give well-
structured and argued feedback with respect to the issues under consideration. This is in line
with the findings of Gough et al. (1995), who describe a large case study in which scenarios
play the principle role; they comment: “from a stakeholder’s perspective, the participatory
process was both creative and motivating.”

6 Future Work
The aim of this research is to develop product and service concepts for the remote
expert services. This is done through utilizing various user centred design practices. The early
design framework presented in the study is further exploited, evaluated, and revised in the
near future.

Acknowledgements
The study was carried out in the research project TechMedia (www.soberit.hut.fi/
techmedia) funded by the National Technology Agency of Finland (www.tekes.fi) and
participating companies (Metso Corporation, Metso Automation, Metso Paper, Fortum
Service, Idean Research, Jyväskylä Science Park, and RecIT Solutions).

References
Anschuetz, L., & Rosenbaum, S., 2003, Ethnographic Interviews Guide Design of Web Site
for Vehicle Buyers. In Proceedings of CHI 2003, Fort Lauderdale, Fla., April 2003, pp. 652-
653.

Beyer, H. & Holtzblatt, K., 1998, Contextual design: Defining customer-centered systems.
San Francisco, CA: Morgan Kaufmann Publishers.

Carroll, J.M. & Rosson, M.B., 1990, Human-computer interaction scenarios as a design
representation. In HICSS-23: Hawaii International Conference on System Sciences. 1990. Los
Alamitos, CA: IEEE Computer Society Press, pp. 555-561.
 Toni Koskinen, Elina Jormanainen, Heini Korpilahti, & Marko Nieminen

Carroll, J.M. & Rosson, M.B., 1992, Getting around the taskartifact cycle: How to make
claims and design by scenario. ACM Transactions on Information Systems, 10, 2, 181-212.

Carroll, J.M., 1995, Scenario-based design: envisioning work and technology in system
development, John Wiley & Sons, Inc., New York, NY, 1995.

Gough, P.A., Fodemski, F.T., Higgins, S.A., & Ray, S.J., 1995, Scenarios - an industrial case
study and hypermedia enhancements. In Proceedings of the Second IEEE International
Symposium on Requirements Engineering, IEEE Computer Society Washington, DC, USA,
pp. 10-17.

Graefe, T.M., 1998, Transforming representations in user-centered design. In Wood, L. E.

(Ed.), User Interface Design: Bridging the Gap from User Requirements to Design. Boca
Raton, CRC Press, pp. 57-79.

Kulak, D. & Guiney, E., 2004, Use Cases: Requirements in Context, Second edition.
Addison-Wesley, Pearlson Education, Inc., Boston, 2004.

ISO/IEC 13407, 1999, Human-Centred Design. Processes for Interactive Systems, ISO/IEC
13407.

ISO/TR 16982, 2002, Ergonomics of human-system interaction - Usability methods

supporting human-centred design.

Kyng, M., 1995, Creating contexts for design. In Carroll, J. M. (Ed.), Scenario-based design:
Envisioning work and technology in system development, New York, NY: John Wiley &
Sons, pp. 85-107.

Rosson, M.B. & Carroll, J.M., 2002, Usability Engineering: Scenario-based Development of
Human-Computer Interaction, San Francisco: Morgan Kaufmann.

Sutcliffe, A.G., Maiden, N., Minocha, S., & Manuel, D., 1998, Supporting Scenario-Based
Requirements Engineering. In IEEE Transactions on Software Engineering, IEEE Press,
Piscataway, NJ, USA. Volume 24, Issue 12, pp. 1072 – 1088.

Wood, L.E. (Ed.), 1998, User interface design: Bridging the gap from requirements to design.
Boca Raton, FL: CRC Press.

View publication stats