UserCentered System Design UserCentered System Design a philosophy

User-Centered System Design

User-Centered System Design - a philosophy of user interface design introduced by Don Norman & Steve Draper in 1986

User-Centered System Design Technology should be designed around the needs of the user. To do this, you need to understand users and what they are trying to do. Avoid: Solutions in search of a problem!

User-Centered System Design Requirements analysis Task analysis Standards, principles, guidelines Design experience Design tools Design Formal models Implementation Evaluation* *(incl. usability testing)

User-Centered System Design To what extent can you trust your own intuitions about doing a task? (Norman) The interface should be the responsibility of someone who can take the perspective of the user and be a strong advocate. This is not easy!

User-Centered System Design Some principles focus on users and their needs instead of technical considerations do a task analysis start usability testing & evaluation early in the design process design the system iteratively and allow it to evolve

Iterative Design DESIGN TEST

User-Centered System Design Task analysis tells us how people currently accomplish a task. (assign. #7) Requirements analysis tells us what a system should do. Usability testing tells us whether a system performs acceptably when a user tries to carry out certain tasks. (assign. #8) User-Centered System Design brings these things together.

Task analysis

Task analysis - What is it? observes users in realistic settings doing particular tasks a bit like doing anthropology or ethnography may include taking notes on what users actually do, having them “think out loud” while working, interviewing them, or having them fill out questionnaires

Task analysis can be done at different levels of detail fine level (primitives, e. g. therbligs, keystrokes, GOMS - the “micro” level) intermediate level (flow charts, plans, or steps for sequences of actions) high level (cognitive goals; social impact - the “macro” level)

The goals of task analysis enables you to understand what the user has to do and cope with enables you to trace steps leading up to an error and figure out why it occurred enables you to see what parts of the task the user spends the most time doing - what is easy and what is hard enables you to compare different users and different methods for doing tasks

Methods for task analysis Questionnaires Interviews Ethnographic observation Verbal protocols Formal models and simulations

Questionnaires & interviews are often done badly. It’s important to ask open-ended questions first and to avoid biasing the respondent (avoid leading questions). Respondents often misinterpret questions. Problem: trusting what people say

Ethnographic observation a method from anthropology Example: Lucy Suchman’s studies of people using copy machines (at Xerox) Finding: Human action isn’t all planned ahead people respond to the situation they are in (“situated action”)

Ethnographic observations are very different from observations in the laboratory! (We’ll compare these further in our next lecture)

A note on scientific methods: There are two important steps in doing science: 1. Observing and describing 2. Testing theories and hypotheses HCI specialists get many useful principles and solutions from what they see users do, not only from abstract theory and testing hypotheses.

Methods for task analysis Questionnaires Interviews Ethnographic observation Verbal protocols Formal models and notations (GOMS) (Hierarchical task analysis) (cont. )

Verbal protocols pioneered by psychologists studying problem-solving have people “think out loud” as they do some activity, step by step Advantage: can get at some of the invisible steps that people go through on the way to a solution, steps that aren’t evident in their behavior.

Methods for task analysis Questionnaires Interviews Ethnographic observation Verbal protocols Formal models and notations (GOMS) (Hierarchical task analysis) (cont. )

Challenges in task analysis: You must involve other people! Try to avoid bias. Summarize in some useful form. Try to characterize the full range of relevant tasks and users.

When to do task analysis? Task analysis must be done at the very beginning of the design process. Examples: Back Seat Driver NL interface (HP) Communication device for a severely handicapped user

Requirements analysis

Requirements analysis Once you understand what users need to do (task analysis), establish the technical requirements. Requirements specify what the technology does and how it should perform Not easy! Users seldom actually know what their requirements are (can’t just ask them!) Failure to do this often means the technology fails to be useful!

Different kinds of requirements (PRS pp. 206 -209) Functional - what the technology does Data - what info it needs Environmental/context of use (physical, social, organizational, technical) User profile for typical user(s) Usability - summary of goals, measures

Requirements analysis methods Questionnaires Interviews Focus groups and workshops Naturalistic observation Studying documentation

task & requirements analyses? Scenarios - imaginary but representative, at a useful level of detail

IDEO web site: An interesting company that specializes in task analysis, design, and usability