Introduction to HCI MSc Computer Sciencerjh/courses/IntroductionToHCI/2012-13/MScCS... · 1 1 MSc...

1

1

MSc Computer Science:Introduction to Human Computer Interaction

Bob Hendley

Room: 236, CS

MSc CS: Intro. to HCI 2012-13 22

Introduction to HCI

100% coursework� Re-assessment by repeat

Classes:� Mon. 4:00 301 BioSciences

� Tues. 2:00 G33 Education

Notes are at:� http://www.cs.bham.ac.uk/~rjh/courses/MScCSINtroToHCI/


First some motivation

……


The world is full of bad design …

Photo from Jacob Nielsen’s Alertbox June 7, 2004


…. And …


… and

2


What’s wrong with these?

Complex

Ugly

Non-intuitive

Fail to consider:

� User

� Usage

Non-ergonomic


What’s wrong with these?

Complex

Ugly

Non-intuitive

Fail to consider:

� User

� Usage

non-ergonomic

Good design must:

Consider capabilities of user

Goals of user & usage scenarios

Take a user focussed view

� NOT system focussed!


See:

http://www.baddesigns.com/

http://www.webpagesthatsuck.com/

http://www.useit.com/alertbox/bad-design.html

… and many many more!

http://www.baddesigns.com/

http://www.webpagesthatsuck.com/

http://www.useit.com/alertbox/bad-design.html

… and many many more!


And sometimes good design …


And …


Why are these good?

User focussed� Driven by:

� Capabilities of people

� What the user is doing

� How they will be used

� Context of use:� For instance: safety critical, social, training/learning …

� Aesthetics

� Ergonomics

Evaluated & modified

3


Many things look good – but aren’ t!

http://www.zaha-hadid.com/


Does it matter?

It may just confuse you!

But:

� You might get a ticket

� Take longer to complete a task

� Delete your work!

� Crash your car!

� Kill your patients!

� …….


Or worse:The 2000 USA Presidential Ballot in Florida


So why look at HCI?

Pragmatically:

Typically, the largest part of a software project:

� Cost

� Time

The only bit the user sees!


So, what is it about?

Screen design?

Interaction?

People?

Experiments?


So, what is it about?

Screen design?� Attractive

� Functional

Interaction?� Shallow

� Deep

People?� Capabilities

� Constraints

� Goals/tasks etc.

Experiments?� To evaluate a

system

� To learn about people’s capabilities

4


HCI is changing..

Physical things

GUI interfaces

Collaborative interfaces

Internet technologies

Social technologies

Ubiquitous technologies

?


What’s the problem?

Slide idea by Bill Buxton

transistorsspeeddiscscost

1950 1990 2030

Computerabilities

Features

Productivity

Ease of use

1950 1990 2030

PromisedFunctionality

1950 20302000BC

human

abilities

Threshold of complexity

So:

•People can’ t get

smarter

•Technology gets more complex

•Interfaces must fill the gap


Human Computer Interaction

Computer Science

Ergonomics

Psychology

Sociology

…and more


To make better interactive technology …. We need to:

Know about how people interact with things

Know about what people can and can’t do� And when

Know about the situations in which people

do things

Know about the basics of good design

Understand people’s goals

… and then check whether it works


We may not become expert psychologists, designers, ergonomists, social scientists ..

… but we can all learn things about people

and design that will help us create better artefacts than we would otherwise have done…


HCI is made up of…

Theories: learn and apply

Models: create and use

Methods: master and apply

Guidelines: learn and use

Principles: understand and apply

Techniques: master and use

So, elements of

Science

Art

Engineering

Craft

….

5


… and these may concern:

People

Analysis

Design

Implementation

Evaluation

…..


So, a tentative outline:

Motivation

People. Their abilities & Limitations

Coursework

Techniques for design� User centred design

� Scenarios

� Personas

� Prototyping

� Design Evaluation

Evaluation with users


Text:

Human Computer Interaction, 3rd EditionAlan Dix, Janet Finlay, Gregory Abowd, Russell BealePrentice Hall, 2004. ISBN 0-13-046109-1

http://www.youtube.com/watch_popup?v=ZfV4R4x2SK0






Lecture 2

It’s all about people:Levels of information processing

Perceptual systems

� What & how

� Vision

Memory

Lessons for HCI


What is a User?A dip into some examples from psychology

Is

Behaves

Feels


Different types of human processing

Norman introduced the idea that product design should address three different levels of cognitive and emotional processing:

� Visceral

� Behavioral

� Reflective.

6


Visceral Processing

The most immediate level of processing, in which we react to visual and other sensory aspects of a product that we can perceive before significant interaction occurs. Visceral processing helps us make rapid decisions about what is good, bad, safe, or dangerous.


Behavioral Processing

The middle level of processing that lets us manage simple, everyday behaviors, which, according to Norman, constitute the majority of human activity.

Norman states:

historically, interaction design and usability practices have primarily addressed this level of cognitive processing.


Reflective Processing

The least immediate level of processing, which involves conscious consideration and reflection on past experiences.

Reflective processing can enhance or inhibit behavioral processing, but has no direct access to visceral reactions.

This level of cognitive processing is accessible only via memory, not through direct interaction or perception.


What makes up a person?

Senses

Body

Thinking

Memory


The Human as an Input Device

