160 likes | 233 Views
Contextual Design. Jenny Linnerud Statistics Norway. 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
E N D
Contextual Design Jenny Linnerud Statistics Norway
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 Why?
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 Interview8 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 SessionC7 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 DiagramC9 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
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 Links with other metadata systems and documents Link between variable system and Datadok 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 Links with other metadata systems and documents Link between variable system and Datadok Pilot system
PrototypingC19 p393-4114 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 Total # people – 42 * new – not involved in any previous step
Reference Contextual Design - Defining Customer-Centred Systems by Hugh Beyer & Karen Holtzblatt, Morgan Kaufmann Publishers, 1998