Contextual Design Jenny Linnerud Statistics Norway Why Central

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 u 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 u Partnership ü Help users articulate their work experience · Alternate between watching and probing u Interpretation ü Interpretation is the assignment of meaning to observation · Ways that users say no – Huh? !, Ummm. . . could be u Focus ü Clear focus steers the conversation · Focus reveals detail but conceals the unexpected – expand your focus ü surprises and contradictions

Contextual Interview C 3 p 42 -66 u 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 u What are we going to build? ü A system for documentation of variables. u Why are we building it? ü What is the corporate VISION? u Who will use it? ü What user groups do we need to interview? u What are their backgrounds? ü How will we capture this? u What will it contain? ü Capture as many DETAILS as possible here. u What should we be able to do with the contents? ü Functionality u What else will it need to communicate with? ü Links and interfaces to other systems

Interpretation Session C 7 p 128 - 136 u 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 C 9 p 154 – 163 u 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 User friendliness Functionality 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 User friendliness Functionality 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 C 19 p 393 -411 4 groups of 5 -6 people – 30 minutes Input: user requirements specification based on interviews and affinity diagram u The paper prototype u ü 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 u u u 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 (new*) 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) Total # people – 42 2 Paper prototype * new 4 – not involved 5 in any previous step (0)

Reference Contextual Design Defining Customer-Centred Systems by Hugh Beyer & Karen Holtzblatt, Morgan Kaufmann Publishers, 1998