Tentamen Human Computer Interaction - part 2

Lecture 7: Data gathering

Buzzword: Wisee.

Whole-home gesture recognition using wireless signals. Unlike Kinect etc. no infrastructure needed,

no cameras needed and through the wall and out-of- sight scenarios.

7.2 – Five key issues

1. Setting goals – Decide how to analyze data once collected

2. Identifying participants – Decide who to gather data from

3. Relationship with participants – Clear and professional, Informed consent when appropriate

4. Triangulation – Look at data from more than one perspective

5. Pilot studies – Small trial of main study

7.3 – Data recording

Notes, audio, video photographs. Notes plus photographs. Audio plus photographs. Video,

interaction loggings, sensor-based (biometrics, speech/gestures).

Data recording in COMIC/SLOT, Spatial Logistics Task. Multimodal interaction. How do users perform

turn-taking, negotiate information, while using facial expressions, speech and gestures?

7.4 – Interviews

Unstructured – are not directed by a script. Rich but not replicable.

Structured – are tightly scripted, often like a questionnaire. Replicable but may lack richness.

Semi-structured – guided by a script but interesting issues can be explored in more depth. Can

provide a good balance between richness and replicability.

Interview questions.

Two types: closed questions and open questions. Close questions are easier to analyze. Avoid long

questions, compound sentences, jargon and language that the interviewee might not understand,

leading questions that make assumptions, unconscious biases.

Running the interview.

- Introduction – introduce yourself, explain the goals of the interview, reassure about the ethical

issues, ask to record, present any informed consent form.

- Warm-up – make first questions easy and nonthreatening.

- Main body – present questions in a logical order

- A cool-off period – include a few easy questions to defuse tension at the end

- Closure – thank interviewee, signal the end, e.g, switch recorder off.

7.5 - Questionnaires

Questions can be closed or open. Closed questions are easier to analyze, and may be done by

computer. Can be administered to large populations. Paper, email and the web used for

dissemination. Sampling can be a problem when the size of a population is unknown as is common

online

Questionnaire design.

The impact of a question can be influenced by question order. Do you need different versions of the

questionnaire for different populations? Provide clear instructions on how to complete the

questionnaire. Strike a balance between using white space and keeping the questionnaire compact.

Decide on whether phrases will all be positive, all negative or mixed.

Question and response format: ‘Yes’ and ‘No’ checkboxes. Checkboxes that offer many options.

Rating scales. Open-ended responses.

Encouraging a good response.

Make sure purpose of study is clear. Promise anonymity. Ensure questionnaire is well designed. Offer

a short version for those who do not have time to complete a long questionnaire. If mailed, include a

stamped addressed envelope. Follow-up with emails, phone calls, letters. Provide an incentive. 40%

response rate is high, 20% is often acceptable.

Advantages of online questionnaires.

Responses are usually received quickly. No copying and postage costs. Data can be collected in

database for analysis. Time required for data analysis is reduced. Errors can be corrected easily.

Problems with online questionnaires.

Sampling is problematic if population size is unknown. Preventing individuals from responding more

than once. Individuals have also been known to change questions in email questionnaires.

An online experiment with Maki

A typical AI/HF experiment. AI: synthesized music. HF: how do humans cope/perceive/appreciate

Data gathered:

- personal info: age/gender/language/experience

- how human-like does it sound?

- how do you like it?

- similarity between two sounds

Data gathered:

- Two main conditions (human/synthesized)

- Several sub-conditions (rhythm/contour/harmony)

7.6 - Observation

Direct observation in the field

– Structuring frameworks

– Degree of participation (insider or outsider)

– Ethnography.

Direct observation in controlled environments.

Indirect observation: tracking users’ activities

– Diaries

– Interaction logging

7.7 - Choosing and combining techniques

Depends on

– The focus of the study

– The participants involved

– The nature of the technique

– The resources available

Summary

Three main data gathering methods: interviews, questionnaires, observation. Five key issues of data

gathering: goals, choosing participants, triangulation, participant relationship, pilot. Interviews may

be structured, semi-structured or unstructured. Questionnaires may be on paper, online or

Telephone. Observation may be direct or indirect, in the field or in controlled setting. Techniques can

