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

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)

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.

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...

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

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......

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

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

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.

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

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

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

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?

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?

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.

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.

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.

How should you structure the interview Two methods:

Ethnographic/Contextual Inquiry Semi-structured/structured

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)

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)

Email example How might we structure an

ethnographic interview?

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 ....

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?

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.

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

Results How did it go? What did you learn? Questions?

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