Know the User

John KelleherIT Sligo

2

Designing for the user

3

Basic Activities of Interaction Design Identifying needs and establishing

requirements [Part 2] Developing alternative designs

[Part 3] Building interactive versions of the

designs [Part 3] Evaluating designs [Part 4]

4

Overview of Needs Identification The importance of requirements Different types of requirements Data gathering Task descriptions: Scenarios

Use Cases Task analysis: HTA

5

Task analysis techniques focus on: understanding users' tasks breaking them down into tasks and actions

It clarifies and organizes user’s knowledge about a system.

Work-flow patterns are identified Frequency of different tasks performed What tasks are done with what tasks Order of work tasks Communication pathways Exceptions – when is task A not done?

Information Gathered from Task Analysis

6

Why do Requirements? Uncovered information may lead to:

abandoning a bad ideavideo-phones, recipe management programs

very good ideasWindow usage matches a working set model –

E.g. Rooms basis for driving design

protects from building a useless program Often assumptions designers have about

users and interface are wrong E.g. Ackroyd study of English Detectives

7

Information Gathered

Users’ conceptual model What is the external representation that is used to do the

task - worksheets, patient charts What organization or model do users keep in their head as

they are doing the task? Interrelationships among objects & tasks

Task specificity of various task objects - eraser for removing marks on a page

Organization of objects into larger task objects, page->section->chapter->book->library

8

SharpReaderConceptual model derived from user’s knowledge of Outlook

9

Information Gathered

Use of other systems and/or applications Use of accelerator keys Use of command-based rather than GUI

applications Use of telephones, voice mail systems and fax

machines

User Characteristics Task experience and knowledge of the domain. System experience Application experience, e.g., other WPs Computer literacy

10

50:34 Controller: Scandinavian 515 route direct to Detling.50:42 SK515: Roger, direct Detling, SK515.51:14 [Controller takes phone call] ... If you like.. OK.51:49 Controller: SK515, descend now to flight level 100, one-five

miles before Detling.52:00 SK515: Roger, level 100 to be level fifteen miles before Detling,

SK515.52:04 Controller: ’kyou.

[Controller sorts flight strips]53:22 [Controller to assistant] Ferry 201 ... is Ferry 201 past?53:27 Controller: Air Ferry 201 continue with Amsterdam 125 decimal

7, good-day.53:34 BAF201: 125 er 7, good-day.

[Discussion with other controllers]55:21 Controller: SK515, what’s your present heading?55:25 SK515: Roger, ’ding 240, SK515.55:28 Controller: Roger, turn left, heading 220, keep you clear of the

danger area.55:25 SK515: Roger, heading 220, Scandinavian 515.

[Controller sorts flight strips]55:47 Controller: Speedbird 723, you can turn, er, for Lambourn,

descend when ready to flight level 150.55:56 BA723: Roger, recleared, when ready level 150 and turning

direct for Lambourn, Speedbird, er, 723.

Transcription of 6 minutes of an ATC exchanges with flights traversing a sector in the London area

11

Establishing requirements

What do users want? What do users ‘need’? Requirements need clarification,

refinement, completion, re-scoping Input : requirements document

(maybe) Output : stable requirements

12

Different kinds of requirements

Functional: What the system should do Historically the main focus of requirements

activities

(Non-functional: memory size, response time... )

Data: What kinds of data need to be stored? How will they be stored (e.g. database)?

13

Different kinds of requirements

Environment or context of use: physical: dusty? noisy? vibration? light?

heat? humidity? …. (e.g. OMS insects, ATM)

social: sharing of files, of displays, in paper, across great distances, work individually, privacy for clients

organisational: hierarchy, IT department’s attitude and remit, user support, communications structure and infrastructure, availability of training

Users – who are they?

14

Different kinds of requirements

Usability: learnability, effectiveness, flexibility,

utility, memorability, efficiency, safety.

Note that user requirements and usability requirements refer to different things

15

Kinds of requirements

What factors (environmental, user, usability) would affect the following systems? A system for use in a university’s self-

service cafeteria that allows users to pay for their food using a credit system.

A system to control the functioning of a nuclear power plant

A system to support distributed design teams, e.g. for car design

16

Define goals for your application

Can be learned in less than 2 minutes User will perform 2 error-free purchases per session The error rate will be lower than 2 per 10 operations Tasks will be performed in 30% of the time it takes using

the competitor’s system

Users will have a high satisfaction with the system as measured by a survey.

Explicit, specific, measurable metrics. Tradeoffs, so have to pick relevant metrics e.g.

learnability versus efficiency

17

Categories of Users

Mandatory Discretionary Intermittent Level of Expertise

Novice Intermediate Expert

18

Level of Expertise Novice

frequent feedback; actions prompted by choices safe exploration supported - robust easy undo selective disclosure

Intermediate knowledge of broad aspects need easy access to the details can be amalgam of novice and expert

Also true of novice and expert.

19

Levels of Expertise (contd.)

Experts critical help system user lower, more subtle support and feedback accelerators required customisability desired to facilitate cross-

application usage only assumption – experts less risk-averse in

usage pattern

