CHAPTER 3. CONTEXTUAL INQUIRY: ELICITING WORK ACTIVITY DATA

1. CHAPTER 3. CONTEXTUAL INQUIRY: ELICITING WORK ACTIVITY DATA Khoa Tran, Huayu Zhou, Alex fiannaca

2. Introduction Khoa

3. Contextual Inquiry - Introduction • Goal: To understand customer’s work practice • "Getting your nose in customer’s tent" • Roots in ethnography • Branch of anthropology focusing on study and systematic description of human cultures

4. Example • Work Set of activities people undertake to accomplish goals in work domain • Work Domain Entire context of work and work practice in target enterprise or other target usage environment

5. Example • Work Practice • Followed and observed in customary performance of a particular job to carry out operations of enterprise • Involves learned skills, decision making, physical actions, and social interaction • Can be based on tradition, ritualized, and habituated • Work Activity  Work activity composed of sensory, cognitive, and physical actions made by users in course of carrying out work practice

6. Example • Voting Booth 1.)  http://www.sandybarris.com/wp-content/uploads/2009/01/voting_booth.gif 2.)  http://changeforbetterme.files.wordpress.com/2012/07/stock-illustration-9380095-old-lady-with-walker.jpg

7. What is contextual inquiry? • Contextual inquiry • UX lifecycle activity to gather detailed descriptions of customer or user work practice • For purpose of understanding work activities and underlying rationale • Goal: To improve work practice and construct and/or improve system designs to support it • Contextual inquiry is about the way things are done now

8. What is contextual inquiry? • Includes • Interviews of customers and users (what they say) • Observations of work practice in real-world context (what they do) • Not “requirements gathering” in traditional sense

9. Contextual Inquiry - Outline Contextual Inquiry Preparation Collection of User  and Work Activities System Concept

10. System concept statement • System (or product) concept statement • Typically 100 to 150 words in length • Mission statement for new system to be developed • Explains system to outsiders • Helps set focus and scope for system development internally

11. System concept statement • An effective system concept statement answers at least the following questions: • What is the system name? • Who are the system users? • What will the system do? • What problem(s) will the system solve? (Be broad to include business objectives) • What is design vision and what are the emotional impact goals? • In other words, what experience will system provide to user?

12. Introducing a running example • Existing: The Middleburg University Ticket Transaction Service (MUTTS) • Central event ticket office, like the one on campus • Target: The Ticket Kiosk System • Distributed self-serve kiosk system • Especially want kiosks at bus stops around town

13. Example: For Ticket Kiosk System The Ticket Kiosk System will replace the old ticket retail system, the Middleburg University Ticket Transaction Service, by providing 24-hour-a-day distributed kiosk service to the general public. This service includes access to comprehensive event information and the capability to purchase tickets rapidly for local events such as concerts, movies, and the performing arts. The new system includes a significant expansion of scope to include ticket distribution for the entire MU athletic program. Transportation tickets will also be available, along with directions and parking information for specific venues. Compared to conventional ticket outlets, the Ticket Kiosk System will reduce waiting time and offer far more extensive information about events. A focus on innovative design will enhance the MU public profile while “Fostering” the spirit of being part of the MU community and offering the customer a “Beaming” interaction experience. (139 words)

14. User work activity data gathering – Core of Chapter 3 • Contextual inquiry – How to do it Essence • Prepare and conduct field visits to customer/user work environment - where system being designed will be used • Observe and interview users while they work • Inquire into structure of users’ own work practice • Learn about how people do work your system is to be designed to support • Take copious, detailed notes: Raw user work activity data Huayu

15. User work activity data gathering • Most general case – domain-complex systems • High technical content • Elaborate work flow and inter-role communication • Need to avoid risk e.g. an Air Traffic Control System From Afar

16. Before the visit: Preparation for system with complex work domain • Learn about your customer organization Issues about the customer: • Get feel for customer’s organizational policies and ethos By looking at their online presence, such as • Website • Participation in social networks • Understand vocabulary and technical terms of work domain • Learn about competition

