Email to ogden@nmsu Names of your group members Possible topics

1. Email to ogden@nmsu.edu • Names of your group members • Possible topics

2. Vending machines Describe the conceptual model underlying the two vending machines Which is easiest to use?

4. The Task-Centered Design Process • figure out who's going to use the system to do what • choose representative tasks for task-centered design • plagiarize • rough out a design • think about it • create a mock-up or prototype • test it with users • iterate • build it • track it • change it

5. Getting to Know Users and Their Tasks • Customers are often illusory • Don't get soft on this step or illusions will stay. • Building to specs doesn't alleviate the need • Getting in Touch With Users • Find real people who would be potential users of what you are going to build. • watch out for generic and designer users

6. Homework • Pick a common task • Start a car. Microwave some popcorn. Check out a book in the library. Etc. • List all the steps necessary to complete the task • Watch someone do the task • Did their behavior match your task description?

7. Requirements:What, how and why? • What • Two aims: • 1. Understand as much as possible about users, task, context • 2. Produce a stable set of requirements via a set of task descriptions that focus on users. • How • Personas • Task analysis

8. What, how and why? • Why: • Requirements definition: the stage where failure occurs most commonly Getting requirements right is crucial

9. What, how and why? • Why: • Requirements definition: the stage where failure occurs most commonly Getting requirements right is crucial

10. An extreme environment example

11. Different kinds of requirements • Users: Who are they? • Characteristics: ability, background, attitude to computers • System use: novice, expert, casual, frequent • Novice: step-by-step (prompted), constrained, clear information • Expert: flexibility, access/power • Frequent: short cuts • Casual/infrequent: clear instructions, e.g. menu paths

12. You have to get in the users’ head • Field research • Watching people doing real things in the real world: (e.g. online shopping – real world shopping) • Watching people use other related software: (e.g. other online shopping sites)

13. Persona • A persona is a fictional person who represents a major user group for your product. • Personas help you identify major user groups. You select the characteristics that are most representative of those groups and turn them into a persona.

14. Personas • Capture user characteristics • Not real people, but synthesised from real user characteristics • Should not be idealised • Bring them to life with a name, characteristics, goals, personal background • Develop multiple personas

15. Data gathering for requirements • Direct observation: • Gain insights into stakeholders’ tasks • Good for understanding the nature and context of the tasks • But, it requires time and commitment from a member of the design team, and it can result in a huge amount of data • Indirect observation: • Not often used in requirements activity • Good for logging current tasks

16. Contextual Inquiry • An approach to ethnographic study where user is expert, designer is apprentice • A form of interview, but • at users’ workplace (workstation) • 2 to 3 hours long • Four main principles: • Context: see workplace & what happens • Partnership: user and developer collaborate • Interpretation: observations interpreted by user and developer together • Focus: project focus to understand what to look for

17. Problems with data gathering (1) • Identifying and involving stakeholders:users, managers, developers, customer reps?, union reps?, shareholders? • Involving stakeholders: workshops, interviews, workplace studies, co-opt stakeholders onto the development team • ‘Real’ users, not managers:traditionally a problem in software engineering, but better now • Availability of key people

18. Some basic guidelines • Focus on identifying the stakeholders’ needs • Involve all the stakeholder groups • Involve more than one representative from each stakeholder group • Use a combination of data gathering techniques

19. Some basic guidelines • Support the process with props such as prototypes and task descriptions • Run a pilot session • You will need to compromise on the data you collect and the analysis to be done, but before you can make sensible compromises, you need to know what you’d really like • Consider carefully how to record the data

20. Qualitative research • Better than quantitative for understanding human activities. • Helps us understand the domain context and constraints of a product (i.e.) • Existing products and how they are used • How current users currently approach problems new products address • Vocabulary and social aspects

21. Frank McDonoughSenior programmerUnited Parcel Service of America Inc. During the peak holiday season, UPS encourages its IT employees to pitch in and help on delivery trucks. McDonough spent two and a half weeks helping route drivers deliver packages.

22. The job: Inventory, scan and load packages; drive to houses; scan deliveries; get signatures; download DIAD (a portable delivery information acquisition device that all UPS route people carry). Also pick up and deliver lost puppies, help ladies rearrange living room furniture and provide other assistance as needed.

23. Lessons learned: McDonough saw "how crucial the DIAD is to the business, how important technology is for the drivers and how they appreciate it and rely on it. It also gave me a great hands-on view of the services UPS provides and simplified everything so I could understand all the package and service codes. "Right now, we're going through a rearchitecture in the billing apps area. Being on the route has enlightened me to what it all means, and so I'm better able to think about how to organize the information and how to report. Instead of building a monster, I can build a smaller app if I know what I'm doing."

24. Mark NardoneManager of IT1-800-Flowers Inc. Nardone's job is to keep IT aligned with business objectives by spending most of his time with businesspeople, often in the retail flower stores. He passes his insights on to the manager of development in IT. The job: Prepare, cut, arrange, sell and deliver flowers; work with marketing and other business units.

25. Lessons learned: "You get a lot of insights into human behavior selling flowers. On Valentine's Day, I was taking orders on the phone, and someone called in ordering for five different women, and the message for each was, 'You're the only one,' he says. "I spent 15 years in development. Seeing how it really works with people gives you a different perspective. Now I'm a florist first and an IT guy second. I'm excited about what it can do for our business. "For example, we were doing craft workshops at the stores, and we decided during a marketing meeting that we wanted to let our telephone customers know about that. So I said [to IT]: 'Guys, this is what we want to do.' Now, when an associate takes a customer's ZIP code on the phone, [the system gives him] a prompt on his screen to tell customers if there's a workshop happening in their area," Nardone says.

26. In the word of Yogi Beara You can observe a lot just by watching

