introduction to hci msc computer science: 100%...

1

1

MSc Computer Science: Introduction to Human Computer Interaction

Bob Hendley

Room: 236, CS

MSc CS: Intro. to HCI 2016-17 2 2

Introduction to HCI

100% coursework Re-assessment by repeat

Classes: Monday 5:00

G29 Mech. Eng.

Thursday 10:00 G34 Mech. Eng.

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


First some motivation

……


The world is full of bad design …

Photo from Jacob Nielsen’s Alertbox June 7, 2004


…. And …


… and

2

MSc CS: Intro. to HCI 2016-17 7

What’s wrong with these?

Complex

Ugly

Non-intuitive & inconsistent

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!




… and many many more!


And sometimes good design …


And …












3


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


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?

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

4


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


HCI is changing..

Physical things

GUI interfaces

Collaborative interfaces

Internet technologies

Social technologies

Ubiquitous technologies

?


What’s the problem?

Slide idea by Bill Buxton

transistors speed

discs cost

1950 1990 2030

Computer

abilities Features

Productivity

Ease of use

1950 1990 2030

Promised

Functionality

1950 2030 2000BC

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

Design

…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


Can we master CS + Psychology, sociology, business, linguistics ……?

No! … but we can all learn things about people

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

Or

we can find out when we need to!

5


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

Computer Science

Psychology

…

Art

Engineering

Craft

….


… 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

So:

We’ll focus upon

methodologies for engineering good HCI

And not on theoretical or research in HCI


Human Computer Interaction, 3rd Edition Alan Dix, Janet Finlay, Gregory Abowd, Russell Beale Prentice Hall, 2004. ISBN 0-13-046109-1

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

28

Text:








Lecture 2

It’s all about people: Perceptual systems

What & how

Examples

Vision

Memory

Levels of information processing

Lessons for HCI


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

Is

Behaves

Feels





6


What makes up a person?

Body

Senses & perception

Memory

Behaviour

Thought


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 … brain etc.

Limitations – pitch, brightness, cycle time etc.

….. And there is the added complexity of

individual differences in sensory perception:

Between individuals

Over time


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

7


Some Examples


Connectedness

a b

c d


Symmetry


Closure

a

a b


Object interpretation


Foreground & Background

8


Contours

a

a

b


Transparency

a


Texture

a

ab

c d


85689726984689762689764358922659865986554897689269898

02462996874026557627986489045679232769285460986772098

90834579802790759047098279085790847729087590827908754

98709856749068975786259845690243790472190790709811450

85689726984689762689764458922659865986554897689269898


8568972698468976268976435892265986598655489768926989

0246299687402655762798648904567923276928546098677209

9083457980279075904709827908579084772908759082790875

9870985674906897578625984569024379047219079070981145

85689726984689762689764458922659865986554897689269898


Orientation

9


Motion


Shading


Faces/emotion …..


Length Width

Parallelism Curvature

Number Added marks Spatial grouping

Shape

Enclosure


An Example


Depth – seeing the 3D world

Many depth cues

Stereopsis

Occlusion

Sharpness

Accommodation

Contrast

Some will dominate others

In other cases, conflicts cause sickness

10


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

















Interference

Try naming the ink colour in first column

Then try the second!

The point is:

•when two cues work together,

then we process quickly

•When they conflict, then we are

slow and error rates increase

….and this applies across all

levels

11

MSc CS: Intro. to HCI 2016-17 61 MSc CS: Intro. to HCI 2016-17 62 62

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.


Impact on HCI

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

Grouping

Consistent cueing

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

We are complex!

Large individual differences Vision

Motor skills

Cognitive skills

There are model based tools that aim to predict performance

But they have limited scope For now!


Impact on HCI (2)

The examples we have looked at:

Are chosen because they are easily accessible

They are surprising and show the complexity of people and their processing and behaviour

But, these examples are mostly at a ‘surface’

level

There are big gains from using this knowledge:

Selection rather than specifying (I.e. recognition rather than recall)

Visual grouping and layout

Etc

Even more important is understanding the deeper and longer term factors

E.g. goals, motivations, affective states, usage scenarios and so on


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

Let’s look at people more deeply:

Memory & processing

Maslow’s Triangle

Case studies: Teaching

Behaviour change

Interruptions

Alarm clock

Lessons

http://www.youtube.com/watch?v=FWSxSQsspiQ&feature=player_embedded

http://www.youtube.com/watch?v=FWSxSQsspiQ&feature=player_embedded

12


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 – 70ms Short term storage – ~20 second decay time

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

Often referred to as ‘Working memory’


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 way events 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 ….


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.

http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two

13


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.