be combined depending on study focus, participants, nature of technique and available resources.

Lecture 9: The process of ID

Buzzword: The Tech Box.

What is involved in ID?

• 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-centred design,

– activity-centred design,

– systems design, and

– genius design

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

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

• Newsletters and other dissemination devices

– Reach wider selection of users

– Need communication both ways

• User involvement after product is released

• Combination of these approaches

User-centered approach is based on:

– Early focus on users and tasks: directly studying cognitive, behavioral, anthropomorphic &

attitudinal characteristics

– 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

Four basic activities in ID:

1. Establishing requirements 2. Designing alternatives 3. Prototyping 4. Evaluating

Some practical issues: 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?

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

What do we mean by ‘needs’?

• Users rarely know what is possible

• Users 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.

How to generate alternatives

Humans stick to what they know works. But considering alternatives is important to ‘break out of the

box’. Designers are trained to consider alternatives, software people generally are not. How do you

generate alternatives? 1)‘Flair and creativity’: research and synthesis, 2) Seek inspiration: look at

similar products or look at very different products .

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

Genius design: inspiration based, intuition, experience, expertise, team work.

UCD:

• You like predictable, measurable results

• User testing is a significant source of decisionmaking confidence for you and your team

• You are risk averse

• You have the time and budget to devote to repeated testing and validation

Genius:

• You are working with a highly experienced team

• You trust your colleague’s intuition

• You trust your own intuition

• You have a deep understanding of your end users’ ultimate goals

Summary

Four basic activities in the design process:

1. Establishing requirements

2. Designing alternatives

3. Prototyping

4. Evaluating

User-centered design rests on three principles

1. Early focus on users and tasks

2. Empirical measurement using quantifiable & measurable usability criteria

3. Iterative design

Lecture 10: Establishing requirements

Buzzword: chord typing. Asetniop.

Four basic activities in ID: 1) Establishing requirements, 2) designing alternatives, 3) prototyping, 4)

evaluating.

What: Two aims:

1. Understand as much as possible about users, task, context

2. Produce a stable set of requirements

How: Data gathering activities

Data analysis activities

Expression as ‘requirements’

All of this is iterative

Boehm & basili (2001): finding and fixing a software problem after delivery is often at least 100 times

more expensive than finding and fixing it during the requirements and design phase.

Why: Requirements definition: the stage where failure occurs most commonly. Getting

requirements right is crucial.

What is a requirement? A statement about an intended product that specifies what it should do or

how it should perform or how it should look and feel.

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.

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)?

• Users: Who are they? — Characteristics: ability, background, attitude to computers

— Novice: step-by- step (prompted), constrained, clear information

— System use: novice, expert, casual, frequent

— Expert: flexibility, access/power

— Frequent: short cuts

— Casual/infrequent: clear instructions, e.g. menu paths

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, user support, communications structure and

infrastructure, availability of training

— technical: standards, hardware, limitations

Personas

• 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

Data gathering for requirements

Interviews: — Prototypes can be used in interviews

— Good for exploring issues

— But are time consuming and may be infeasible to visit everyone

Focus groups: — Group interviews:

— Good at gaining a consensus view and/or highlighting areas of conflict

— But can be dominated by individuals

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

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

Contextual Inquiry

• An approach to ethnographic study where user is expert, designer is apprentice

• A form of interview, but — at users’ workplace (workstation)

• Four main principles: — Context: see workplace & what happens

— 2 to 3 hours long

— Partnership: user and developer collaborate

— Interpretation: observations interpreted by user and developer

together

— Focus: project focus to understand what to look for

Problems with data gathering

• 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

• ‘Real’ users, not managers: traditionally a problem in software engineering, but better now

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

• Political problems within the organisation

• Dominance of certain stakeholders

• Economic and business environment changes

• Balancing functional and usability demands

Some basic guidelines

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

• 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

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

• 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

— more structured and distinguishing between system/user

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)

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

Summary

• Getting requirements right is crucial

• There are different kinds of requirement, each is significant for interaction design

• The most commonly-used techniques for data gathering are: questionnaires, interviews, focus

groups, direct observation, studying documentation and researching similar products

• Scenarios, use cases and essential use cases can be used to articulate existing and envisioned work