27. inContex • Example design firm that uses customer field data in their design process • http://www.incent.com/cd/cdhow.html • Interested in: • Structure and language used in the work • Individual and group actions and intentions • The culture affecting the work • Explicit and implicit aspects of the work

28. Personas Modeling the user • Archetypal characters created to represent the needs and goals of the people for whom the product will be designed. • Defining functionality to satisfy the goals of a real person, rather than an abstract notion of "the user," enables you to avoid development roadblocks caused by personal preferences or biases.

29. Wrong way to use personas

30. Right way to use personas

31. Personas as a user model • Determines what a product should do and how it should behave. • Communicate with stakeholder, developers and other designers and focus on user experience with a common language. • Protects against: • The elastic user – everyone has a slightly different idea about who the user is • Self-referential designs – people designing for themselves • Designing for edge cases – keeps unusual cases in perspective

32. Describe how people behave – not job descriptions. Multiple persons w/same job or same person w/multiple jobs. Add life to the personas, but remember they're design tools first Use the right goals Life goals (e.g. retire at 50) Use rarely Experience goals (e.g. avoid feeling stupid) Use when specific to the interface product End goals ( e.g. find the best price) Should be the main focus Perfecting your personas Origin of Personas Personas

33. Personas • Are based on research • Are represented as individuals • Personifications simplify the user model • Represent classes of users in context • Archetypes not stereotypes • Based on observed behavior not on biased assumptions • Have motivations

34. Example of a Persona USDA Senior Manager GatekeepersMatthew Johnson Program Staff Director, USDA • Matthew is 51-year-old married father of three children and one grandchild. He has a Ph.D. in Agricultural Economics who spends his work time requesting and reviewing research reports, preparing memos and briefs for agency heads, and supervising staff efforts in food safety and inspection. He is focused, goal-oriented within a strong leadership role. One of his concerns is maintaining quality across all output of programs. He is comfortable using a computer and refers to himself as an intermediate Internet user. He is connected via a T1 connection at work and dial-up at home. He uses email extensively and uses the web about 1.5 hours during his work day. He is most likely heard saying: “Can you get me that staff analysis by Tuesday?”

35. Learning About the Users' Tasks • Develop lists of things the users would like to do • Say what the user is doing, not how they do it • Be specific with details. • Describe the complete job • key point because transition between tasks are covered • The tasks should say who the users are

36. Task analysis • Task descriptions are often used to envision new systems or devices • Task analysis is used mainly to investigate an existing situation • It is important not to focus on superficial activities What are people trying to achieve? Why are they trying to achieve it? How are they going about it? • Many techniques, the most popular is Hierarchical Task Analysis (HTA)

37. Task Inventory • What is a task? • It has an observable action with a beginning and end • What level of granularity? • Make dinner? or Peel Potatoes? • Make it a reasonable length • 7 ± 2 ? Probably 10-20

38. Partial task list for e-mail program • Write a message • Send a message • Receive a message • Read a message that you received • Reply to a message • Save a message to look at it later • Forward a message to someone else • Send a formatted file with the message • Send the same message to several people • Keep an address book

39. Detail task list for e-mail program • Write and send a message to ogden@nmsu.edu about missing class • Forward the message sent to ogden to someone else in the class. • Send the same message to everyone in the class.

40. Example • What overall tasks are users trying to accomplish at our Web site? • Trying to find a nursing home near you for an elderly relative. • Trying to get information about options for treatment for skin cancer. • Trying to sign up to receive an email notice when a payment is due. • How are users currently doing the task? • People are completing that task using something other than the web. • Users are on our Web site now. • Users are using another Web site trying to complete the same or similar tasks.

41. Hierarchical Task Analysis • Involves breaking a task down into subtasks, then sub-sub-tasks and so on. These are grouped as plans which specify how the tasks might be performed in practice • HTA focuses on physical and observable actions, and includes looking at actions not related to software or an interaction device • Start with a user goal which is examined and the main tasks for achieving it are identified • Tasks are sub-divided into sub-tasks

42. Example Hierarchical Task Analysis 0. In order to borrow a book from the library 1. go to the library 2. find the required book 2.1 access library catalogue 2.2 access the search screen 2.3 enter search criteria 2.4 identify required book 2.5 note location 3. go to correct shelf and retrieve book 4. take book to checkout counter

43. Example Hierarchical Task Analysis (plans) plan 0: do 1-3-4. If book isn’t on the shelf expected, do 2-3-4. plan 2: do 2.1-2.4-2.5. If book not identified do 2.2-2.3-2.4.

44. Example Hierarchical Task Analysis (graphical) Borrow a book from the library 0 plan 0: do 1-3-4. If book isn’t on the shelf expected, do 2-3-4. go to the library find required book retrieve book from shelf take book to counter 1 2 3 4 plan 2: do 2.1-2.4-2.5. If book not identified from information available, do 2.2-2.3-2.4-2.5 access search screen enter search criteria identify required book access catalog note location 2.1 2.2 2.3 2.4 2.5

45. Example task analysis • Buy An Anvil • Find The Anvil • Search For Anvil • Type in "anvil" in Search box • Read results • Browse the Store • View anvil • Purchase The Anvil

46. Using the Tasks in Design • Send task descriptions to the users • develop a DESIGN SCENARIO for each task • these are design specific • discuss these with the users and designers • gives CONTEX to the discussions. • Represented with STORYBOARDS (sequences of sketches showing what the screen shows and actions taken)

47. Scenarios should • Say who the users are – personas • What their goals are • When they are using your interface • What other people, objects they interact within the same time frame.

48. Homework • Pick a common task • Start a car. Microwave some popcorn.. Etc. • List all the steps necessary to complete the task • Watch someone do the task • Did what they do match your task description?