Maslow’s Hierarchy of needs


Maslow’s Triangle


Some Case Studies

Teaching

Behaviour change

Interruptions

Alarm clocks

Lessons?

14


What must we do?

If we want to build systems that help people in complex tasks:

Understand the tasks & the cognitive processes Build on research & practice

(these are often incomplete or conflicting!)

Build systems with a knowledge of these things

Test whether they work


(1) Systems that teach

How do people learn?

What is the best way to ‘teach’ people

Can we adapt the behaviour of a system to the abilities/traits & knowledge of an individual?

Does it work?


Models of Learning Style

The Felder/Silverman model classifies learners in 4 dimensions:


So:

Can we build a system which:

Builds a model of a students learning style?

Maintains a model of a students existing ‘knowledge’?

Adapts its teaching to an individual?

Does it work?


Results: Adapting teaching

based on a student

model (learning style

& knowledge):

•Improves

learning

•Short term

•Long term

•Increases

learner

satisfaction

LS+K > K

LS+K > LS

[Short & long term learning &

user satisfaction] MSc CS: Intro. to HCI 2016-17 84

(2) Behaviour change

Problem:

Many people would like to change their bad behaviours:

Addictions, health, fitness, mental health …….

Technology provides a potential route

How can we help:

There are many apps, websites …. But do they work?

What do we need to do to enable change?

What are the problems?

15


Draw upon research to build models to support change

Models (to draw upon) System1/System2

How do we change behaviour?

Habits How are they formed?

Changed? Removed?

Reactance Why? What causes it? How can

it be reduced? What influences it?

Priming How do we use/avoid it?

Triggers

Affective state

Activity

Etc.

Build technology that: Senses

Mobile ‘phone

Interprets raw data to information

Acts appropriately for: that user,

in that context,

at that time …


(3) Interruptions

Problem:

Our systems interrupt us:

Typically, people receive many hundreds of notifications on their ‘phone each day

This is disruptive!

Can we improve this?

Find appropriate: Time

Medium

Device

for each notification

Understand the value and cost of an interruption in different contexts adapt


What do we need?

Models of behaviour:

Interruptability

When should we interrupt?

Tasks

What is the user doing?

Goals

Etc.

Sense user state

Interpret interruption

Predict future states

Predict cost & value of interruption in current & future contexts

Determine best time, place, method to issue notification


(4) Smart Alarm apps

Problem: How can you build a better alarm?

Build an understanding of sleep patterns

When is the best time to awaken a person?

Build an app which:

Monitors users sleep pattern:

e.g. accelerometer, mic

Uses a window to define alarm time

Wakes user at best time in their sleep cycle


Summary

Sometimes we don’t need to be too clever, but:

We may need to understand: Models of perception, cognition,

behaviour: To guide good design

Understanding of User goals, tasks, capabilities etc.

Models of behaviour: Of different types

And what drives it

Drawing upon theories and models: possibly, across several

disciplines

We may need to build systems which:

Sense

Interpret, reason, infer, learn

Act appropriately

We always need to understand user

Check whether they work:

And possibly fix them

underlying knowledge


Lecture 4

Coursework:

Motivation: ATM

Groups

Coursework Specification

Assessment

16


ATM/Cash Machine

Surely, this is a trivial interface to get right!

User Goals? Cash before card!

Ergonomics

Data entry <enter>

Buttons/touch screen

Consistency

Requirements

Etc.


A B C D E

Success Rate 90.9 90.9 95.0 92.3 80.0

No. of Clicks 29.1 25.8 24.6 27.4 30.9

Time 63.9 59.2 56.3 57.9 72.0

Satisfaction 4.29 4.16 4.44 4.14 3.97

Difference 22.1 8.81 14.8 11.7 27.4

ATM: Empirical studies This study compared

performance with 5 banks’ ATMs:

Large variation in performance:

Error rate

Time taken

Satisfaction

And also, large variation between users!


Lectures 5, 6 & 7

Design Alternative models

Where is the focus?

UCSD (User Centred System Design)

Personas

Scenarios

93 MSc CS: Intro. to HCI 2016-17 94 94

Understanding the Design Process

What is the design 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 1. Designers: understand

requirements and explore, design, evaluate and refine solutions

2. Implementers: 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

overall cost

The better the solution

So: Focus on

understanding users & 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 the requirements

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)

17


Efficient Development..

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

(users?)

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


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 [or administrator, manager …], find interesting?

How do I (the developer) see the system?

This is

what you get!

System centred: not just

technology centred


User Centred …

Design is focused upon the users:

Abilities and real needs

Not just what you hope or imagine they are

Context

Work

Tasks

Values

….