How we make ‘sense’ of the

world around us… inputs and

understanding


Each Sense has…

A sensor – e.g.. Eye, skin, ear etc

A process – nerves, electricity etc

Limitations – pitch, brightness etc

….. And there is the added complexity

of individual differences in sensory perception

7


Perception & Senses

Vision

Hearing

Touch

Smell & taste

Motion/Balance

Kinethesis/ Proprioception

.. and others –temperature, pain, pressure etc.


Vision

Primary sense

� Most important for HCI

High bandwidth (10GB/sec ??????)

High resolution

Specialist processors/processing

� Take advantage of this and especially pre-attentive processing


Pop outs & gestalts

No cognitive processing required

Very fast

Can be inhibited/confused

Examples:� colour

� size

� Number

� Motion


Some Examples


Connectedness

a b

c d


Symmetry

8


Closure

a b


Object interpretation


Foreground & Background


Contours

a

b


Transparency


Texture

ab

c d

9


8568972698468976268976435892265986598655489768926989802462996874026557627986489045679232769285460986772098908345798027907590470982790857908477290875908279087549870985674906897578625984569024379047219079070981145085689726984689762689764458922659865986554897689269898


856897269846897626897643589226598659865548976892698902462996874026557627986489045679232769285460986772099083457980279075904709827908579084772908759082790875987098567490689757862598456902437904721907907098114585689726984689762689764458922659865986554897689269898


Orientation


Motion


Shading


Faces/emotion …..

10


Length Width

Parallelism Curvature

NumberAdded marksSpatial grouping

Shape

Enclosure


Depth – seeing the 3D world

Many depth cues

� Stereopsis

� Occlusion

� Sharpness

� Accommodation

� Contrast

Some will dominate others

In other cases, conflicts cause sickness


Problems

People differ:

� Colour blindness

� Stress levels

� Stereopsis

� etc.

There is not a complete understanding of human visual system


Interpreting images - context

The visual system compensates for:� movement� changes in luminance.

Context is used to resolve ambiguity

Optical illusions sometimes occur due to over compensation











11







Interference

Try naming the ink colour in first column

� Then try the second!


Touch

Provides important feedback about environment.

May be key sense for someone who is visually impaired.

Some areas more sensitive than others e.g. fingers.

Also consider:

Stimulus received via receptors in the skin:� thermoreceptors – heat and cold� nociceptors – pain� mechanoreceptors – pressure

Kinethesis - awareness of body position � affects comfort and performance.


The Human as a Store

Humans have the capacity to remember and retrieve information…� this affects the way

they use technology

� How does it work?


Three Different ‘Stores’

Sensory buffers: momentary stores for stimuli received by the senses. This information, unless encoded in the short-term memory, is quickly lost.

Short-term memory (or working memory): short-term memory acts as a store for

information required fleetingly.

Long-term memory: this forms the main

resource for memory.


Short Term Memory

An example of this would be recalling a telephone number long enough to write it down. Short-term memory degrades quickly, and has a limited capacity. Quick access time – 70msShort term storage – ~20 second decay time

Limited capacity� Length of sequence remembered in order = 7 ± 2 (Miller, 1956)

� Chunking

Maintained and increased with rehearsalNowadays referred to as ‘Working memory’

12


Chunking and STM

Short-term memory holds information that is actively being used (thought about, reasoned with).

A chunk can be thought of as a single object that conveys a larger amount of information (e.g. 0121 414 xxxx).

Examples of these include words, shapes and colours. However, the information decays in seconds as items are displaced by new items coming in.


LTM – Networked chunks

Here we store everything we ‘know’ . Long-term memory is characterised by huge capacity, slow access time and relative accuracy over time.

It is organised in an Episodic wayevents and experiences in sequential order…….. and a Semantic way� facts, concepts and skills that we have acquired

Storage� Structure, familiarity and concreteness� Decay, interference, forgetting

Retrieval� Recall - reproduced� Recognition – clue given – faster, more accurate ….


Impact on HCI

Understanding the limitations and capabilities of humans is essential as guidance for good design. E.g.� Recognition rather than

recall

� Grouping

� STM limitations

� …….

But there is much more to this than we have described here!

But these models are not enough:� There are

competing/inconsistent theories

� They are incomplete

Large individual differences� Vision

� Motor skills

� Cognitive skills

There are model based tools that aim to predict performance

� But they have limited scope


An Example


Take a look at this example!

If you don’ t believe me:

� The door study

If you don’ t believe me:

� The door study


Lecture 3

Coursework:

� Groups

� Coursework Specification

� Assessment

13


Lectures 4 & 5

Design� Alternative models

� Where is the focus?

� UCSD (User Centred System Design)

� Personas

� Scenarios

73 MSc CS: Intro. to HCI 2012-13 7474

Understanding the Design Process

What is the process?

� …. And what should it be?

� …. Remember, we want:

� To produce good designs

� To produce them efficiently

Where are good/bad decisions made?

Why are good/bad decisions made?


Developing Interactive Products

Stage 1 – build time� 1a. Designers, understand

requirements and design solutions

� 1b. Implementors, construct, test and refine system

Stage 2 – use time� ‘Stakeholders’ use the

system and because their needs, contexts and objectives can only be anticipated – some changes are generally made to the product at this stage

The more time spent in the early stages:

� The lower the cost

� The better the solution

So:

� Focus on design

� Focus on ‘stakeholders’ –end users ++


RE responsible in the failure of 90% of larger projects(Davis et al., 2006)

Poor requirements management can be attributed to 71% of software projects that fail; greater than bad technology, missed deadlines, and change management issues (Lindquist, 2005)

Fixing mistakes made at requirements the elicitation stage accounts for 75% of all error removal costs (Davey & Cope, 2008)

Poor execution of elicitation will almost guarantee that the final project is a complete failure (Hickey & Davis, 2003)


Efficient Development..

Relies on the system’s developer having a GOOD understanding of the ‘stakeholders’� Needs

� Capabilities

� Objectives, goals, tasks, plans …..

� Context

� Etc.

... And knowing what the technology can do!


The Focus of the development

… can vary..

•Context

•System

•User

14


System Centred Design





What can I easily build on this platform?

What can I create from the available tools?

What do I, as a programmer, find interesting?

How do I (the developer) see the system?

This is

what you get!


User Centred …

Design is focused upon the users:

� Abilities and real needs

� Context

� Work

� Tasks

� Values

� ….


Methodologies

Depending on the focus we can label our methodology as:

� Abilities and needs: User Centred Design

� Context: Contextual Design

� Work: Goal Directed Design

� Tasks: Task Centered Design

� Values: Value / Worth Centred Design


User Centred [System] Design

Focus on:

� the people who will use the system

� their preferences

� their requirements

Building models of:

� Users

� Tasks

� Systems

Iterative process

Prototyping and Evaluation by users

Descriptive

models that

build an

understanding

15


UCD


Core Concepts in UCD

Early stages� User model

� Task models

� Context

Later stages� Inclusive Design

� Design for all

� Universal Access


For now: our UCD

The Early stages� Focus on:

� Users

� Tasks

� contexts..

� But also on� Goals

� values


Who are Users in UCD?

They should represent the actual users:� Not one user but all

different classes

� All types of user e.g.� Learning: students,

teachers, parents, administrators …

� eCommerce: customer, marketing, sales, managers …

Consider:

� Yourself

� Your peers

� Your granny

� Your nephew

A system designed to teach 7 year olds remedial

arithmetic:

•Required a reading age of 14

•Sophisticated cognitive & social skills

•Used green text on a blue background


Video here….

http://www.computing.dundee.ac.uk/projects/UTOPIA/


Tasks (and Goals)

Tasks

� Not all systems are task based (eg. Games)

� Not all tasks can be easily specified

Goals

� Irrespective of the user tasks, there can be a conflicting or complementary goal

� Interruptions

� To have fun?

16


Context

Where will the system be used?

What sort of technology will be deployed?

Will the users be able to get any help?


Values

What matters to the user?

What is important in the context?

What are the business concerns?


Models of Users

.. It’s all about empathy…


Warning!!!

This section might seem very fluffy/cuddly, very beard and sandles …..

But it works!

(if you engage with it)


Personas & Scenarios

Purpose:

To build an understanding/to construct ‘models’ :� Of users of the

system

� Of the way they will use it

To guide & evaluate designs

Methods:

Aim for good coverage of usage

� Balance cost/value

(Ideally) Informed by real (potential) users

� Interviews, observations etc.

� Who are they? What are their constraints? What are their goals? etc


Modelling Users using Personas

Widely promoted by Alan Cooper as an integral component of Goal-Centred (Directed) design

Refer to: www.interactionbydesign.com/presentations/olsen_persona_toolkit.pdf

Personas are user archetypes that we construct from behavioral data� gathered during user interviews and field

observations.

17


The Power of Personas

The personas are given realistic names, faces, and personalities to foster user empathy within a product team.

Personas can be used later to evaluate prototypes and the final product

A critical element of personas - beyond

capturing typical user behavior patterns and roles - is capturing user motivations in the

form of specific goals.


Note:

In programming we design and program test cases for software� sometimes before even writing the program itself.

HCI approaches this in a similar fashion by creating scenarios which they expect users to encounter or run through. One major distinction is that scenarios cover the most likely of cases and only sometimes include the edge cases. They will never, ever, cover every possible scenario.


Creating Scenarios

“A scenario is a concise description of a persona using a product to achieve a goal”(Cooper).� concise : short but complete; breadth instead of

depth

� product : assume the product (software or physical device) exists, even if it doesn’ t

� goal : the reason why we perform a task

There must be enough detail to drive design & evaluation


Why Use Scenarios?

They build an understanding of the users

They drive requirements analysis and design

Scenarios help us to validate our design

Scenarios help us check our assumptions

Successful Scenarios help us transfer theoretical/conceptual design to “wire frame” design

Like Personas, Scenarios create a sharedunderstanding of the end users - for the entire design team.


ExampleSteve texts using predictive text, he

is sending a message to a number he doesn’ t have in his contacts (it is a girl he met on the train and he wants to meet up with her). He has the number on a scrap of paper. He is walking down towards New Street Station, it is getting quite dark, he is texting without checking the screen


Another Example:Booking train tickets

Steve Jones:

1. Steve has a meeting in London at 10:00 on Tuesday. He wants to find a train that will arrive by 9:30 and return after 7:00. When he has selected the train he needs to tell purchasing to buy it. He needs to pass the details on to his wife who will ferry him to/from the station.