practices.

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

Lecture 11: Prototyping and building

Buzzword: HRI.

Human-Robot Interaction (HRI) is a relatively young discipline that has attracted a lot of attention

over the past few years due to the increasing availability of complex robots and people's exposure to

such robots in their daily lives, e.g. as robotic toys or, to some extent, as household appliances

(robotic vacuum cleaners or lawn movers). Also, robots are increasingly being developed for real

world application areas, such as robots in rehabilitation, eldercare, or robots used in robotassisted

therapy and other assistive or educational applications.

HRI as a research domain is a synthetic science, and it should tackle the whole range of challenges

from technical, cognitive/AI to psychological, social, cognitive and behavioural.

What is a prototype? In other design fields a prototype is a small-scale model: for example a

miniature car.

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

• a series of screen sketches

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

• a Powerpoint slide show

• a video simulating the use of a system

• a lump of wood (e.g. PalmPilot)

• a cardboard mock-up

• a piece of software with limited functionality written in the target/another language

Why prototype?

• Evaluation and feedback are central to interaction design

• Stakeholders 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 • Difficult, controversial, critical areas

Low-fidelity Prototyping uses a medium which is unlike the final medium, e.g. paper, cardboard and

it is quick, cheap and easily changed.

‘Wizard-of- Oz’ prototyping

• The user thinks they are interacting with a computer, but a developer is responding to output

rather than the system.

• Usually done early in design to understand users’ expectations

High-fidelity prototyping

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

• Prototype looks more like the final system than a lowfidelity version.

• For a high-fidelity software prototype common environments include Macromedia Director, Visual

Basic, and Smalltalk.

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

Compromises in prototyping

• All prototypes involve compromises

• 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 and ‘vertical’: provide a lot of detail for only a few functions

• Compromises in prototypes mustn’t be ignored. Product needs engineering.

Construction

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

• Quality must be attended to: usability (of course), reliability, robustness, maintainability, integrity,

portability, efficiency, etc

• Product must be engineered Evolutionary prototyping ‘Throw-away’ prototyping

Conceptual design: from requirements to design

• Transform user requirements/needs into a conceptual model

• “a description of the proposed system in terms of a set of integrated ideas and concepts about

what it should do, behave and look like, that will be understandable by the users in the manner

intended”

• Don’t move to a solution too quickly. Iterate, iterate, iterate

• Consider alternatives: prototyping helps

Is there a suitable metaphor?

• 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?

Considering interaction types

• Which interaction type? How the user invokes actions. Instructing, conversing, manipulating or

exploring

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

Expanding the conceptual model

• What functions will the product perform? What will the product do and what will the human do

(task allocation)?

• How are the functions related to each other? Sequential or parallel? Categorisations, e.g. all actions

related to telephone memory storage

• What information needs to be available? What data is required to perform the task? How is this

data to be transformed by the system?

Summary

• Different kinds of prototyping are used for different purposes and at different stages

• Prototypes answer questions, so prototype appropriately

• 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

Lecture 12: ID in Practice

Buzzword: BCI. Wolpaw (2002): a BCI translates brain signals into control commands for steering a

device or neural interface.

Agile development

• Short (one to three week) timeboxes of iterative development (sprint, iteration, cycle)

• Early and repeated customer/user feedback

• Re-prioritisation of work based on customer/user so that emergent requirements can be handled

AgileUX

• Integrates techniques from interaction design and Agile software development

• AgileUX requires a change of mindset

• In Agile, as implementation proceeds: – requirements are elaborated – requirements are re-

prioritised

• All techniques in UX are still relevant but when and how much needs re-thinking – focus on

product, not design, as deliverable – cross-functional teams

User research

• Aims to characterise users through data collection and analysis

• Agile’s timeboxing approach does not support long periods of user research

• User evaluations and some detailed work can be fitted within a timebox

• Some user research can be performed in iteration 0 (zero), before implementation starts

• Ongoing programme of user research

Aligning work practices

• Designing a complete product upfront causes problems because of re-prioritisation

• Some upfront work is needed (technical and UX)

• Use a parallel tracks approach: – create product vision before development starts, (cycles 0 and 1)

– do design work one iteration ahead of development – some teams work two iterations ahead