18


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 Centred Design

Values: Value / Worth Centred Design


User Centred [System] Design

Focus on: the people who will use the system

their requirements

their preferences

Building models of: Users

Tasks

Systems

This is usually:

An iterative process

That involves:

Prototyping and Evaluation with (and without) users

Descriptive models that

build an understanding


UCD


Core Concepts in UCD

Early stages User models

Task models

Context

But also on Goals

Values

Prototyping, evaluation, refinement ….

Later stages?

Inclusive Design

Design for all

Universal Access


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


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

19


Video here….

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


Tasks (and Goals)

Tasks

What is the user trying to do with the system?

Not all systems are task based (eg. Games, SNS)

Not all tasks can be easily specified

Goals Irrespective of the user

tasks, there can be conflicting or complementary goals Interruptions

To have fun?

Do something else

So, these may constrain time, engagement, motivation ….


Context

Where will the system be used?

Quiet office, busy train, outside ….

What sort of technology will be deployed?

Desktop, tablet, kiosk ..

Will the users be able to get any help?

Will they receive training?

All these constrain the space of designs


Values

What matters to the user?

Motivation, accuracy, speed, satisfaction…

What is important in the context?

What are the business concerns?


Lecture 6

Models of Users

… It’s all about empathy… Personas

Scenarios

The point is: It’s all too easy to forget:

Who the user is

What motivates them

What they are trying to do


Warning!!!

This section might seem very …..

But it works!

(if you engage with it)

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

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

20


Personas & Scenarios

Purpose:

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

Of the way they will use it

And use these to:

To guide the design process

To guide the evaluation of designs

Methods:

Aim for good coverage of usage: Balance cost/value

(Ideally) Informed by real (potential) users Interviews, observations

etc.: This is hard to do

properly

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.

… but also from insight


The Power of Personas

The personas are given realistic:

Names

Faces

Personalities

to foster user empathy within a design team.

As well as driving design:

Personas & their scenarios can be used later to:

evaluate prototypes

and the final product

A critical element of personas:

beyond capturing typical user attitudes & 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.


An example Persona template


An example Persona The point is to build a

‘picture’ of the user:

•So that you can put

yourself in their place

21


And another


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

We are interested in:

The users’ behaviour

What they want to achieve

Not the details of how they achieve it (I.e. not keystrokes, menu selections etc.)


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 shared understanding of the end users for the entire design team.


Scenario: example

Steve 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 the details in his diary. He needs his wife to have the details so that she knows what he is doing and, maybe, can ferry him to/from the station.

2. Steve lives in Stratford and wants to compare the options for tickets for his commute to Birmingham. He usually travels 4 days and either travels away or works from home the other day. He wants to keep costs down but needs flexibility.

3. On Sunday, Steve wants to take his family 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. His total for 2+2 is £120.

4. Steve needs to attend a meeting at 9:30 in central Paris on Monday. He would like to spend some time exploring the city. He wants to minimise his CO2 footprint but he also has a tight budget. He does not want to be away more than one night


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

Remember, this is about what the user wants to achieve not how they do it.

22

MSc CS: Intro. to HCI 2016-17 127 MSc CS: Intro. to HCI 2016-17 128

An example – open diary

system

Who are the users?

What are they trying to do?


An example – open diary

system

Who are the users?

What are they trying to do?

For instance, consider:

Students, lecturers, salesman, retired person ….

Privacy & security

Devices & synching

Anniversaries

Regular appointments

Types of appointments hard soft

Movable/fixed

Location

etc. etc.

When to notify: Anniversary, meetings (travel,

prepare ..)

You only identify these

issues by:

•Analysing existing systems

•Considering concrete

usage by concrete people


Some Examples

Here are some examples of personas. See

www.fluidproject.org

Here are some examples of personas. See

www.fluidproject.org


Further Work

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


Summary

Personas & scenarios are excellent ways to:

Focus on the users

Their context, motivations, goals, tasks, constraints etc.

Share & validate understanding of users

Undertake early stage testing

It’s really important

(and effective) to capture a lot of ‘soft’

information

Focus on the user’s

goals & tasks

Not on how they might use the system

Identify, archetypal users

http://www.fluidproject.org/

http://www.fluidproject.org/

23


Lecture 8

Tutorial

Review problem specifications

Tutorial with groups


Lecture 9&10

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.


Prototypes may serve different purposes


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 potential designs

To understand technology

…..

Make mistakes early and cheaply!

24


Methodology for prototyping

Iterative

Usually several stages of prototyping

Parallel

Consider alternative solutions

May have several orthogonal strands of prototyping

E.g. Cars: body, interior, drivetrain ….