2. Steve lives in Stratford and wants to compare the options for tickets for his commute 4 days a week to the University.

3. On Sunday, Steve wants to take his family to a historic place for a day out. He wants to choose the most interesting, quickest and cheapest option. He does not want to use a replacement bus service.

18


Writing Good Scenarios

Brainstorm, within the context of our problem domain, the goals our Personas will have

Write the Scenarios for a specific Persona

Go for breadth rather than depth

� it is more important to describe things from start to finish rather than in exhaustive detail


An example Persona template


An example Persona


And another


An example – open diary

system

Who are the users?

What are they trying to do?

Consider:

Students, lecturers, Granny ….

Privacy

Devices & synching

Anniversaries

Regular appointments

Types of appointments� hard � soft

� Movable/fixed

� Location

� Etc etc


Some Examples

Here are some examples of personas. See

www.fluidproject.org

19


Further Work

Investigate the use of personas by searching for toolkits and case studies


Lecture 6

Tutorial

� Review problem specifications

� Tutorial with groups


Lecture 7&8

Prototyping� What is a prototype & why do it

� Lofi prototyping� Screen mockups

� Storyboards

� Card-based prototypes

� Hifi prototyping� Tools


Prototyping and Construction

What is a prototype?

Why prototype?

Different kinds of prototyping� low fidelity

� high fidelity

Compromises in prototyping

� vertical

� horizontal

Construction


What is a Prototype

In many design fields a prototype is a model:

� Cars

� Buildings

� Appliances

� Etc.


Aims of prototyping

To evaluate alternative solutions:

Quickly

Cheaply

Focus:

Broad but shallow

Deep but narrow

Prototypes may be:

Disposable

Evolving

Purpose:To understand requirements

To understand design

To understand technology

Make mistakes early and cheaply!

20


Methodology for prototyping

Iterative� Usually several stages of

prototyping

Consider alternative solutions

May have several orthogonal strands of prototyping� E.g. Cars: body, interior,

drivetrain ….

� Software: UI, DB, Reasoning

Evaluate each prototype

Be clear about the purpose

Minimise cost

� Time

� Effort

� Only do what is necessary to meet goals


What is an HCI Prototype?

In interaction design it can be (among other things):

� a paper-based screen design

� a storyboard, i.e. a cartoon-like series of scenes

� a Powerpoint slide show

� a piece of software with limited functionality – built quickly using tools/scripting languages etc

� a video simulating the use of a system

� .....

Or even ....

� a physical mockup (e.g. a ‘phone)

There may be parallel prototypes -to test different aspects

The aim is to understand the space of designs:

� Test alternative solutions

� Understand how they might be built

� Evaluate them with users


Why Prototype?

Evaluation and feedback are central to interaction design

Stakeholders (ie. Users) can see/hold/interact with a prototype more easily than a document or a drawing

Team members can communicate effectively

You can test out ideas for yourself

It encourages reflection: very important aspect of design

Prototypes answer questions, and support designers in choosing between alternatives


What to Prototype

Technical issues

Work flow, task design

Screen layouts and information display

Interaction models and modes

Difficult/controversial/critical areas

….


Lo-Fi Prototyping

Uses a medium which may be unlike the final medium� e.g. paper, cardboard, photoshop …

Is quick, cheap and easily changed

Examples:

� sketches of screens, task sequences,

� ‘Post-it’ notes

� Storyboards

� ‘Wizard-of-Oz’


Why Use Low-Fi Prototypes

Traditional methods take too long:� Sketches � prototype � evaluate �iterate

Can simulate the prototype:� Sketches act as prototype:

� Designer “plays computer”� Other design team members observe & record

� Might sound silly:

� but it is very effective

Kindergarten implementation skills� Allows non-programmers to participate

Widely used in industry

21


Storyboards

Often used with scenarios, bringing more detail, and a chance to role play

It is a series of sketches showing how a user might progress through a task using the device

Used early in design


Generating Storyboards

Paper-based prototypes Example 2


Card-based prototypes

• Combine screen mock-ups and storyboard• Use (e.g.) index cards (3 X 5 inches)• Each card represents one screen or part of

screen• Designer drives interaction• Often used in website development

Interaction

Interaction


Storyboard used to generate prototype

22


Hi-Fi Prototyping

Uses materials that you would expect to be in the final product.

Prototype looks more like the final system than a low-fidelity version.

For a high-fidelity software prototype common environments include:� Director, Flash, Visual Basic, Powerpoint, ….

Danger that users think they have a full system……. see compromises


Wizard of Oz

The user thinks they are interacting with a computer, but a developer is responding to generate the output rather than the system.

Usually done early in design to understand users’ expectations

What is ‘wrong’ with this approach?


Inte

rface

Pro

toty

pe

Experim

ente

r In

terfa

ce

Follo

ws S

cript

Wizard of Oz

Can be used with Cards or Hi-Fi prototype


Compromises

All prototypes involve compromises� That’s the point!

For software-based prototyping maybe there is a slow response? sketchy icons? limited functionality?

Two common types of compromise� ‘horizontal’ : provide a wide range of functions, but

with little detail

� ‘vertical’ : provide a lot of detail for only a few functions

Compromises in prototypes mustn’ t be ignored.

