1. 5/20/2002 1 Conducting and Analyzing a Contextual Interview ICS 205 Spring 2002 Tom Herring Ratiya Komalarachun

2. 5/20/2002 2 Introduction After K. Holtzblatt and S. Jones, Human- Computer Interactions: Toward the Year 2000, by R. M. Baecker, J. Grudin, W. A. S. Buxton, and S. Greenberg, pp. 241-253, Contextual inquiry arose from the need to build a general purpose computer system which would be successful in a varied set of user cultures. A system includes hardware, software, services and customer support.

3. 5/20/2002 3 Specific Challenges Identify a process which supports people who do similar work but operate in significantly different businesses and national cultures. Identify a process which efficiently gathers user information within limited time constraints. Identify a means which accurately translates users’ work information into a form that helps Engineering design a system that meets our goals.

4. 5/20/2002 4 Comprehensive and Consistent Vision The technique involves all the team members (hardware and software engineers, people and product managers, writers, marketing and customer support personnel). Participation by all these members fosters team work and the development of a shared and consistent vision.

5. 5/20/2002 5 Contextual Inquiry Principles Not a set of steps or a walkthrough checklist A process, guided by:  Context  Partnership  Focus

6. 5/20/2002 6 Context -- Rich in Information Design information is presented in its most comprehensive form when we speak with people during the performance of their tasks. By way of contrast, design information is presented primarily as abstractions when people are queried ‘off the job’, losing important information in the process.

7. 5/20/2002 7 Context -- Teasing the Data People do not usually think about their work process and the impact of computer tools on their work. Computer designers are able to ‘tease’ design information from the users most effectively when the user is actually performing their task(s).

8. 5/20/2002 8 Context -- Detail vs. Summary When asked about a computer system, users will give abstract, summary information. When queried while performing a task on a computer system, users remember much more detail about the system’s positive and negative attributes.

9. 5/20/2002 9 Context -- Finding Touchstones Touchstones help people recall their work experiences. Touchstones are ‘crib’ sheets taped to a wall or computer monitors, documentation that is actually opened and used, documents used in meetings, and other artifacts people use to support the performance of their tasks.

10. 5/20/2002 10 Context -- The Principle Dialogue with users in their work context. Tease design information from users while they are ‘in process’ to gain the greatest level of detail. Be aware of touchstones and the roles they may play in the performance of tasks.

11. 5/20/2002 11 Partnership -- Sharing Information Context leads us to dialogue. Partnership with users makes this dialogue effective, producing quality information. Information is shared, not extracted, through this approach.

12. 5/20/2002 12 Partnership -- Expert Users Acknowledging users as the experts and the source of understanding: - makes the designer the student; questions are expected, then, from the designer - designers are tempted to less interpretation given their status as students of the user

13. 5/20/2002 13 Partnership -- Shared Control Detecting the difference between dialogue and interrogation (free flow vs. start, stop, wait for the next question from the designer). Open ended questions, recognizing the user’s expert status, communicate shared control to the user.

14. 5/20/2002 14 Partnership -- Reflect and Engage The designer engages the user in a conversational, stream of consciousness discussion. The designer then reflects upon what has been shared, integrating it into the evolving understanding of the task. This process is repeated, allowing both partners to steer the conversation.

15. 5/20/2002 15 Partnership -- The Principle By assuming the roles of expert in the respective areas of task performance (User) and computer system design (Designer) who partner to jointly create a new design, we optimize the quality and quantity of shared information about the new design’s requirements.

16. 5/20/2002 16 Arranging the Visit Identifying Customers - the business or industry sector we expect to buy our products - the individuals that will interact with our system Marketing earns its keep by getting the team in to visit an important customer

17. 5/20/2002 17 Preparing the Framework Once a customer contact is established, we prepare our visit objectives and schedule before we call our contact. We prepare for the visit in all respects, including necessary hardware (video equipment, etc.). We are considerate of the customer’s business needs.

18. 5/20/2002 18 Conducting the Interview Focus -- select people who: - use the system directly (users) - manage the users - receive the system’s products (recipients) - test the system and interface with management with the results/ make purchasing decisions - use a competitive (similar) system

19. 5/20/2002 19 Conducting the Interview Focus -- large work domains require segmentation of the interview team and process: - breakdown the organization’s work domain into ‘chunks’ and perform several sequential visits as necessary - identify key people for each visit segment

20. 5/20/2002 20 Conducting the Interview Focus -- focus keeps us ‘on track’ with who we interview, keeping costs down and speeding the process while minimizing the impact to the customer’s organization. Subsequent visits -- focus directs the decision of whom we will interview at the next visit

21. 5/20/2002 21 Conducting the Interview Multiple Interviewers are beneficial: - different perspectives (engineering, documentation, service, training) combine to present a complete picture to the team - team integration of data naturally includes information gained from the interfaces with the other perspectives.

22. 5/20/2002 22 Setting the Focus Before the Interviews Discussing about the focus for this visit. Discussing about what aspects of the work will be probed. Entering assumptions and focus

23. 5/20/2002 23 Setting the Focus before the Interviews Making notes on key areas. Clarifying its purpose. Discussing these notes with the user to focus on the conversation.

24. 5/20/2002 24 Structure of a Contextual Interview A typical Contextual Interview: – Introduction: Establishing a relationship – Ongoing work inquiry – The wrap-up

