Seng310 Lecture 3. Requirements: User

analysis

Warm-up exercise: Technology glitch causes market collapse? (May 7 2010)

The Story: New York Stock Exchange efforts to stabilize Thursday's stock market had the opposite effect, triggering a momentary market collapse.

•  It wasn't a goof. It wasn't human error. Rather, it was an instant that displayed the hazard of new markets that handle billions of dollars' worth of trades each day.

•  During yesterday's fast-moving midday market, NYSE specialists -- who oversee trading in individual stocks --used their authority to call a momentary time out. Years ago, when the NYSE dominated trading, such "time-outs" worked well at stabilizing stock prices.

•  But today, the NYSE accounts for only about 25% of the volume in its listed stocks. The rest comes from computerized markets run by private companies -- and some of those systems did not take a time out yesterday. So, as the NYSE paused for a minute or two at about 2:40 p.m. ET, the off-exchange computers kept searching to execute trades.

•  And in some cases, the off-exchange computers found no bids at all. When that happens, market-making computers see a zero bid, then offer a penny higher to capture the trade and collect a commission -- hence the trades of just one cent for several stocks, including Accenture (ACN), Boston Beer (SAM), Exelon (EXC, Fortune 500).

2

Warm-up exercise

•  Answer the following questions after you watch the video:

•  From a human computer interaction perspective, identify the level where the most important error has occurred.

•  What are your suggestions for fixing this error? •  5 min for writing down your ideas + 5 min for

class discussion

3

Objectives

• By the end of this class you should be able to…   Explain the importance of involving

users in requirements gathering   Choose data gathering techniques

for a given scenario and justify the choice

  Design your own interviews and questionnaires

Requirements gathering

Design

Prototyping User testing and evaluation

5

  Domain knowledge, users, user characteristics …

  Tasks and task characteristics   Physical environment, social environment,

organizational environment, availability of user support …

  Usability goals, constraints, trade-offs …

What kinds of information should we gather?

6

7

What is the First Law of

Human Factors Design?

Know Thy User.

The User is Not You.

8

Designers are not typical users

“Steve Wozniak, the whiz-kid co-founder of Apple Computer offered the first public glimpse of CORE, his latest brainchild. “CORE, which stands for controller of remote electronics, is a single device that allows consumers to fully operate their home equipment by remote control as long as the equipment is all in one room…

CORE comes with a 40 page user manual. But Wozniak says users of his gizmo won’t be daunted because initially, most will be ‘techies’”

9

The designer’s clients may not be users

•  “ in my university, copying machines are purchased by the printing and duplicating center, then dispersed to the various departments. The copiers are purchased after a formal “request for proposals” has gone out to manufacturers and dealers of machines. The selection is almost always based on price, plus a consideration of cost and maintenance. Usability? Not considered. The state of California requires by law that universities purchase things on a price basis; there are no legal requirements regarding usability or understandability of the product. That is one reason we get unusable copying machines and telephone systems.”

•  From Norman, “The design of everyday things”

Example: User analysis for design of eBooks

  What information would you want to know about users?

  What information might be irrelevant?

10

When we try to understand users, we collect data

Observation   Live (direct) or video (indirect)

Interview or focus group   Structured or flexible

Keystroke / mouse logging (indirect) Questionnaire (open, closed, semantic differential,

Likert scale)

What are the advantages / disadvantages of these methods? Example: user analysis at Microsoft

11

12

Interviewing strategies

• Goals: –  to produce a descriptive model of

current work practice that can be used to guide further design activities

– To get a clear picture about the user’s domain knowledge which will be used when interacting with your application

• Techniques are adaptations of methods used by ethnographers and cognitive scientists

13

Expert knowledge

•  Potential users are experts in the work domain which the application is intended to support

•  Analysts typically underestimate the complexity of expertise in a domain of knowledge different from their own.

•  Aspects of expertise relevant to design: –  The organization of expert knowledge –  The tacit nature of some knowledge –  The potential for experts to explain their expertise to

you: translation competence

14

Organization of expert knowledge

•  Macro-level: hierarchic organization, taxonomy with categories and subcategories

•  Micro-level: “chunks” of frequently occurring patterns stored in the long-term memory

•  Each chunk has an attached procedure for giving a fast appropriate response in a problem-solving situation

15

SENG 310 : Human Computer Interaction, Lecture 3.

16

17

Tacit knowledge

• Much of an expert’s problem solving knowledge has become automatic through extensive and frequent use

• Tacit (implicit) knowledge is difficult for an expert to articulate, especially when asked to do so directly

• Solution?

18

Observational techniques

•  Observe users work in their usual work environment

•  Main difference from interviews: analyst does not interact with user during observation (passive role)

•  Indirect observational techniques may replace direct observation (and interviews) for a first-round user analysis under special circumstances.

SENG 310 : Human Computer Interaction, Lecture 3.

19

20

Translation competence

•  Analysts are often novices in the work domain being analyzed

•  The domain expert translates knowledge to the convenience of the analyst (an outsider)

•  Solutions: –  Careful study of the domain-related terminology

relevant to your UI –  Ask questions –  Ask for examples

21

Building interviews

• Contextual interviewing – Good for user analysis, but also for

prototyping purposes – Consists of:

• Semi-structured interviewing • Ethnographic style observations

22

Contextual interviewing

• Key issues: – Deciding who to interview – Deciding how to ask and who to ask – Analyzing the data – Planning the interview process

23

Who to interview?

• People that are representative for your target users

• Get a good mix • Ask participants who else to talk to • How many? 6-10 according to

usability experts

24

Developing user profiles

•  Iterative • Develop an initial profile • Use that profile to determine an

initial round of people to interview •  Interview this round and update your

profile • Contact remaining participants and

interview (iterate as necessary)

25

Developing user profiles

• Think about relevant characteristics – Those that all users might share – Those that might make a difference

among users – Example: for an on-line flight booking

system, relevant user characteristics are: …

26

How to plan the interview

•  Identify who to interview –  Use initial user profiles

•  Make interview appointments •  Decide who will make the visit •  Have a procedure •  Buddy system: interviewer/scribe •  Consider pros/cons of taping •  Always summarize immediately afterwards

together

27

What to ask? How to ask? Dos

•  First thing: always explain to participants why you do this interview. •  Semi-structured interviewing

Develop a set of questions that allow for open-ended responses and elaborations Ask specific questions about how people approach the task or

activity •  Understanding context Have people work through the actual task through the meeting •  Critical incidents Ask them to tell you about the best, the worst, and the strangest time they did X. The Last Question

28

What to ask? How to ask it? Don’ts

•  questions with yes/no answers •  leading questions •  Linear thinking •  Speculative questions

–  Ex: Do you think you might use an electronic diary?

•  system-oriented questions –  Ex: Do you think you'd use feature XYZ?

•  general questions –  Ex: tell me how you do your job

29

What to ask? How to ask?

• Critique the following interview

• Provide suggestions for interview redesign (new questions etc)

30

Post-interview data analysis

•  Identify emerging patterns indicating: –  Important design priorities –  Important design issues –  Develop and update user profiles and personas

•  Capture priorities and issues as tasks •  Identify other information that you need for building your first prototype: sorts and amounts of data, data sources, special equipment etc.

Key Points from today

•  User analysis is one core component of requirements gathering

•  There are many techniques for data acquisition for user analysis, we need to carefully mix and match

•  Points to consider when designing interviews

•  From textbook: points to consider when designing questionnaires