� Final product still needs engineering


Hi-Fi Disadvantages

Distort perceptions of the tester:

� Formal representation indicates “ finished” nature

� People comment on colour, fonts, and alignment

Discourages major changes:

� Testers don’ t want to change a “ finished” design

� Designers don’ t want to lose effort put into creating the hi-fi design


Down-sides to informal design

Clients

� Often see the fidelity of the interface as an indication of development effort

� Often hard to involve them as subjects

� Talk to them early and often!

� Explain the process and set expectations up front!

23


Summary

Different kinds of prototyping are used for different purposes and at different stagesPrototypes answer questions - so prototype appropriatelyConstruction: the final product must be engineered appropriatelyConceptual design (the first step of design) � Consider interaction types and interface types to prompt creativity

Storyboards can be generated from scenariosCard-based prototypes can be generated from use cases


Some quick techniques!

‘Steal’ some screenshots

Use a paint/draw package to customize

Use tools like powerpoint to ‘glue’ it

together

� Screens

� Sequences

134


Start with a Blank Page


Use a drawing program to insert items you want

Be experimental ... But don’t get too carried away by bad taste!

Remember that you will evaluate this later


Useful Tricks

Print Screen and then cut out elements you like� Windows: Alt-PrtScn captures the active window into the

clipboard� Mac OSX Grab Utility

� Open Grab (located in Applications/Utility).

Use a simple graphics editor like Paint to stitch the images together� Copy & Paste many elements for different looks/feels


PowerPoint/Web-Based

Provides the illusion of interactivity

Can employ screenshots to show parts of your webpage

Can be used as just a “click-through” of

screenshots

24


Resources

http://www.krisjordan.com/2008/09/07/10-minute-mock-prototyping-tips-for-powerpoint/

http://www.istartedsomething.com/20071018/� Demo Program

Balsamiq:� http://www.youtube.com/watch?v=zLysy3IPfFI


Remember:Aims of prototyping

To evaluate alternative solutions:

Quickly

Cheaply

Focus:

Broad but shallow

Deep but narrow

Prototypes may be:

Disposable

Evolving

Purpose:To understand requirements

To understand design

To understand technology

Make mistakes early and cheaply!


Lecture 7

User Interface evaluations:

What are they and why do them?

When:� Throughout the design phase

� At the end

How:� By inspection

� By experiment


Why Evaluate?

Evaluation is important:

� To compare design choices:

� to assist us in making decisions

� To determine how usable they are (possibly, for different user groups):

� So they can be improved

� To identify good and bad features:

� to inform future design

� To understand what makes a good interface


Compare this with software testing

Evaluate & test as you build:� Including prototypes

Test the completed product:� Does it work?

Reflect on what is produced and how:� Do it better next

time

There are always multiple dimensions:� Correctness, efficiency,

reliability …

Cannot be exhaustive:� Focus where return is

greatest

Compare:� ‘synthetic’ test

� ‘ real world’ test

Methods may differ but aim is the same!


How to organise your evaluations

Evaluation is expensive:� Focus where it is

most:� Valuable

� Easily/cheaply undertaken

� Real users are expensive & elusive:� Use wisely &

economically

Evaluate at all stages:

� Analysis

� Design

� Implementation

� Delivery

Catch mistakes early:

� Especially the big ones!

So: Think & plan

25


What are we interested in?

Five aspects of usability:

Learnability : ease of learning especially for novice users.Efficiency: steady-state performance – particularly of expert users. How efficiently can they do their job.Memorability : ease of using system intermittently for casual users.

Errors : error rate for both minor and serious errors.

Subjective Satisfaction: Do they like it?

This may not be comprehensive, but:� all of these are important

� The balance between them will vary!


Evaluation Methods

There are very many techniques for evaluating interfaces

Broadly they can be divided into:� Inspection Methods

� Testing/experimental methods� But, this division is not a

hard one.

Degree of rigour can be varied

Inspection methods:

� No users needed!� May be informed by

Personas & scenarios

� Heuristic evaluations

� Walkthroughs

� Others

User Testing/experiment:

� Users needed

� Usability tests

� Empirical:� Observe

� Measure

� Analyse

� Hard & expensive


Inspection Methods

Heuristic Evaluation

� Nielsen’s Heuristics

� How to do it

� Effectiveness of inspection methods


Inspection Methods

Methods that are based on inspections:

� Heuristic evaluation

� Heuristic estimation

� Cognitive walkthrough

� Feature inspection

� Standards inspection

� Pluralistic walkthrough

� Consistency inspection

� Formal usability inspection


Heuristic evaluation (what is it?)

Method for finding usability problems

Popularized by Jakob Nielsen

“Discount” usability engineering:

� Use with working interface or prototypes

� Convenient

� Fast (cheap!)

� Easy to use


Systematic inspection to see if interface complies to guidelines� Driven by Heuristics (Rules of thumb)

Method� Typically, 3-5 inspectors

� usability engineers, end users, double experts…� Inspect interface independently (~1–2 hours for simple interfaces)� Compare notes afterwards

� single evaluator only catches ~35% of usability problems

� 5 evaluators catch ~75%

Works for paper, prototypes, and working systems

150

Heuristic evaluation

Eval: 1 2 3 5 10

Teledata 51% 71% 81% 90% 97%

