Administrivia

1. Administrivia • Turn in ranking sheets, we’ll have group assignments to you as soon as possible • Homeworks • Programming Assignment 1 due next Tuesday • Group Assignment:1 Interviews, due next Thursday. • Shengli office hours: • Tuesday 10:30 – 11:50 Sieg 226a • Thursday 11:00 – 11:50 Sieg 329 • Thursday 1:30 – 3, Sieg 232

2. Administrivia continued... • Website will change... • A.J. will be at the CHI conference next week, some availability for questions via email • Reading related to today lecture is Chapters 1-4 in About Face (pg. 5-54)

3. What is design? • Cooper and Reimann define it as (pg 5): • Understanding the user’s wants, needs, motivations, and contexts • Understanding business, technical, and domain requirements and constraints • Translating this knowledge into plans for artifacts (or artifacts themselves) whose form, content and behavior is useful, usable, and desirable, as well as economically viable and technically feasible.

4. Why you should care.... • Focusing on the goals of your user helps you to build more successful applications • Successful applications get used.... • If you are building software, especially at a smaller company, these skills will be very helpful...

5. Why is it challenging? • Industry is ignorant of user goals and it takes work to determine them. • Conflict of interest • Programmers naturally focus on ease of coding vs. ease of use • History of computer use • Takes empathy • Process for translating user goals to software is under development

6. What’s the state of the world? • Software often follows the implementation model instead of the mental model • Software is often rude • Software assumes a lot of knowledge about the internals of the computer (save) • Examples: printing in Word, web forms, copying between drives, boolean logic in search interfaces (and vs. or) • Your examples......

7. Evolving the software development process • Several different “processes” out there including Goal Directed Design, Contextual Design, ... The meta-level process • Research about users • Building models of users • Designing artifact

8. Value of User Research • Qualitative research helps us understand • Understand existing products and how they are used • Potential users for new or existing products and how they currently do things that the new product design is hoping to address • Technical, business, and environmental contexts • Vocabulary and other social aspects of the domain in question

9. Recognizing User Goals • Goals • Motivate us to do tasks and use technology. Goals stay the same regardless of technology. • Think about goals for your project. This will help you determine the tasks that meet those goals.

10. Understanding Users • Variety of approaches to do qualitative research to learn about users • Stakeholder interviews • People commissioning design work • Subject matter experts • Expert users, important for complex of specialized domain • User and customer interviews • User observation/ethnographic field studies • Literature review • Product/prototype and competitive audits

11. User Interviews • To make user interviews valuable you/your group needs to think about several questions: • Who should you interview? • What do you want to learn from the interview? • How should you structure the interview? • Group Assignment 1 asks these very questions • Chapter 4 in About Face focuses on these questions

12. Email example • Suppose you believe that people use email in ways that the current interfaces don’t support well ... • Possible Goals people have when using email: • Track things I need to do • Track conversations/discussions

13. Who should you interview • Ideally a diverse group of users so you can understand a range of behaviors • Persona hypothesis (pg 46) • First guess at different kinds of users, helps you decide who to interview (Enterprise portal example) • What different sort of people might use this product? • How might their needs and behaviors vary? • What ranges of behavior and types of environments need to be explored?

14. Who should you interview • Contextual Inquiry uses concept of roles. These often map to job descriptions in the workplace (secretary, managers...) • In both cases, you are trying to identify variables that might help break users into groups with different needs. • What kind of roles might we use for the email example?

15. Who should you interview • In “real” cases you’d want several interviews for each role you identified. • In our class we will choose one primary role and interview 2 – 3 people that fit that role.

16. What do you want to learn from the interview? • Think about your project. What do you need to know to design the application? • This will be a list of questions you have, things you will be looking for in the interview to verify or discredit hypotheses you have about the user’s work practice.

17. What do you want to learn from the interview? • For the email example ..... • Do people actually use their mail to track tasks? • Do people have trouble doing this (too much mail...) • IMPORTANT NOTE: You will not be asking your users these questions. These are high-level questions about which you want to gather information to help in building personas, defining scenarios, and designing the artifact.

18. How should you structure the interview • Two methods: • Ethnographic/Contextual Inquiry • Semi-structured/structured

19. Ethnographic/Contextual Inquiry • Go where the user works • Observe the user as he/she works • Talk to the user about the work • Focus on goals first (Cooper)

20. How to talk with users? • Master/apprentice model (Avoid interview/interviewee, expert/novice, guest/host) • This is harder than you think.... • Avoid summary, watch them work, encourage story telling about specific experiences. • Get concrete data • Be prepared to ask additional goal related questions (pg. 50 has a list of some to consider)

21. Email example • How might we structure an ethnographic interview?

22. Semi Structured/Structured • Ideally you will observe users working on tasks, but it can all be helpful to have some set questions to learn demographic or general usage data. • Email example ....

23. Things not to do • Don’t make the user a designer • Get information about the problems he/she is having, not their ideas on solutions • Avoid discussions of technology • Don’t make the user a programmer • Note, domain specific knowledge (elevators) is an exception to this rule • Avoid leading questions • Would feature X help you out? • Do you think you’d use X, if it were available?

24. During and after the interview • During • Take lots and lots of notes. • Be respectful of their expertise and appreciative of their time. • Aim for about an hour or so for an interview • After • Get together as a group to compare notes and discuss anything particularly interesting.

25. Now you try.... • Email example • Register for classes

26. Results • How did it go? • What did you learn? • Questions?

27. Group Assignment 1: Interview Script • Due April 10th • You will be individually responsible for emailing your answers and the answers to the reflective questions. • Group answers