25. 5/20/2002 25 Introduction: Establishing a Relationship Introducing oneself to users. Assuring them for the confidential. Asking for the permission to record the interview. Informing them the purpose of this visit.

26. 5/20/2002 26 Introduction: Establishing a Relationship Informing how long it will take. Asking them to give the overview of their works. Discussing what specific work they are doing during the visit. Asking for the opinion about the tools they are using.

27. 5/20/2002 27 Ongoing Work Inquiry Goals: – To articulate a coherent understanding of the users’ work process. – To uncover the needs for the work – To uncover what supports or hinders the work. – To build a shared understanding of users’ work.

28. 5/20/2002 28 Ongoing Work Inquiry Asking Questions and sharing ideas as users work. Watching them in silence. Sharing our interpretations and design ideas.

29. 5/20/2002 29 Ongoing Work Inquiry Suggesting a break or end a session as needed. Ensuing that users are equally involved in the partnership. Letting users lead the discussion by keeping the questions open-ended.

30. 5/20/2002 30 Ongoing Work Inquiry Redirecting the conversation as needed. Asking about workarounds. Bringing out assumptions that we have when users refer to that area.

31. 5/20/2002 31 The Wrap-Up Summarizing what we learned by referring to our notes. Discussing any questions that might occur during the interview. Validating or invalidating our assumptions.

32. 5/20/2002 32 The Wrap-Up Giving some tips about the software. Asking them if we can contact them later for further questions. Inviting them to contact us if they think of something after we leave. Thanking them for their times.

33. 5/20/2002 33 Variations in the Use of Contextual Inquiry Collecting information about work and system use from people as they work. Maximizing the information. Spending 2-3 hours. Using the principles of context to design alternative information collection schemes.

34. 5/20/2002 34 Analyzing Contextual Inquiry Information Interpretative process. Results in a shared understanding of users’ work and system use. Build an understanding of user and organizational work practices, a system vision, and specific design ideas.

35. 5/20/2002 35 Analyzing Contextual Inquiry Information Analysis taking place both during and after the interviews. Integrate multiple perspectives. Create a shared vision of the system and a shared focus for subsequent interviews.

36. 5/20/2002 36 Analyzing Contextual Inquiry Information Consist of 5 parts: – Transcribing the Interview – Fixing and Evolving the Focus of Analysis – Interpreting the Information – Recording Understanding – Structuring the Understanding

37. 5/20/2002 37 Transcribing the Interview It is important to transcript notes and tapes while the interview is still fresh in memory. Reviewing the interview helps us refocus for the next set of interviews. We may include comments, insights, or questions that arise.

38. 5/20/2002 38 Fixing and Evolving the Focus of Analysis It is important to clarify our focus before beginning analysis. “What is our purpose of design concern?” Our focus directs what we include and exclude. Some brought up questions might be useful.

39. 5/20/2002 39 Interpreting the Information Bringing the focus to the information guides our interpretation. Changing the focus, different aspects are revealed. Discussing about users’ work and the system.

40. 5/20/2002 40 Interpreting the Information Using and reusing the user’s language. Moving back and forth between the specific instance being examined and the whole session.

41. 5/20/2002 41 Interpreting the Information The reusable knowledge provides us with a framework: – Work structure or work flow – Problems accomplishing the work – Problems in system use – Disruptions caused by the system – Workarounds that are used to avoid disruption from the system – Transparency of the system – Aspects of work process and system use that support work

42. 5/20/2002 42 Recording Understanding As we interpret the text, we record our understandings. Using the a coding scheme. Using the Post-it or note cards. Reviewing each conducted interview one at a time.

43. 5/20/2002 43 Recording Understandings What we record: – A description of users’ work – The flow or structure of the work – A description of problems in their work – A description of problems with the computer tools – Design ideas that emerge from our understanding of their work – Questions for subsequent interviews

44. 5/20/2002 44 Structuring the Understanding Working effectively with large amount of information requires some structuring. Using a technique to support inductive thinking. Dividing all Post-its among team members.

45. 5/20/2002 45 Structuring the Understanding Grouping them conceptually. Continuing grouping them until stable. Reviewing each group and assigning the name.

46. 5/20/2002 46 Using Contextual Inquiry Throughout the System Development Cycle Each phase of development has key questions and tasks to which engineering teams must respond. The first phase development question: – “What should we build?” – Determine a product strategy and product requirement.

47. 5/20/2002 47 Using Contextual Inquiry Throughout the System Development Cycle – What is the user’s work? – What tools are currently used? – What works well and why? – What are the problems that we can address with our technology?

48. 5/20/2002 48 Using Contextual Inquiry Throughout the System Development Cycle The second phase of development: – Focused on project planning and preliminary design. – Used contextual inquiry with paper prototyping to define the system work model. – Used Metaphor Workshops, scenario building, and user participation in design meetings.

49. 5/20/2002 49 Using Contextual Inquiry Throughout the System Development Cycle The third phase of development: – Include design and coding of the implementation. – Used contextual inquiry to codesign the system work model and user interface with users.

50. 5/20/2002 50 Using Contextual Inquiry Throughout the System Development Cycle The forth phase of development: – Involving external field test of the system. – Conducting contextual inquiry sessions with users in their environment while they are using the system for their work.

51. 5/20/2002 51 Using Contextual Inquiry Throughout the System Development Cycle Throughout the development cycle, user collaboration and system design are part of an ongoing, iterative process. The results of the inquiries are incorporated into the design of the system.