Mantel 38% 52% 60% 70% 83%

Savings 26% 41% 50% 63% 78%

Transport 20% 33% 42% 55% 71%

26


Points of Variation

Evaluators

Heuristics used

Method employed during inspection


Evaluators

These people can be novices or experts

� “novice evaluators”: Often domain experts

� “ regular specialists”: Usability experts

� “double specialists”: Domain & usability experts

Each evaluator finds different problems

The best evaluators find both hard and easy problems


Heuristics

Heuristics are rules of thumb that are used to inform/guide the inspection…

There are many alternative heuristic sets:

� Nielsen’s


Nielsen's Heuristics

1. Visibility of system status

2. Match between system & real world

3. User control and freedom

4. Consistency & standards

5. Error prevention

6. Recognition rather than recall

7. Flexibility & efficiency of use

8. Minimalist design

9. Help error recovery

10.Help & documentation


1. Visibility of system status

searching database for matches


What is “reasonable time”?

0.1 sec: Feels immediate to the user. No additional feedback needed.

1.0 sec: Tolerable, but doesn’ t feel immediate. Some feedback needed.

10 sec: Maximum duration for keeping user’s focus on the action.

For longer delays, use % done progress bars.

27


2. Match between the system and the real world

Make sure the system’s model matches the user’s – or make the system’s clear

Socrates: Please select command mode

Student: Please find an author named Octavia Butler.

Socrates: Invalid Folio command: please


3. User control and freedom

The user will make mistakes:

Don’ t force users to take a particular path� Provide exits for mistaken choices

Enable:� undo

� redo


4. Consistency and standards


5. Error prevention

People will make errors.

� Yet we can try to prevent/reduce them.

� How might you go about trying preventing errors?


6. Recognition rather than recall

Minimise load on user’s memory

Menus vs Commands

� E.g select country code rather than type it

Display format/options next to text box

Carry over/display information from different parts of dialogue


7. Flexibility and efficiency of use

Is usage as efficient as possible?

Consider:

� Keyboard accelerators

� Macros & keyboard macros

� Recently used files

� …..

28


8. Aesthetic and minimalist design

Keep it simple!


9. Help users recognize, diagnose, and recover from errors

SEGMENTATION VIOLATION! Error #13

ATTEMPT TO WRITE INTO READ-ONLY MEMORY!

Error #4: NOT A TYPEWRITER


10. Help and documentation


We should wonder…..

If this is a sensible heuristic set:

� Coverage

� Uniqueness

� Ease of use

There are others – but this set is widely used


Phases of a heuristic evaluation

Pre-evaluation training - give evaluators needed domain knowledge and information on the scenario

Evaluate interface independently

Rate each problem for severity

Aggregate results

Debrief: Report the results to the interface designers


Severity ratings

Each evaluator rates individually:

0 - don’ t agree that this is a usability problem

1 - cosmetic problem

2 - minor usability problem

3 - major usability problem; important to fix

4 - usability catastrophe; imperative to fix

Consider both impact and frequency.

29


Styles of Heuristic evaluation

Problems found by a single inspector

Problems found by multiple inspectors

Individuals vs. teams

Goal or task?

Structured or free exploration?


Empirical studies of effectiveness of heuristics

Problems found by a single inspector:

� Averaged over six case studies:

� 35% of all usability problems

� 42% of the major problems

� 32% of the minor problems

Whilst not perfect:

� finding some problems with one evaluator is muchbetter than finding no problems with no evaluators!



Varies according to � difficulty of the interface being evaluated � the expertise of the inspectors

Average problems found by:� novice evaluators - no usability expertise - 22%� regular specialists - expertise in usability - 41% � double specialists - experience in both usability and the particular

kind of interface being evaluated - 60%� also find domain-related problems

Tradeoff:� novices less good:

� but cheaper!



Evaluators miss both easy and hard problems:‘best’evaluators can miss easy problems‘worst’evaluators can still uncover hard problems

MSc CS: Intro. to HCI 2012-13 173173 MSc CS: Intro. to HCI 2012-13 174174

Problems found by multiple evaluators

3-5 evaluators find 66-75% of usability problems:

� different people find different usability problems

� only modest overlap between the sets of problems found

30


Problems found by multiple evaluators

Where is the best cost/benefit?


Individuals vs. teams

Nielsen:

� recommends individual evaluators inspect the interface independently

Why?

� evaluation is not influenced by others

� independent and unbiased

� greater variability in the kinds of errors found

� no overhead required to organize group meetings


Self Guided vs. Scenario Exploration

Self-guided� open-ended exploration� Not necessarily task-directed� good for exploring diverse aspects of the interface, and to follow

potential pitfalls

Scenarios� step through the interface using representative end user tasks � ensures problems identified in relevant portions of the interface � ensures that specific features of interest are evaluated � but limits the scope of the evaluation - problems can be missed


How useful are they?

Inspection methods are discount methods for practitioners. They are not rigorous scientific methods.

� All inspection methods are subjective.

� No inspection method can compensate for inexperience or poor judgment.

� Using multiple analysts results in an inter-subjective synthesis.

� However, this also

a) raises the false alarm rate, unless a voting system is applied

b) reduces the hit rate if a voting system is applied!

� Group synthesis of a prioritized problem list seems to be the most effective current practical approach.


A recipe …..

