CHI 97 Electronic Publications: Tutorials
Getting Started on a Contextual Project
Karen Holtzblatt, Hugh Beyer
InContext Enterprises, Inc.
249 Ayer Rd. , Suite 301
Harvard, MA 01451 USA
telephone: +1-508-772-0001
email: karen@acm.org, beyer@acm.org
ABSTRACT
Field data gathering techniques such as Contextual
Inquiry enable a design team to collect the detailed customer
data they need for their projects. But when a team wants to apply
contextual techniques to their own situation, they are faced with
a host of problems. What project should they start with? Is it
better to introduce them early or late in the process? Given all
the different possible techniques, which will work best for the
specific project chosen? How should the customers be chosen and
how should visits to them be set up? Who should be on the project?
It's no wonder people find it hard to get started with these new
techniques in their own organizations.
This tutorial gets participants over the roadblocks
in the way of using contextual techniques in their projects. We
walk through the different aspects of a contextual project, describing
the issues that need to be resolved, the different approaches
that can work, and the principles which guide making a choice.
We use exercises to give participants the chance to plan aspects
of their own projects, so they can do the thinking process themselves
and raise any questions raised by their own situations.
This tutorial is appropriate to anyone wishing to
use field methods to gather customer data for their projects.
Some familiarity with these methods is assumed.
Keywords
analysis methods, design techniques, customer-centered
design, ethnography, usability engineering, methodology, team
design, domain analysis, work modeling, software engineering,
task analysis, user models, user studies work analysis
© 1997 Copyright on this material is held by the authors.
CONTENT
This tutorial covers the process of moving from an
initial project situation or problem statement to a plan for gathering
and using customer data in that project. We describe the issues
to consider, the decisions to make, and the criteria to use for
making them. Through exercises and discussion, we give participants
the opportunity to plan their own contextual project and address
specific issues important to them.
Setting Project Focus
The first issue is to decide what project is a good
candidate for trying new techniques on. This is a decision which
has both organizational and technical implications. To generate
excitement and follow-on projects in the organization, the project
should be highly visible and important; but since the techniques
will be new to everyone involved, there should be some margin
for error. Some projects have large user interface components
and support work which is easy to study; others are focused on
work which is difficult to study: // infrastructure or work which
is proprietary, cognitive, of very long duration, or otherwise
difficult to observe. A project may be at the start of the cycle,
ready to consider a wide range of possibilities for specific requirements,
or it may be winding up work on a version and be unwilling to
consider anything more than minor usability fixes. Finally, the
attitude of the project team determines whether they will be open
to using new techniques to incorporate customer data.
We discuss how to balance these different considerations
against each other to determine the most effective place to put
effort using contextual techniques. We talk about how deliver
the right kind of customer data for different points in the life
cycle and different kinds of projects, and how to set focus for
the project to identify who the customer population is, what work
will be affected, what the key issues are for the design team.
Defining the Data Gathering Situation
Once the project focus is set, the team has defined
what customers are served by the project and what aspects of their
work will be affected by the new system. The next decision is
how to collect information about this kind of work. The team has
to decide the specific work tasks which will guide the design,
and given the nature of those tasks how to find out about the
work. Some work is amenable to simply showing up and observing,
but other kinds of work are more difficult: if the work is spread
out over years, the techniques need to look across time; if the
work is highly detailed (e.g. the specific interaction with a
tool), the techniques need to capture and reveal the detail; and
if the work is very intermittent (e.g. using help) then the techniques
need to capture and collect data from all the different instances.
The team also needs to decide what specific customers
to talk to. Contextual techniques always look for the greatest
variety of work within the target customer population; the team
needs to determine what customer characteristics will lead to
different work situations and from that develop a list of potential
customer sites to visit. They then need to drive the logistics
of locating this kind of customer, planning and setting up the
visits.
We discuss how to choose the specific customers and
organizations to gather data from based on the project focus.
We show how to decide what particular work tasks will be critical
to the design. We review different contextual techniques and the
criteria for choosing the best ones to use given the work situation
and project focus. We define how to set up the data gathering
situation and discuss using the organization's own contacts to
find specific customers and set up the visits. Finally we discuss
how to decide on a method of interpreting the results of the visits
so findings can inform the design.
Defining the Team Structure
Any project planning needs to account for the people
on the project and the people to whom the project is accountable.
If the team is open to involving customers it may be possible
to integrate data collection and usage into project activities.
If the team is more resistant, it may be necessary to run the
data collection as a separate activity (perhaps with the involvement
of friendly project members) and manage the communication of findings
and implications to the larger project team. In any case, the
results of the investigation and impact on the project design
needs to be communicated to management and to other interested
parties, both to show benefit on this project and to demonstrate
the worth of the techniques.
We discuss the issues of organizing the data collection
team: whether it should be a separate team or a subset of the
development team, how to manage the time commitments of the different
team members, and how to communicate results to the rest of the
organization, tailoring the communication to the audience.
CONCLUSION
Successfully putting new procedures and techniques
in place in an engineering organization involves more than just
learning the skills. New ways of working affect everyone, and
everyone will have opinions and feelings about the change. Practitioners
who hope to introduce more customer involvement successfully need
to understand both the practical, logistical aspects of implementing
the new techniques as well as the organizational implications
of integrating them into project activities. This tutorial gives
participants insight into both sets of issues, while guiding them
through the step-by-step planning for a specific project.
REFERENCES
H. Beyer, "Calling Down the Lightning,"
in IEEE Software. September 1994, Vol. 11 No 5, p. 106
B. Curtis, M. I. Kellner, and J. Over, "Process
Modeling," Communications of the ACM, September 92,
V 35, No. 9.
P. Ehn, Work-Oriented Design of Computer Artifacts.
Gummessons, Falkoping, Sweden 1988, international distribution
by Almqvist & Wiksell International, also Coronet Books, Philadelphia,
PA.
K. Holtzblatt and S. Jones, "Contextual Inquiry:
A Participatory Technique for System Design," Participatory
Design: Principles and Practice. Aki Namioka and Doug Schuler
(Eds.), Hillsdale, NJ: Lawrence Earlbaum Pub. 1993.
K. Holtzblatt and H. Beyer, "Making Customer-Centered
Design Work for Teams," Communications of the ACM,
October, 1993.
K. Holtzblatt and H. Beyer, "Representing work
for the Purpose of Design," in Representations of Work,
HICSS Monograph (Hawaii International Conference on System Sciences),
January 1994. Lucy Suchman, Editor.
K. Holtzblatt and H. Beyer, "Contextual Design:
Principles and Practice," Field Methods for Software and
Systems Design. D. Wixon and J. Ramey (Eds.), John Wiley &
Sons, Inc., NY, NY, (forthcoming).
K. Holtzblatt, "If We're a Team, Why Don't We
Act Like One?", in interactions, July 1994, Vol. 1
No. 3, p. 17
M. Kyng, "Making Representations Work,"
in Representations of Work, HICSS Monograph (Hawaii International
Conference on System Sciences), January 1994. Lucy Suchman, Editor.
P. Sachs, "Transforming Work: The Role of Learning
in Organizational Change," in Representations of Work,
HICSS Monograph (Hawaii International Conference on System Sciences),
January 1994. Lucy Suchman, Editor.
L. Suchman, ed. Communications of the ACM
issue on 'Representations of Work', September 1995.
CHI 97 Electronic Publications: Tutorials
