Contextual Design
Jenny Linnerud
Statistics Norway
Why?
Central IT
+ Generic solutions for the entire
organisation
- Lack local knowledge
+ Good exchange of best IT
practise
+ Identify common problems and
provide common solutions
-

Local IT
+ Specific solutions for local
needs
+ Good understanding of the local
needs
- Little exchange of IT experience
- Reinvent solutions

Contextual Inquiry

Context
 Go where the work is to get the best data
 Span time by replaying past events in detail
 Keep the user concrete by exploring ongoing work

Partnership
 Help users articulate their work experience
 Alternate between watching and probing

Interpretation
 Interpretation is the assignment of meaning to observation
 Ways that users say no – Huh?!, Ummm ... could be

Focus
 Clear focus steers the conversation
 Focus reveals detail but conceals the unexpected – expand your focus
 surprises and contradictions
Contextual Interview C3 p42 -66

What do the users want? Ask them!
 Identify the users
 Go to their place of work
 Observe them working
 When you are watching the work happen , learning it is easy
 Seeing the work reveals
 what matters
 details
 structure
 Talk to them about what they are doing
Contextual Interview
The contextual interview has 4 parts:
 the conventional interview
 introduce yourself and the project
 get to know the user and their issues
 the transition
 explain the new rules of a contextual interview
 You are the master. I am the apprentice.
 the contextual interview proper
 observe and probe ongoing work
 the wrap-up
 feedback a comprehensive interpretation
Mock Interview
8 groups of 3 people – 30 minutes

What are we going to build?
 A system for documentation of variables.

Why are we building it?
 What is the corporate VISION?

Who will use it?
 What user groups do we need to interview?

What are their backgrounds?
 How will we capture this?

What will it contain?
 Capture as many DETAILS as possible here.

What should we be able to do with the contents?
 Functionality

What else will it need to communicate with?
 Links and interfaces to other systems
Interpretation Session C7 p128 - 136

Go back to the project team with the results from the
interviews and try to reach a common interpretation of
these.




Look for related issues
Look for duplicate issues
Clarify questions in further interviews
Keep interviewing until nothing new comes up
Now what?
-> Structure the information
The Affinity Diagram C9 p154 – 163

The affinity diagram organises the individual notes captured
during interpretation sessions into a hierarchy revealing common
issues and themes.
green – group label summarising
an area of concern
pink – group label summarising
a set of groups
blue – group label
summarising points
below
white – individual
point captured in
interpretation
The Vision
General need for
documentation
General aim
Metadata for steering
processes
Variable definitions
Variable sources
Content +
Maintenance
Changes
Maintenance
Sensitive variables
Functionality
User friendliness
User support
Flexible reports
Link between variable
system and STABAS
Links
Link between variable
system and Datadok
Links with other metadata
systems and documents
Pilot system
General need for
documentation
General aim
Metadata for steering
processes
Variable definitions
Variable sources
Content +
Maintenance
Changes
Maintenance
Sensitive variables
Functionality
User friendliness
User support
Flexible reports
Link between variable
system and STABAS
Links
Link between variable
system and Datadok
Links with other metadata
systems and documents
Prototyping C19 p393-411
4 groups of 5-6 people – 30 minutes
Input: user requirements specification based on interviews
and affinity diagram
 The paper prototype

 the screen
 windows
 pull-down menus
 tool palettes and button bars
 radio buttons, check boxes, controls
 dialog boxes
 window contents
 anything that represents your intent and isn’t too complicated to
create or use is fair game
Testing






After prototyping an IT person should be able to write a functional
requirement specification for the subsystem.
Based on this document it should be possible for an IT person to build
the subsystem.
Testing should be conducted based on user scenarios.
The subsystem (including documentation) should then be
adjusted according to the users input and retested until the users
are satisfied.
The above phases (prototyping, testing) should be repeated until the
entire system has been built to the satisfaction of the users.
The updated user and functional requirement specifications can form
the basis for the system documentation
User participation in contextual design
# divisions
# people
Interviews
15
26
(26)
Walking the affinity diagram brainstorming
8
9
(2)
Paper prototype 1
8
10
(4)
Testing 1
11
15
(5)
Production
5
9
(5)
Paper prototype 2
4
5
(0)
Testing 2
4
5
(0)
Total # people – 42
(new*)
* new – not involved in any previous step
Reference
Contextual Design Defining Customer-Centred Systems
by Hugh Beyer & Karen Holtzblatt,
Morgan Kaufmann Publishers, 1998