Software: UI, DB, Logic ….

Evaluate each prototype

Be clear about the purpose

Minimise cost

Time

Effort

Only do what is necessary to meet goals


What do we mean by a HCI Prototype?

It can be (among other things):

a paper-based screen design

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

An animated slide show

With interaction

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 A very important aspect of design

Prototypes answer questions

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

Rather than the routine

….


Lo-Fi Prototyping

Uses a medium which may be unlike the final medium

e.g. paper, cardboard, photoshop …

It is quick, cheap and easily changed/binned

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

No implementation skills Allows non-programmers to participate

Widely used in industry

25

Paper-based prototypes


Later we can produce a more hifi version

It may be MUCH easier to draw


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


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

Evaluate

against Persona

& scenarios


Generating Storyboards

26


Storyboard used to generate prototype


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

Focus prototype where there is value

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

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

27


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!


Summary

Different kinds of prototyping are used for different purposes and at different stages Prototypes answer questions so prototype appropriately and be clear why you are

building it

Construction: the final product must be engineered appropriately Conceptual design (the first step of design) Consider interaction types and interface types to prompt creativity

Storyboards can be generated from scenarios Card-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

159 MSc CS: Intro. to HCI 2016-17 160 160

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-PrntScrn captures the active window into

the clipboard Mac OSX Grab Utility Android

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

28


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


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


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 11&12

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 the system is (possibly, for different user groups):

So it can be improved

To identify good and bad features:

to inform future design

To understand what makes a good interface

To understand principles, science, behaviour …


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!














http://www.istartedsomething.com/20071018/

http://www.istartedsomething.com/uploads/toolkit_0_2.pptx

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

http://www.istartedsomething.com/20071018/powerpoint-prototype-toolkit-01/














http://www.istartedsomething.com/20071018/

http://www.istartedsomething.com/uploads/toolkit_0_2.pptx

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

http://www.istartedsomething.com/20071018/powerpoint-prototype-toolkit-01/

29


Unit testing Integration

testing

Alpha testing

Prototype1 prototypen Product

Development process

So, we have an iterative process:

•Identify purpose

•Design prototype

•Build

•Evaluate

•Learn lessons


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


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!


Requirements for evaluation

Be clear what you want to learn: Focus on important

parts of design

Focus on important aspects of design

Devote appropriate resources

Make lessons explicit

For instance:

Aircraft display: Low error rates, efficient

Learnability, memorability & satisfaction are less important

Ecommerce site: Learnability, satisfaction,

memorability are crucial

Error rates, efficiency are less critical


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


Planning evaluations

It’s critical to decide,

upfront:

What attributes are important:

Their relative importance

E.g. learnability > efficiency > error rates

For instance, compare a flight booking system:

For travel agents

For end-users

30


Cost of evaluations

In early stages, evaluations must be:

Fast

Cheap

And they don’t need to be perfect

[We’re evaluating prototypes!]

For the final product:

Effectiveness, reliability, completeness are more important

So, we’re prepared to spend more time and effort


Inspection Methods

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

179

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%


# Evaluators 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% 72%

31


Why do this?

We need to understand the performance of our prototypes:

To fix them

To guide decisions

However:

A full experimental evaluation would be too expensive & take too long

The system is, in any case, incomplete & ‘rough’

So, use methods that are good enough & quick enough: This applies even when the

system is finished: catch ‘obvious’ errors

fix

Then test rigourously


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



Show what the system is doing:

How long it will take

What mode it is in

Make it clear when the system is waiting for user action

…..

searching database for matches

32


Aside: What is “reasonable time”?

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

needed. But not for some things!

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 (for instance) %-done progress bars.


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

For instance, don’t use

language that you

cannot accept as input:

•Mirroring



Guidance is useful, but don’t over constrain:

Allow flexibility

Don’t force users to take a particular path:

e.g. Provide (useful) exits for mistaken choices Don’t force abort & restart

Enable:

undo

redo


4. Consistency and standards


5. Error prevention

People will make errors.

Design to prevent/reduce them:

How might you go about trying to prevent errors?


5. Error prevention

People will make errors.

Design to prevent/reduce them:

How might you go about trying to prevent errors?

Menus

Grey out invalid choices

Radio buttons

Calendar popups

E.g flights to Birmingham, Lagos …..

33



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 file list

…..


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


Remember ….

Not all heuristics will be, necessarily, relevant

Different applications will have different priorities

Some of these dimensions will conflict

So, we need to be clear about:

Who the users are

Their context

Their motivation

….

… and drive

evaluation accordingly

34


We should wonder…..

Is this a sensible heuristic set?: Coverage

Uniqueness

Ease of use

