1 / 30

Task Analysis and Contextual Inquiry

This task analysis and contextual inquiry class explores the process of understanding user needs and creating design ideas for Japanese inventions. Topics include task inventory, user personas, scenarios of use, and prototyping.

clarimonde
Download Presentation

Task Analysis and Contextual Inquiry

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Task Analysis andContextual Inquiry IS 485, Professor Matt Thatcher

  2. Japanese Inventions

  3. Japanese Inventions

  4. Agenda • Review • Task analysis and contextual inquiry • Next class • creating a task inventory list • selecting tasks for prototyping • creating scenarios of actual use • sketching design ideas • The rest of the course is about • prototyping and evaluating design ideas iteratively

  5. Review • Team project • team feedback • milestones

  6. Task Analysis • Find out • who the intended users are • what tasks they need to perform • in what context they perform them • Observe existing work practices of ordinary users • Develop user personas and scenarios of actual use • Try-out new ideas before building software

  7. Task Analysis Questions • Who is going to use system? • What tasks do they perform? • What new tasks are desired? • How critical are the tasks? • How often do the users perform the tasks? • What are the time constraints on the tasks? • How are the tasks learned? • Where are the tasks performed? • How do users communicate with each other? • What happens when things go wrong?

  8. Who are the Users? • Identity • in-house users are easy • need several typical users for broad product (or target audiences) • Background characteristics • age, gender, education level, education training • Skills • experience with computers (in general), specific products or applications, similar products • experience with specific software applications • experience with tasks that the new system will support

  9. Who are the Users? (continued) • Learning Styles • read documentation / manuals • ask others/watch others do tasks (e.g., tech support) • trial and error (exploring on their own) • what other learning styles are there? • Physical characteristics (or limitations) • color deficiency? • hearing/visual impairment? visual fatigue? eyeglasses? • height? mobility impairments? others?

  10. Color Deficiency Example

  11. Who are the Users?(continued) • Cultural characteristics • nationality (e.g., icons, language, metaphors, colors, stds) • geographic location (e.g., southwest US, northeast US) • industry culture (terminology, acronyms, work ethic) • hospitals vs. financial services vs. manufacturing plant • e.g., what does ATM stand for? • company culture • generations (e.g., touch-based screen of the the 1960s) • Motivational characteristics • willingness to change • openness to learn new tools and ways of doing tasks • what motivates them to perform the tasks

  12. Interface Hall of Shame(Globalization Issue from Norway) Time Magazine Website (change of address form) Byte Magazine Website

  13. Who are the Users?(continued)

  14. Milestone 1 Expectations • Develop a user profile characterizing your target users • background (e.g., age, education) • skills (e.g., job, task, computer, specific applications, internet) • physical characteristics • cultural characteristics • goals and motivations • User Personas • story-like description of your target user • name, background details, experiences, etc.

  15. What Tasks? • Important for automation and new functions • Measure the following: • relative importance (or criticality) of tasks • relative difficulty (or complexity) of tasks • how often users perform each task (frequency) • optimize system for the most important/frequent tasks and it will improve the perception of good performance • Observe users • interviews are not enough • users forget tasks and important details or have problems communicating what they do all day • on-line billing example at the dentist’s office

  16. What are the Time Constraints on Each Task? • How fast must users complete each task • determine the amount of time users will feel is acceptable for completing each task with the new system • what functions will users be in a hurry for? • which can wait? • Is there a timing relationship between tasks? • task 2 and 5 must occur before completing task 8

  17. How are Tasks Learned? • What does the user need to know? • Does the user need training? • academic • general knowledge / skills • special instruction / training • Or is the system a “walk up and learn” system (e.g., kiosks)

  18. Where is the Task Performed? • Office, laboratory, point of sale? • Effects of environment on users? • How much space do users have? • Lighting? • Noise? • Temperature? • Do they have wet, dirty, or slippery hands? • Customers under stress? • Confidentiality required?

  19. How Do Users Communicate With Each Other? • Who communicates with whom? • About what? • Follow lines of the organization? Will a re-design go against it? • Example: assistant to manager • installation of computers changes communication between them • people often prefer to change their computer usage than their relationship

  20. What Happens When Things Go Wrong? • Is information lost? • Are customers dissatisfied or lost? • Does the company lose money or time? • Can users recover easily? (e.g., alternatives) • Does someone die? • E-mail?, Microsoft Word?, Y2K?, electricity outages, Therac-25?

  21. Involve Users to AnswerTask Analysis Questions • Users help designers learn • what is involved in their jobs • what tools they use • i.e., what they do • Developers reveal technical capabilities • builds rapport & an idea of what is possible (sketches) • user’s can comment on whether ideas make sense • How do we do this? • observe & interview prospective users in the work place!

  22. Contextual Inquiry • Way of understanding users’ needs & work practices • Master – apprentice model allows user to teach us what they do! • master does the work & talks about it while working • we interrupt to ask questions as they go • The Where, How, and What expose the Why “Think aloud” and “probing questions”

  23. Principles • Context • go to the workplace & see the work as it unfolds • people summarize in interviews, but we want details • Partnership • master-apprentice relationship, yes; other models, no • avoid interviewer/interviewee (stops work) • set expectations at the start • partnership allows more apprentice interaction • alternate between watching & probing (withdraw and return)

  24. Principles(continued) • Interpretation • good facts are only the starting point • designs based on interpretations • validate & rephrase • run interpretations by the users to see if you are right • share ideas to check your reasoning • people will be uncomfortable until the phrasing is right • need to be committed to hearing what the customer is really saying (“Huh?”, “Umm…”, “Yes, but…”) • show them your initial user profiles and task lists • have them make comments, corrections, etc. • even this stage of design is iterative

  25. Thoughts on Interviews • Use recording technologies • notebooks, tape recorders, still & video cameras • Structure • conventional interview (15 minutes) • introduce focus & deal with ethical issues (sign consent forms) • get used to each other by getting summary data • maybe come up with an initial task list before visit and discuss up front • transition (30 seconds) • state new rules – they work while you watch & interrupt • contextual interview (1-2 hours) • take notes, draw, be nosy! (“who was on the phone?”) • wrap-up (15 minutes) • summarize your notes & confirm what is important • Master/apprentice can be hard • do your best

  26. Contextual Inquiry Materials • Recruiting script • Interview guidelines • Site visit script • User profile questionnaire • Data logging sheet

  27. Analyzing the Data • Affinity Diagramming • Ad hoc procedures

  28. What Users Might Say • “This system is too difficult” • “You don’t have the steps in the order we do them” • Do not take comments personally • you shouldn’t have a personal stake • Goal is to make the system easy to use for your intended users

  29. Summary • User-centered design is different than traditional methodologies • leads to solving problems up front (cheaper) • Know thy user & involve them in design • answer task analysis questions before designing • who, what, where, when, how often? • use contextual inquiry (or other ethnographic methods)

  30. Next Time • Creating a task inventory list • Selecting tasks for prototyping • Creating scenarios of actual use • Sketching design ideas

More Related