Use several independent evaluators

Ensure evaluators understand purpose & scope

� Ie. Plan, focus and direct!

Use personas & scenarios to drive evaluation

Collate and analyse results

Generate recommendations

Remember:� Finding problems with

systems is inevitable and acceptable:� (maybe if they don’ t exist

you are not trying hard enough!)

� But not spotting them is NOT acceptable!


Remember

Problems can arise because of:

� Mistakes:

� You just got it wrong or it

works for you but not for the actual users

� You are trying to be creative:

� sometimes it doesn’ t quite

work!

� A good design for one user

class may be bad for other classes

� Compromise:

� A good design from one

perspective may be bad from another

The aim of the evaluation is to be explicit about issues and what to do about them.

You can present results as a table:

Heuistic Issue Severity Recommendation

System status The ….

The …0

5

Not an issue

Modify …

Match wit real world

31


Lecture 8

Usability Testing


Usability testing

This is concerned with experimental evaluation of use with users

� Design experiment

� Conduct experiment

� Collect data

� Analyse data

� Draw conclusions


Why do this?

The ultimate test!

� Designers believe that they understand users

� Designers understand what they have designed

� They find it easy, intuitive, reliable …. to use

� They are often wrong!

Conduct the experiment, collect the data, look at the results …� Sometimes you are very surprised (disappointed!)


So, how do we do this?

There are many approaches:� Informal

� Sit user down with system

� Tell them to use it

� Ask them what they think

� Formal� Controlled sets of users

� Defined task

� Video, record keystrokes, measure time, error rate etc.

� Statistical analysis of data

� And every stage between!


Problems with informal testing

Informal/subjective tests� May not be very reliable

� Short term – whereas usage may be long term

� Users may be:

� Atypical

� Too few

� Subjective assessment is unreliable� Why?

� Task & environment is artificial

� But:� Cheap

� Will uncover many problems


Problems with formal testing

Very, very expensive� Time of:

� Users (numbers required & duration)

� Experimenters

� Analysis

Often answer ‘small’ questions� Because of need to control experiment

But …. Can be very useful (or even essential)� Safety critical applications

� To establish principles!

32


So, where does this leave us?

As always, it’s a matter of balance:� How important is

usability?� What aspects are

important?

� What resources can we devote?� Costs

� Timescales

� User availability

There is a balance to be drawn between:� Analysis

� Validation of:� Requirements

� Design

� Product

Use limited access to users most appropriately

Produce a plan!


A recipe

Load user resources up front� UI requirements

� Development of personas & scenarios

Use personas to drive� Analysis

� Design

� Testing

Use heuristic evaluations

Use personas to drive testing with usability ‘experts’

Use non-domain users to test general usability

Use typical users when confident

Assessment:

� Collect data


Experiment Design

Determine design� What you need to test

� Performance/ satisfaction etc

� How you will measure it� Data collection

Pilot experiments

Conduct experiments

The problem is:

Short term vs long term

Actual performance vs subjective views

Control of experiment

Etc etc.

What can we do:

Observe

Measure errors

Measure time to complete task

Debrief users:� Discussion

� Questionnaires

……….


Questionnaires – a quick way

to collect useful data

Personal data

� Domain expert?

� Technical expertise & experience

Subjective assessment

� Easy to use?

� Attractive?

� Things I liked

� Things I disliked

� Changes I would make

For each task:

� Was the task completed?

� How long?

� Any errors?

� If it was not completed:

� Why?

Try to use an existing questionnaire!


How to conduct usability testing

Produce a plan� Objectives

� What are you trying to evaluate?

� Identify focus

� Method� How will you conduct

it?

� How will you collect data?

� How will they be analysed?

Always pilot

Make it clear to user:

� Purpose

� Tasks


Lecture 9

User Interface Design

� Designing Systems that work for People

Summary

33


So how do I design?


Interface Metaphors

Interface metaphors combine familiar knowledge with new knowledge in a way that will help the user understand the product. Three steps: � understand functionality

� identify potential problem areas

� generate metaphors

Evaluate metaphors:� How much structure does it provide?� How much is relevant to the problem?� Is it easy to represent?� Will the audience understand it?

� How extensible is it?


Interaction Models

Which interaction type?� How the user invokes actions

� Instructing, conversing, manipulating or exploring

Do different interface types provide insight?� WIMP, shareable, augmented reality,

etc

� Initiative: System/User/Mixed


Construction

Taking the prototypes (or learning from them) and creating a whole

Quality must be attended to:

� usability, reliability, robustness, maintainability, integrity, portability, efficiency, etc.

Product must be engineered:

� Evolutionary prototyping

� ‘Throw-away’ prototyping


Design rules

Designing for maximum usability– the goal of interaction design

Principles of usability� general understanding

Standards and guidelines� direction for design


types of design rules

principles� abstract design rules

� low authority

� high generality

standards� specific design rules

� high authority

� limited application

guidelines� lower authority

� more general application increasing authority

incr

easi

ng g

ener

ality

Standards

Guidelines

increasing authority

incr

easi

ng g

ener

ality

34


Principles to support usability

Learnabilitythe ease with which new users can begin effective interaction and achieve maximal performance

Flexibilitythe multiplicity of ways the user and system exchange information

Robustnessthe level of support provided the user in determining successful achievement and assessment of goal-directed behaviour