17. Before the visit: Preparation • Learn about your customer organization Issues about the customer: (continued) • Learn about culture of work domain in general • Example, conservative financial domain vs. laid-back art domain • Recognize differences in perspectives between managers and users • Investigate current system, practices, and history • Look at company’s existing and previous products • If software, download trial versions to get familiar with design history and themes

18. Before the visit: Preparation • Learn about the domain Issues about your team: • Decide how many people to send on visits • UX people and other team members • Set own limits on number of visits and number of team members • Depending on your budget and schedule • Plan interview and observation strategy (who in team does what)

19. Before the visit: Preparation • Learn about the domain Lining up the right customer & user people: Selectand contact appropriate users or customer management and Administrative people to: • Explain the need for a visit • Explain purpose of visit: to learn about their work activities • Explain approach • Build rapport and trust Promise personal and corporate confidentiality

20. Before the visit: Preparation (continued) • Identify areas of activity and users for observation and interviews • Ask about which kinds of users are doing what and when Set scope; Explain that you want to see broadest representation of users and work • Identify work activities Focus on most important and most representative tasks

21. Before the visit: Preparation (continued) • Establish or negotiate various parameters, such as how long you will/can be there It can be up to several intense weeks for data gathering • How often to visit It can be up to every other day • How long for average interview A couple of hours maximum • Maximum number of interviews per visit Example, four to six

22. Before the visit: Preparation • Learn about the domain Lining up the right customer & user people:(continued) Selectand contact appropriate support people • Determined by management people • Arrange logistics for visits

23. Before the visit: Preparation • Learn about the domain Lining up the right customer & user people:(continued) Select appropriate users and others to meet, observe, and interview • Especially frequent users, managers, customer representatives • Cover as many usage roles as possible • Plan visits to multiple sites if they exist

24. Before the visit: Preparation • Get access to “Key” people Who are they? • user • manager

25. Before the visit: Preparation • Get access to “Key” people What if you can’t find real users? • Talk to user proxies • Such as business experts or consultants • disadvantages

26. Before the visit: Preparation • Get access to “Key” people Setting up the right conditions? • The environment: the active work place • The people: not the supervisor but workers

27. Before the visit: Preparation • Get access to “Key” people How many interviewees at a time? • Multiple users • A single user • Preparing your initial questions (last but not least) • Ask users to tell you and show you how they do their work

28. During visit: Collecting User Work Activity Data • Goal: Use Context, Not User Desires! • Do not ask users what they want or need • Akin to relational database design: • How do you your task? • What data should I store? • Observe and interview users • In own work context • About how they do their work (normal, good, bad, etc.) vs. • “If I had asked people what they wanted, they would have said, faster horses” • — Henry Ford Alex

29. DURING VISIT: COLLECTING USER WORK ACTIVITY DATA • Form partnerships with users • Users must trust you and be engaged • Allow the users to lead the inquiry by asking open ended questions • Who is the expert? • Behind the keyboard: hopefully you… • In the use/work domain: the user • Pay close attention to the feedback from the expert!

30. DURING VISIT: COLLECTING USER WORK ACTIVITY DATA • Get task data • One of most important kinds of contextual data • From observing users doing their own workin their own work context • I.e. Don’t ask a manager to explain a different user’s job • Notice triggers for tasks and steps • What happens to cause them to initiate each task or step? • Example, incoming phone call leads to filling out order form • Learn about your users’ task barriers • Notice hesitations, problems, errors

31. DURING VISIT: COLLECTING USER WORK ACTIVITY DATA • Recording video • Effective way to capture comprehensive data • Use only where conditions and resources permit • Can help you capture nonverbal communication cues • Downsides • Users can be “camera shy” → Not forthcoming • Who wants to make a mistake on camera? • Users may not want to make negative comments on camera (about their current work practice)

32. DURING VISIT: COLLECTING USER WORK ACTIVITY DATA • Note taking • Pen and paper • Laptop • Only if you can type quietly! We don’t want our observations to disturb the user’s normal work practice • Small digital recorder • For notes, not for recording interview • Allows the user to correct any misconceptions you may speak aloud while recording notes • Use a consistent notation!