There are others: Some focused on a domain

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:

Impact

Frequency


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

much better 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!

35



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



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


Problems found by multiple evaluators

Where is the best cost/benefit?

Obviously, this

is case

dependent!


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

Scenario driven: 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

36


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. They’re as good as the evaluators

Using multiple analysts results in an inter-subjective synthesis. However, this also

a) raises the false alarm rate, unless (e.g.) 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:

Aspect Issue Severity Recommendation

System status

The ….

The …

0

5

Not an issue

Modify …

Match with real world

Also see:

•http://comminfo.rutgers.edu/~aspoerri/Teaching/InfoVisOnline/HEte

mplate.doc

•http://www.uxforthemasses.com/blog/wp-content/uploads/2011/02/Usability-review-template.xls


Summary

Inspection methods:

Can be very effective: They will catch many

problems

They are ‘cheap’ Quick, easy to undertake

They don’t require end-users

Find, say, 80% of problems quickly and cheaply Then devote other

methods to the harder problems

Using multiple evaluators improves coverage

Using personas & scenarios helps to focus on end-user needs

Works with early stage prototypes

Inform design decisions


Lecture 15

Usability Testing:

Motivation

To find problems

Methodologies

Data collection

Data analysis

Controlled experiments:

Experimental design

Participants

Variables

Data collection

Data analysis

interpretation


Usability Testing

Remember:

Inspection methods can identify problems:

Quickly

Cheaply

But they won’t find

everything!

Usability testing is:

Empirical testing

With users

To find usability problems

So they can be fixed

Compare with Software testing (e.g. alpha, beta …. testing)

http://comminfo.rutgers.edu/~aspoerri/Teaching/InfoVisOnline/HEtemplate.doc

http://comminfo.rutgers.edu/~aspoerri/Teaching/InfoVisOnline/HEtemplate.doc

http://www.uxforthemasses.com/blog/wp-content/uploads/2011/02/Usability-review-template.xls







37


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 test, 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

(Typically) 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(er)

Will uncover many problems


Problems with formal (controlled) 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!


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!


Usability testing

Remember the purpose is to find problems:

So they can be fixed

Issues:

Who are the users?

Where & how is the testing done?

What data do we collect?

What do we do with the results?

38


Who are the users?

In early stages we will use atypical users: Students

Volunteers

Colleagues

And so on …

[But we still want them as typical, balanced etc. as possible]

And in artificial circumstances

Later:

Typical users

In realistic settings


Where and how?

In early stages:

In a (probably) non realistic setting

Use a script to define the context:

From user scenarios

Typically, short term use

Later:

Seek realistic usage

Move to a realistic environment

User takes initiative from environmental cues

Longer time scales

‘in the wild’ studies


Data

What is important?

Objective data:

Time taken, error rates, usage patterns and so on

Subjective data:

Is the user happy?

What were they thinking:

Mental model

Problems

The system can:

Log data:

Key strokes, mouse events, timings data

Video

Possibly with detailed analysis & annotation

Debrief/interviews

Questionnaires


Think Aloud

Often what the user is thinking is critical:

What is their ‘mental model’

Why did they do that?

What are they looking for

Some methods used:

Ask user to explain what they are doing as they do it:

Changes behaviour

Debrief/interview them afterwards

Using video of their usage

[Erikson & Simon 1985]


Eye tracking

Where is the user looking and when?

Screen design

Movement around screen:

Searching, reading etc


Questionnaires – a quick way

to collect useful data

Personal/demographic data Domain expert?

Technical expertise & experience

Age, sex, impairments etc

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!

• Why?

39


Why use an existing Questionnaire

It’s easy to create a

questionnaire

Paper

On-line e.g. survey monkey

It’s hard to create a

useful one

Existing questionnaires are:

Trialled and validated

The interpretation of the results is understood

You can augment an existing tool by adding to it:

At the end.


System Usability Score (SUS)

To calculate the SUS score

first sum the score contributions from each item. Each item's score contribution will range from 0 to 4.

For items 1,3,5,7,and 9 the score contribution is the scale position minus 1.

For items 2,4,6,8 and 10, the contribution is 5 minus the scale position.

Multiply the sum of the scores by 2.5 to obtain the overall value of SU.

SUS scores have a range of 0 to 100.

http://www.usabilitynet.org/trump/documents/Suschapt.doc


Computer System Usability Questionnaire

http://oldwww.acm.org/perlman/question.cgi?form=CSUQ


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

Make conclusions/lessons

explicit


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

Identify lessons!!!!


Overall lessons

Think, define objectives, plan, analyse

Load effort towards early stages Inspection methods

Atypical users

Real usage

