IM2044 – Week 6: LectureDr. Andres Baravalle

1

Interaction design

• The next slides are based on the companion slides for the textbook

• By the end of this week, you should have studied all chapters of the textbook up to chapter 10

• Today we will covering chapters 9-10.

2

3

Overview

• What is Interaction Design?– Importance of involving users– Degrees of user involvement– What is a user-centered approach?

• Some practical issues:– Who are the users?– What are ‘needs’?– Where do alternatives come from?– How do you choose among

alternatives?

4

What is Interaction Design?

• It is a process:– A goal-directed problem solving activity informed by

intended use, target domain, materials, cost, and feasibility

– A creative activity– A decision-making activity to balance trade-offs

• Four approaches: user-centered design, activity-centered design, systems design, and genius design

5

Importance of involving users

• Expectation management – Realistic expectations – No surprises, no disappointments– Timely training– Communication, but no hype

• Ownership – Make the users active stakeholders– More likely to forgive or accept problems– Can make a big difference to acceptance and

success of product

6

Degrees of user involvement

• Member of the design team– Full time: constant input, but lose touch with

users– Part time: patchy input, and very stressful– Short term: inconsistent across project life– Long term: consistent, but lose touch with

users• Dissemination devices, as newsletters

– Reach wider selection of users– Need communication both ways

• User involvement after product is released• Combination of these approaches

What is a user-centered approach?• User-centered approach is based on:

– Early focus on users and tasks: directly studying user characteristics (cognitive, behavioural, anthropomorphic & attitudinal)

– Empirical measurement: users’ reactions and performance to scenarios, manuals, simulations & prototypes are observed, recorded and analysed

– Iterative design: when problems are found in user testing, fix them and carry out more tests

7

Interaction design activities

• Establishing requirements

• Designing alternatives

• Prototyping

• Evaluating

8

A simple interaction design lifecycle model• Who are the users?

• What do we mean by ‘needs’?

• How to generate alternatives

• How to choose among alternatives

• How to integrate interaction design activities with other models?

9

Who are the users/stakeholders?• Not as obvious as you think:

– Those who interact directly with the product– Those who manage direct users– Those who receive output from the product – Those who make the purchasing decision – Those who use competitor’s products

• Three categories of user (Eason, 1987): – Primary: frequent hands-on– Secondary: occasional or via someone else– Tertiary: affected by its introduction, or will influence its

purchase

10

Who are the stakeholders?

11

Check-out operators

CustomersManagers and owners

• Suppliers• Local shop owners

What do we mean by ‘needs’?• Users rarely know what is possible• Users (typically) can’t tell you what they ‘need’ to help

them achieve their goals • Instead, look at existing tasks:

– Their context– What information do they require?– Who collaborates to achieve the task?– Why is the task achieved the way it is?

• Envisioned tasks:– can be rooted in existing behaviour– can be described as future scenarios

12

How to generate alternatives

• Humans stick to what they know works– Considering alternatives is important to ‘break out of

the box’

• Designers are trained to consider alternatives, software developers generally are not

• How do you generate alternatives?– ‘Flair and creativity’: research and synthesis – Seek inspiration: look at similar products or look at

very different products

13

How to choose among alternatives• Evaluation with users or with peers, e.g.

prototypes• Technical feasibility: some not possible• Quality thresholds: usability goals lead to

usability criteria set early on and check regularly– Safety: how safe?– Utility: which functions are superfluous? – Effectiveness: appropriate support? task coverage,

information available– Efficiency: performance measurements

14

15

How to choose among alternatives

Test the alternatives!

How to integrate interaction design in other models?• Agile software development is one option:

– Have development and design running in separate tracks

– Maintain a coherent vision of the interface architecture

16

Software requirements: what, how and why

17

• What:1. Understand as much as possible about users, task, context2. Produce a stable set of requirements

• How:Data gathering activitiesData analysis activitiesExpression as ‘requirements’All of this is iterative

18

Software requirements: what, how and why (2)

•Why:Requirements definition: the stage where failure occurs most commonly

•Getting requirements right is crucial

19

Volere shell

Volere requirements template

20

Establishing requirements

21

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

completion, re-scoping• Input: requirements document (maybe) • Output: stable requirements

• Why ‘establish’?• Requirements arise from understanding users’

needs• Requirements can be justified & related to data

22

Different kinds of requirements• Functional:

—What the system should do—Historically the main focus of requirements activities

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

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

23

Different kinds of requirements (2)Environment or context of use:

— Physical: dusty? noisy? vibration? light? heat? humidity? …. (e.g. OMS insects, ATM)— Social: sharing of files, of displays, in

paper, across great distances, work individually, privacy for clients— Organisational: hierarchy, IT department’s

attitude and remit, user support, communications structure and infrastructure, availability of training

24

An extreme example

25

Different kinds of requirements (3)