Principles of learnability (1)

Predictability

� determining effect of future actions based on past interaction history

� operation visibility


Principles of learnability (2)

Familiarity� how prior knowledge applies to new system� Guess-ability; affordance

Generalize-ability� extending specific interaction knowledge to new situations

Consistency� likeness in input/output behaviour arising from similar

situations or task objectives


Principles of flexibility (1)

Dialogue initiative� freedom from system imposed constraints on input dialogue

� system vs. user initiative

Multi-threading� ability of system to support user interaction for more than one

task at a time

� concurrent vs. interleaving; multimodality

Task migrate-ability� passing responsibility for task execution between user and

system


Principles of flexibility (2)

Substitutivity

� allowing equivalent values of input and output to be substituted for each other

� representation multiplicity; equal opportunity

Customizability

� modifiability of the user interface by user (adaptability) or system (adaptivity)


Principles of robustness (1)

Observability� ability of user to evaluate the internal state of the

system from its perceivable representation� browsability; defaults; reachability; persistence;

operation visibility

Recoverability� ability of user to take corrective action once an

error has been recognized� reachability; forward/backward recovery;

commensurate effort

35


Principles of robustness (2)

Responsiveness

� how the user perceives the rate of communication with the system

� Stability

Task conformance

� degree to which system services support all of the user's tasks

� task completeness; task adequacy


[Standards]

Set by national or international bodies to ensure compliance by a large community of designers standards require sound underlying theory and slowly changing technology

Hardware standards more common than software high authority and low level of detail

ISO 9241 defines usability as effectiveness, efficiency and satisfaction with which users accomplish tasks


Guidelines

more suggestive and general

many textbooks and reports full of guidelines

abstract guidelines (principles) applicable during early life cycle activities

detailed guidelines (style guides) applicable during later life cycle activities

understanding justification for guidelines aids in resolving conflicts


Golden rules and heuristics

“Broad brush” design rules

Useful check list for good design

Better design using these than using nothing!

Different collections e.g.

� Nielsen’s 10 Heuristics

� Shneiderman’s 8 Golden Rules

� Norman’s 7 Principles


Shneiderman’s 8 Golden Rules

1. Strive for consistency

2. Enable frequent users to use shortcuts

3. Offer informative feedback

4. Design dialogs to yield closure

5. Offer error prevention and simple error handling

6. Permit easy reversal of actions

7. Support internal locus of control

8. Reduce short-term memory load


Norman’s 7 Principles

1. Use both knowledge in the world and knowledge in the head.

2. Simplify the structure of tasks.

3. Make things visible: bridge the gulfs of Execution and Evaluation.

4. Get the mappings right.5. Exploit the power of constraints, both

natural and artificial.6. Design for error.7. When all else fails, standardize.

36


[Users with disabilities]

These represent extreme cases – but can inform design for normal usersvisual impairment� screen readers, ALT tags

hearing impairment� text communication, gesture, captions

physical impairment� speech I/O, eyegaze, gesture, predictive systems (e.g. Reactive keyboard)

speech impairment� speech synthesis, text communication

dyslexia� speech input, output

autism� communication, education


… plus …

age groups� older people e.g. disability aids, memory aids,

communication tools to prevent social isolation

� children e.g. appropriate input/output devices, involvement in design process

cultural differences� influence of nationality, generation, gender, race, sexuality,

class, religion, political persuasion etc. on interpretation of interface features

� e.g. interpretation and acceptability of language, cultural symbols, gesture and colour


Summary

In this course we have introduced some of the issues of HCI & usability design

� It’s all about people!

� People in general

� The potential users of the system

� Attributes

� Goals & tasks

� Constraints


The user

The first step is to understand our users� What they can do

� What they want

Once this is done you can have some confidence in what you produce

The last step is to check whether you have done this right!


So ….. ?

Work with users upfront

� Identify requirements

� Build personas & scenarios� To help define

requirements

� To guide design

� To drive some evaluations

Build prototypes

� Alternatives

� Multiple stages

� Evaluate� Ideally with real users

� End users

� Non-typical users

� Against metrics

� Using personas to guide

Iterate, refine and go deeper

Evaluate at all stages

� As best you can

� It will always teach you something

Evaluate the final product

� Analytically

� Experimentally


Usability engineering

This methodology is typical of all engineering disciplines

It is a matter of maximising benefits and minimising costs

� Work within the constraints

� Create an explicit plan

Evaluation & testing is a central part of this

� Be clear about goal, method, data & analysis

� Feedback on requirements/designs/products

37


Is that it?

The point of having this type of methodology is:

� Work efficiently & cost effectively

� Provide space to be:

� Creative

� Imaginative

� Innovative

� Radical

HCI has several faces:� Engineering

� Creating new solutions as technologies and societies evolve� This provides a

framework where you can do that

http://www.youtube.com/watch_popup?v=AklKy2NDpqs#t=12http://www.youtube.com/watch_popup?v=Mgy1S8qymx0#t=73s

Introduction to HCI MSc Computer Sciencerjh/courses/IntroductionToHCI/2012-13/MScCS... · 1 1 MSc...

Documents

Transcript of Introduction to HCI MSc Computer Sciencerjh/courses/IntroductionToHCI/2012-13/MScCS... · 1 1 MSc...