Catch errors as early & cheaply as possible Only use more expensive methods when you are

confident

Be honest & learn lessons Remember, you are doing this to find problems!

40


Lecture 16

Controlled Experiments


Controlled experiments

This is concerned with empirical evaluation of system use by users.

A more scientific study with controlled conditions:

Users

Variables

Statistical analysis

Interpretation of results

Define objectives

Define hypotheses? What are we trying to do?

Uncover problems?

Reliably compare conditions?

Etc.

Define scope, focus, objective of evaluation

Design experiment

Conduct experiment: Collect data

Analyse data

Draw conclusions


Experiment Design

Determine design: What you need to test:

What is the research question?

Performance/ satisfaction etc

This leads to a set of hypotheses

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.

Pre-study data collection

In-study data collection:

Observe

Think-aloud

Track

Post-study data collection

After each condition

At the very end


Hypotheses

You cannot really draw conclusions unless you are clear, in advance, what you are trying to

test.

Define hypothese e.g.

H1: in condition 1 users will complete their task faster than condition 2

H2: in condition 1 users will be more satisfied with the system than in condition 2

H3: in condition 1 the user will learn more than in condition 2


Experimental Conditions

Typically we want to establish: 2 or more experimental

conditions This defines the

independent (or controlled) variables

E.g. interface 1 or interface 2

As far as possible, the two conditions should be identical Except for the defined

point of variation

The dependent (or measured) variables are the things that we expect to measure (the effects). E.g. Speed

Effectiveness

Error rate

And so on


Users

Users are a major point of variation

Because they vary!

Subjects:

Between subjects

Each user experiences only one condition

Within subjects

Each user experiences each (or several) conditions

41


Within Subjects

This reduces variation:

Because the user is the same between conditions

But there could be

ordering and other confounding effects

Counterbalancing helps to reduce this effect:

User 1: C1 C2

User 2: C2 C1


Between subjects

Each user only experiences one condition:

No carry over effects

Cannot directly compare C1/C2 for an individual

Large individual variation

Balance users in each condition:

Age, sex etc

Pre-test scores

To try to have comparable populations in each condition


Other things to watch out for

Experiments with people are very difficult:

Individual variations

Biases

e.g.

Blind, double blind, triple blind studies

Why must all clinical trials be registered beforehand?

Hawthorn effect

Placebo effects

………


Data

As with usability testing:

Time to complete task

Error rate

Questionnaires Satisfaction

Others

Etc.

What can we do:

Observe But in an objective way

Measure errors

Measure time to complete task

Measure achievement What is the objective of

system? Change behaviour? Change

attitudes? Learn something?

Debrief users: Discussion

Questionnaires

……….


Data analysis

We have to undertake a (sensible!) statistical analysis of the data:

Driven by the hypotheses

Then we can (possibly):

Conclude that the hypotheses are true

At a certain confidence level

Of course, the important thing is:

The interpretation that you put on the results:

Assumptions

Limitations


Summary

Usability testing aims to find problems

Controlled experiments aim to answer a question: This may be a scientific

question or just a comparison between two interfaces.

They are hard (and expensive) to design and undertake.

They, typically, answer small, detailed questions

There are many pitfalls in designing, undertaking and interpreting these experiments.

See: www.nejm.org/doi/ful

l/10.1056/NEJM1991

04043241418

http://www.nejm.org/doi/full/10.1056/NEJM199104043241418



42


Lecture 17 & 18

User Interface Design Designing Systems that work for People

Important ideas in design: Metaphor

Interaction model

Affordances

What is important to guide your design: Principles

Guidelines

Standards


So how do I design?


Remember: criteria

Learnability

Efficiency

Memorability

Error rates/reliability

Satisfaction

We want to:

Maximise all of these

They often conflict

So:

Balance is problem specific


Designing for usability

Most of this is easy to dismiss as ‘common sense’

….. But many designers do not do this!

There is a ‘craft skill’ here

But look at examples, guidelines etc. To learn how to do it:

Compare to good software design!


Some important ideas

Interface metaphors

Where does the dialogue initiative lie?

Affordances


Interface Metaphors

Interface metaphors combine familiar knowledge with new knowledge in a way that will help the user understand & use the system:

Build a consistent mental model of system.

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?

So, we have obvious examples like:

Desktop

Video controls

Filing systems

Touch controls

These build on our existing knowledge to allow us to predict how the interface will work

Without having to explicitly

learn

43


Examples


UI Metaphor

Aim to build on existing knowledge

Easy to learn & predict behaviour

Compare:

Metaphor

Skeuomorphism

Analogy

Metonymy

Consider a slider for volume control:


Metaphors: summary