20

User categories (anecdotal)

Novice usersomeone who is afraid if they touch the keyboard they will break the system.

Intermediate usersomeone who has broken the computer and doesn’t know how to fix it.

Expert usersomeone who breaks other people’s computers.

21

Data gathering techniques (1) Questionnaires

Keep the number of questions low Only questions with answers that you can’t get other ways Only questions that will have a direct impact on functional

requirements Avoid asking for everything

Ask clear questions Ask questions that users can answer validly and reliably

Does the user store information in this way? Does the user remember such information? Will the user be inclined to answer your question truthfully?

Good for answering specific questions from a large, dispersed group of people

22

Data gathering techniques (2)

Interviews: Forum for talking to people Structured, unstructured or semi-

structured Props, e.g. sample scenarios of use,

prototypes, can be used in interviews

Good for exploring issues But are time consuming and may be

infeasible to visit everyone

23

Data gathering techniques (3)

Workshops or focus groups: Group interviews Good at gaining a consensus view and/or

highlighting areas of conflict

24

Data gathering techniques (4)

Naturalistic observation: Spend time with stakeholders in their

day-to-day tasks, observing work as it

happens 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 Ethnography is one form

25

Data gathering techniques (5)

Studying documentation: Procedures and rules are often written

down in manuals Good source of data about the steps

involved in an activity, and any

regulations governing a task Not to be used in isolation Good for understanding legislation, and

getting background information No stakeholder time, which is a limiting

factor on the other techniques

26

27

Data gathering techniques (6)

Contextual Enquiry Way of understanding users’ needs and work

practices Master – apprentice model allows customer to

teach us what they do!master does the work & talks about it while

workingwe interrupt to ask questions as they go

The Where, How, and What expose the Why Presence Project1

1 Gaver et al (1999) Cultural probes. ACM Interactions Magazine, January and February, 21-29Cultural Probes

28

Task descriptions

Scenarios an informal narrative story, simple, ‘natural’,

personal, not generalisable illustrate using storyboards

sequences of sketches showing screens & transitions

good to demonstrate to management, marketing and customers

can replace much textual specification similar to Use Cases in Software Engineering See Brad Meyers at 0:46.05

29

Scenario for shared calendar

Victoria is a bright young college student looking for a gift for her younger sister, who is turning 16 in two weeks. Like most college students, Victoria is on a tight budget, but wants to get something memorable and useful for her sister on this important birthday for a young girl.

She’s heard some of her friends talk about ebirthdayz.com, and so she decides to check it out. On the ebirthdayz.com homepage, she sees that the Web site has a gift recommendation feature. Victoria finds the recommendations screen and sees gifts based on her sister’s age and general interests, as well as her own limited finances.

The site shows some suggestions, and Victoria chooses a popular favourite and buys it, including gift-wrapping. Total time spent: 20 minutes.”

30

Scenarios (cont.) Scenarios are design specific, tasks

aren’t Scenarios force us to

show how various features will work together

settle design arguments by seeing examples

only examples sometimes need to look beyond

Show users storyboards sequences of sketches showing

screens actions users can take get feedback

31

Storyboards

32

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)

GOMS is also used

33

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

34

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 catalogue2.2 access the search screen2.3 enter search criteria2.4 identify required book 2.5 note location

3. go to correct shelf and retrieve book4. take book to checkout counter

35

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.

36

Example Hierarchical Task Analysis (graphical)

Borrow a book from the library

go to the library

find required book

retrieve book from shelf

take book to counter

321 4

0

access catalogue

access search screen

enter search criteria

identify required book

note location

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 from information available, do 2.2-2.3-2.4-2.5

2.1 2.2 2.3 2.4 2.5

37

Group info & find relations between groups Post-Its on

large surfaces haptic UI immersive persistent brainstorming

Also used forcreating web info architecture Reprinted by permission from Contextual Design by Hugh Beyer &

Karen Holtzblatt, InContext Enterprises, http://www.incent.com, © Morgan Kaufmann, 1998

Affinity diagramming

38

Summary

Getting requirements right is crucial There are different kinds of requirement, each is

significant for interaction design The most commonly-used techniques for data

gathering are: questionnaires, interviews, focus groups and workshops, naturalistic observation, studying documentation

Scenarios, and use cases can be used to articulate existing and envisioned work practices.

Task analysis techniques such as HTA help to investigate existing systems and practices

39

Exercise

Appreciate tacit knowledge of users Mechanical syringe design

Doses may be in range 0 – 9999 Draft a prototype

40

Automatic syringe

1 3 6 7 27 8 9

654

321

0

1 4 7 2+ + +

---+

-

Before consulting users After consulting users

41

Further Reading

Interaction Design,Preece et al,Chapter 7

42

Readings Lewis C. & Rieman J., “Getting to know users

and their tasks”, Shareware book. Gould J. (1988), “How to design usable

systems”. In Baecker et al. Web Sites

Beyer, Hugh, "Getting Started with Contextual Techniques" http://www.incent.com/connection.indx/techniques.html

Norman D. & Draper S. (eds.) (1988), “User Centred System Design”.