33. DURING VISIT: COLLECTING USER WORK ACTIVITY DATA • Use numbering system to identify source of each data point • To document data for validity • So can go back to answer questions • Mark time points in videos and audio • Transcribe recordings with line #s Result: A consistent timeline/framework of all notes and observations from the contextual inquiry

34. DURING VISIT: COLLECTING USER WORK ACTIVITY DATA • Be a listener • Usually do not offer your opinions about what users might need • Do not lead user or introduce your own perspectives I want privacy when I am buying tickets… You mean, when you are looking for events and buying tickets, you don’t want other people in line to know what you are doing? Can you elaborate what you mean by wanting privacy?

35. DURING VISIT: COLLECTING USER WORK ACTIVITY DATA • Do not expect every user to have same view of work domain and work • Expect multiple perspectives → during analysis your job will be to determine the "truth" from the middle ground of these perspectives

36. DURING VISIT: COLLECTING USER WORK ACTIVITY DATA • Capture details as they occur • Do not wait and try to remember it later • Be an effective data ferret or detective • Discover, extract, “tease out” • Follow leads, collect “clues” • I.e. If a new term or concept comes up, jump on it and tease the idea apart before returning to your previous line of questioning • Be ready to adapt, modify, explore, branch out

37. DURING VISIT: COLLECTING USER WORK ACTIVITY DATA • Pay attention to information needs of users • “It is all there” Syndrome → Cop-out, Laziness • Lack of proper contextual inquiry leads to “information flooding screens”

38. DURING VISIT: COLLECTING USER WORK ACTIVITY DATA • What about design ideas that crop up with users? • Take note of the idea, but direct the user back towards the work practice • Remember: Users tend to not know what they need and tend to have very narrow views! • What about analyst and designer ideas that crop up? • Again, tag them like any other note and move on

39. DURING VISIT: COLLECTING USER WORK ACTIVITY DATA • Questions not to ask: • Do not ask about the future; do not ask users what they would do in a given circumstance. • Answers won’t reflect reality! • Do not ask for design advice • Users aren’t designers! • Do not ask leading questions that just put ideas into their heads • This will bias the user towards your understanding

40. DURING VISIT: COLLECTING USER WORK ACTIVITY DATA • Collect work artifacts • Tangible talking points for analysis and design • Example: Work artifacts from local restaurant

41. DURING VISIT: COLLECTING USER WORK ACTIVITY DATA • Other forms of data collection • Digital photos • Document the environment with lots of pictures • Capture the big picture • On-the-fly diagrams of workflow, roles, and relationships • On-the-fly sketches of physical layout, floor plans • Quantitative data • How many people do this job? • How many widgets are assembled per hour? • Etc.

42. Between visits: Anticipate Modeling Needs • Create contextual data “bins” • Key problems, ideas • Temporary repositories to hold categories of raw contextual data • Example, labeled piles of notes on table • To start organizing data right from start 42

43. Wrap it up • Do not overstay your welcome • Be efficient, get what you need, and get out of their way • Limit interviews to no more than two hours • Most people cannot focus and remain concentrated on explaining their work process for more than two hours • They probably have work to do! • Hartson and Pyla suggest giving gifts… • I think a simple thank you is appropriate

44. What about commercial products? • Work role → simply the user (think Android app) • Challenge: Collecting work activity data (e.g. use of the Android app) as is occurs over time without influencing the user’s behavior • Long term patterns have to be observed • People learn new forms of usage over time • E.g. users alter the way they use their Android phone over time in order to become more efficient in using the phone

45. Typical Issues • Users don’t understand what contextual inquiry is • Users want to meet in a conference room • Users want to do group sessions • Users don’t show complete work tasks • Users talk over your head (subject experts) • Contextual inquiries turn into complaint sessions www.UXmatters.com

46. Other Resources • www.usabilitybok.org/contextual-inquiry • www.usabilitynet.org/tools/contextualinquiry.htm