Using a metaphor is a good idea:

Improves learnability & memorability

Can improve performance

Can build on known good design

Dangers:

Metaphor is incomplete/breaks down:

Trash can

Conflicting cues

Bad slider!

May not work for all users

Can maintain inefficient use:

VR, search …


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

Think about what model is right:

Should the system always structure the dialogue?

Should the user have complete freedom to do what they want?


Affordances

A common principle across all design disciplines

Make it obvious what to do and what is possible:

No need to learn

Architects (e.g.) apply this:

Door handle vs door plate

Buttons, knobs, sliders …


44


Affordances

Like with metaphors, this builds upon people’s intuitions:

They show what is possible

They cue behaviour

Can improve learnability & performance

Conflicting affordances & unfilled affordances have a negative effect


Summary

All these can improve performance

If used properly

They can also be used to feedback the result of actions

Metaphors & affordances can be:

At various levels of abstraction


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


How can we do this?

Principles

Guidelines

Standards

Examples:

Nielson

Shneiderman

Norman


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

guidelines lower authority

more general application

standards specific design rules

high authority

limited application increasing authority

inc

reas

ing

gen

era

lity

Standards

Guide lines

increasing authority

incre

asin

g g

en

era

lity

45


Principles to support usability

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

Flexibility the multiplicity of ways the user and system exchange information

Robustness the level of support provided to 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 and design metaphors & affordances

operation visibility

You can see what you might do (e.g. menu options with inappropriate options ‘greyed out’)


Principles of learnability (2)

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

Generalize-ability

extending specific interaction knowledge to new situations E.g. carry across from parts of this or other systems

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 E.g. delegate task to system (spell check?)


Principles of flexibility (2)

Substitutivity

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

E.g. different (but equivalent) input/output formats

Different ways to perform the same task

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 Browse-ability; defaults; reach-ability; persistence;

operation visibility I.e. see what is going on without changing anything

Recoverability

ability of user to take corrective action once an error has been recognized

forward/backward recovery

46


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, international bodies or manufacturers 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


Nielsen's Heuristics


2. Match between system & real world


4. Consistency & standards

5. Error prevention


7. Flexibility & efficiency of use

8. Minimalist design

9. Help error recovery

10.Help & documentation


Shneiderman’s 8 Golden Rules

1. Strive for consistency:

• Make sure that menu structures, terminology, actions etc. are consistent

2. Design for all users:

1. Support novice users: • E.g. tool tips

2. Enable frequent users to use shortcuts:

• Allow expert users to work more quickly: keyboard accelerators, macros etc.

3. Offer informative feedback:

• Make sure state is clear and provide feedback on actions

4. Design dialogs to yield closure:

• Organise actions with a clear structure and signal completion

5. Offer error prevention and simple

error handling:

• Aim to prevent errors, if they

happen then detect & signal and

offer a way forward

6. Permit easy reversal of actions:

• Undo, redo etc

7. Support internal locus of control:

• Give control & flexibility to user –

let them think they are in control!

8. Reduce short-term memory load:

• Keep it simple: reduce context

switching, display as much as you

can …

47


Norman’s 7 Principles

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

• Understand the user’s conceptual model and build to match that

2. Simplify the structure of tasks.

• Make it obvious what is going on, give feedback …

3. Make things visible: • Make functions, options,

state etc. visible to user

4. Get the mappings right: • For instance build on a

metaphor

5. Exploit the power of constraints, both natural and artificial:

• Make it easy to do it right and hard to do it wrong

6. Design for error: • Try to reduce the chances of

errors – but if they happen help recovery (e.g. undo)

7. When all else fails, standardize.

• At the very least, design consistently and follow guidelines or standards.


Summary

These heuristics are useful: To guide design

To evaluate designs

They have different origins: Analysis of usability

problems – Nielsen

Experience – Shneiderman

Human behaviour - Norman

If you use these (in some way) you will produce better designs

Remember, these are often conflicting:

So, explicitly think about where the balance should lie

Draw upon these rules, as appropriate


Lecture 19

Guest Lecture

Paul Englefield

[Slides]

Paul is a consultant usability engineer. Most recently at IBM providing consultancy services to corporate clients.

Paul will present some case studies of the work they have undertaken and will relate this back to methodologies, tools and techniques and also the challenges and obstacles that are faced.


Lecture 20

Guest Lecture

Charlie Pinder

[Slides]


Lecture 21

Guest Lecture

Andrew Howes

[Slides]


Lecture 22

Special cases

Disabilities

‘special’ users

Special Environments

Novel & emerging interaction methods

http://www.cs.bham.ac.uk/~rjh/courses/IntroductionToHCI/2016-17/PaulEnglefield.pdf