• Users: Who are they?— Characteristics: ability, background, attitude to computers— System use: novice, expert, casual, frequent— Novice: step-by-step (prompted), constrained, clear information— Expert: flexibility, access/power— Frequent: short cuts— Casual/infrequent: clear instructions, e.g. menu paths

What are the users’ capabilities? • Humans vary in many dimensions:

– Size of hands may affect the size and positioning of input buttons

– Motor abilities may affect the suitability of certain input and output devices

– Height, if designing a physical kiosk – Strength - a child’s toy requires little strength to

operate, but greater strength to change batteries– Disabilities (e.g. sight, hearing, dexterity)

26

Kinds of requirements

27

• What factors (environmental, user, usability) would affect the following systems?• Self-service filling and payment system

for a petrol (gas) station• On-board ship data analysis system for

geologists searching for oil• Fashion clothes website

Personas (stereotypes)

• Capture user characteristics– Not real people, but synthesised from real

user characteristics– Should not be idealised– Bring them to life with a name, characteristics,

goals, personal background

• Develop multiple personas

28

Personas

29

Data gathering for requirements

30

Interviews:— Props, e.g. sample scenarios of use,

prototypes, can be used in interviews— Good for exploring issues — But are time consuming and may be

infeasible to visit everyoneFocus groups:

— Group interviews— Good at gaining a consensus view and/or highlighting areas of conflict— But can be dominated by individuals

Data gathering for requirements (2)

31

Questionnaires:— Often used in conjunction with other

techniques— Can give quantitative or qualitative data— Good for answering specific questions from

a large, dispersed group of people

Researching similar products:— Good for prompting requirements

Data gathering for requirements (3)

32

Direct observation:— Gain insights into stakeholders’ tasks — Good for understanding the nature and

context of the tasks— But, it requires time and commitment

from a member of the design team, and it can result in a huge amount of data

Indirect observation:— Not often used in requirements activity— Good for logging current tasks

Data gathering for requirements (4)

33

Studying documentation: — Procedures and rules are often written

down in manuals — Good source of data about the steps

involved in an activity, and any

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

getting background information— No stakeholder time, which is a limiting

factor on the other techniques

Problems with data gathering (1)• Identifying and involving stakeholders:

users, managers, developers, customer reps?, union reps?, shareholders?

• Involving stakeholders: workshops, interviews, workplace studies, co-opt stakeholders onto the development team

• Getting ‘real’ users, not managers:traditionally a problem in software engineering

34

Problems with data gathering (2)• Requirements management: version control, ownership• Communication between parties:

– Within development team– With customer/user– Between users… different parts of an organisation

use different terminology• Domain knowledge distributed and implicit:

– Difficult to dig up and understand– Knowledge articulation: how do you walk?

• Availability of key people

35

36

Problems with data gathering (3)•Political problems within the organisation•Dominance of certain stakeholders•Economic and business environment

changes•Balancing functional and usability

demands

Some basic guidelines

37

•Focus on identifying the stakeholders’

needs

• Involve all the stakeholder groups

• Involve more than one representative

from each stakeholder group

•Use a combination of data gathering

techniques

Some basic guidelines (2)

38

• Support the process with props such as

prototypes and task descriptions

• Run a pilot session

• You will need to compromise on the data you

collect and the analysis to be done, but before

you can make sensible compromises, you need

to know what you’d really like

• Consider carefully how to record the data

39

Data interpretation and analysis

•Start soon after data gathering session• Initial interpretation before deeper

analysis•Different approaches emphasize different

elements e.g. class diagrams for object-oriented systems, entity-relationship diagrams for data intensive systems

Task descriptions

40

• Scenarios― An informal narrative story, simple, ‘natural’,

personal, not generalisable

• Use cases— Assume interaction with a system— Assume detailed understanding of the

interaction

• Essential use cases— Abstract away from the details— Does not have the same assumptions as use

cases

Task analysis• Task descriptions are often used to envision new

systems or devices• Task analysis is used mainly to investigate an existing

situation• It is important not to focus on superficial activities

– What are people trying to achieve? – Why are they trying to achieve it?– How are they going about it?

• Many techniques, the most popular is Hierarchical Task Analysis (HTA)

41

Hierarchical Task Analysis

• Involves breaking a task down into subtasks, then sub-sub-tasks and so on. These are grouped as plans which specify how the tasks might be performed in practice

• HTA focuses on physical and observable actions, and includes looking at actions not related to software or an interaction device

• Start with a user goal which is examined and the main tasks for achieving it are identified

• Tasks are sub-divided into sub-tasks

42

43

Example Hierarchical Task Analysis

0. In order to buy a DVD1. locate DVD2. add DVD to shopping basket3. enter payment details4. complete address5. confirm order

plan 0: If regular user do 1-2-5. If new user do 1-2-3-4-5.

44

Example Hierarchical Task Analysis (graphical)

Hierarchical Task Analysis (2)

• More in the tutorial

45