http://www.cs.bham.ac.uk/~rjh/courses/IntroductionToHCI/2016-17/Andrew Howes.pdf

48


Special cases

Disabilities: Physical

Perceptual

Cognitive

Mental state Tiredness, anxiety etc.

Cultural Differences Language, culture

Age Groups: Children vs Adults vs

Elderly

These are not really special cases:

They can also inform design for ‘typical’

users


Users with disabilities

These represent extreme cases – but can inform design for normal users visual impairment screen readers, ALT tags, braille output

etc.

hearing impairment text communication, gesture, captions

physical impairment speech I/O, eyegaze, gesture, predictive

systems https://www.youtube.com/watch?v=0d6yIquOKQ0

speech impairment speech synthesis, text communication

dyslexia speech input, output

autism communication, education

Goal: Allow all users to have

access to software, information, tools

Consider: Users with no/slow data

connections/small screens/driving …

Noisy environments

Hands free situations – surgeons/lab. Workers ….

The clarity of language

….


… 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


Potential Applications

There are many ways in which technology can help users: Directly overcoming

obstacles

Enabling communication, participation etc.

Sensing & inferring

Applications: Assistive technology

Overcome physical, sensory & cognitive limitations

Medical Sense biometric

features & infer state Physical and other

Social Enable interaction


Some examples

Sensing & prediction

Gesture input

Brain Computer Interfaces


Sensing

We collect data:

Directly through computer mediated communication, typing

Wearables Including ‘phones

Cameras, microphones

Special devices

These can be used to infer:

Physical state

Affective states: Moods, emotions etc.

[Build models of user]

And predict: Behaviour

Goals, desires

… and therefore build better systems

Adapt the system ….Or to design

interventions To change behaviour

https://www.youtube.com/watch?v=0d6yIquOKQ0

https://www.youtube.com/watch?v=0d6yIquOKQ0

49


Handsfree use

There are many cases where users cannot use convention interaction devices:

Sterile environments

Operating theatres

Food preparation

Remote operation:

Vehicles

Construction equipment

Gesture control is one way in which this can be addressed:

https://www.youtube.com/watch?v=f5Ep3oqicVU


Brain Computer Interfaces

What if a user is profoundly disabled?

What if gesture is impractical?

BCI can be used as:

An input device:

External

Implants

As an output device:

To stimulate parts of the brain

Visual

Aural

others


Brain Computer Interfaces: Control

Uses a headset to measure brain activity

Interprets data into commands

Controls external device (robot)

Or wheelchair, assistive robot ….

https://www.youtube.com/watch?v=0d6yIquOKQ0?v=xhrmjsjK0pU


Brain Compter Interfaces: Evaluation

This can be done at different levels:

Motor

Cognitive

Affective

Could allow control of:

Wheelchairs

Aircraft

etc

Reliability is an issue Training &

inaccuracy

Distractions

Safety critical situations

Cognitive load High levels of

concentration are needed


Lecture 21

Summary

Understand (some of) the way people work

Process of design

Understand user

Create (potential) solutions

Evaluate

Future

Conventional systems are still important

Ubiquitous computing On people’s terms


HCI Design

In this course we have introduced some of the issues of HCI & usability design (and, especially, a process for designing good systems) It’s all about people!

People in general

The potential users of the system Attributes

Goals & tasks

Constraints

[and many other things]




https://www.youtube.com/watch?v=xhrmjsjK0pU

https://www.youtube.com/watch?v=xhrmjsjK0pU

50


The user

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

What they want

Their tasks, constraints, motivations etc

Once this is done you can have some confidence in what you produce Prototype, check …. Catch mistakes and iterate

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

Lessons!


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


Note

We have looked at some techniques: For the overall

process

For understanding users

For designing & building systems

For evaluating systems

There are many other techniques that can be used:

For different purposes

In different contexts

With different objectives

[and some we haven’t

looked at e.g. cognitive modelling]


Looking Ahead

HCI started as a discipline to facilitate people using computers:

This is still important

It has always been multidisciplinary

Now we have systems which are becoming:

Ubiquitous

Invisible

So the interaction is on people’s terms

… and these systems

can provide insights into how people work

51


Looking Ahead (2)

Systems have increasing amounts of data about users (think Google!): These can be used

to build models of the user

The system can adapt based on these models

So we can:

Have new applications:

Behaviour change, care, environment, entertainment …

Change the way we perform existing tasks

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

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

So we can:

Have new applications:

Behaviour change, care, environment, entertainment …

Change the way we perform existing tasks


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


The End.





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











introduction to hci msc computer science: 100%...

Documents