---
tags: Exam Recap, HCI
---

# HCI 2020 notes

## S02 - What is HCI

Ingredients:

- user
- computer
- task to accomplish

**Goal:** the system must support the user's **task**, with a focus on its usability

- useful
- usable
- used

HCI is very multidisciplinary

### Models of interaction

Assume that the user wants to accomplish a **goal** in a specific **domain**. **Tasks** are operations to manipulate the concepts of a domain

#### Norman’s model


#### Abowd and Beale model, with explicit UI


### Human errors

Human errors are usually a result of bad design, never the fault of the user

Slip:

- right action but fail to execute it correctly
- maybe corrected by a better interface

Mistake

- you don't know the system well and you may not formulate the right goal
- the user mental model if the system state is not correct
- requires radical redesign

### Human centered design process

Dimensions of usability:

- Usefulness: does it do something people want?
- Learnability: is it easy to learn?
- Memorability: once learned, is it easy to remember?
- Effectiveness: does it allow reaching the goal?
- Efficiency: once learned, is it fast to use?
- Visibility: is the state of the system visible?
- Errors: are errors few and recoverable?
- Satisfaction: is it enjoyable to use?


HCI should be considered in every step of the software process -> "HCI is always a step ahead"

## S03 - Need-finding

To do:

- what do users need?
- what do users want?

This requires:

- who are the users?
- how are they doing it now?
- what is the context in which they are doing it?

Need to know your users (**you are not the user**) but you can

- talk to them
- watch them
- imagine them

### Observation

- to embed in the users' environment and obtain the necessary data to influence interface design
- learn the language of the user
- process vs practice

Types:

- controlled
- in a lab
- easy to reproduce and analyze
- the act of observation could change the approach of the user to the task
- naturalistic
- _in the wild_
- more reliable and useful to come up with new ideas
- not replicable and hard to manipulate external variables

Blending in the environment:

- become part of the wall
- become "one of them"

### Diaries

- observing users "in the wild" for long periods of time is not possible by an observer
- diaries require user actions
- users should get an incentive
- user needs to track own behavior

### Interviews

- Time demanding with respect to surveys
- provide more deep knowledge of the user
- user do not know what they want
- choose a sample that best represents all the stakeholders of the app
- questions:
- open-ended for follow-up discussion
- use language of the user
- concrete, specific questions

### Surveys

- familiar, cost-effective
- easy to visualize and statistically analyze
- shallow view of a large base of users
- limit number of mandatory infos asked to the user
- questions:
- open-ended, avoid too generic
- close-ended; only ordinal or nominal
- better 2 simple questions than a complex one

## S04 - Task Analysis

Task analysis is the study of the way people perform their jobs:

- what they do
- what things they use
- what they must know

A **task** is a **goal** together with come ordered set of **actions**

The task analysis is useful in every part of the development:

- identify tasks to support
- navigation
- site structure
- prototyping
- usability testing

### Hierarchical Task Analysis (HTA)

Disintegrating a task into subtasks until too easy/obvious. It leads to an hierarchy of tasks and a set of plans which describe how to order/execute them

### Knowledge-based Analysis

Aim to understand the knowledge required for a task.

It focuses on:

- object used in task
- actions performed

How to generate the knowledge?

- established conventions and existing documentation
- ask users to list objects
- structured interviews

## S05 - Prototyping

Types of prototypes:

- paper
- video
- Wizard-of-Oz
- Mockups

The prototype is meant to not be durable -> evolutionary, to be discarded. Classifiable by:

- Durability:
- exploratory
- experimental
- operational
- Coverage:
- global
- local
- Functional completeness:
- horizontal
- vertical
- diagonal
- Fidelity:
- Low
- high
- Usage:
- Static
- Dynamic
- Interactive

### Paper prototypes

- low fidelity in look and feel, high fidelity in depth (person is the backend)
- natural interactions
- why?
- faster to build
- easy to change
- focus on big picture
- can learn:
- conceptual model
- navigation and task flow
- terminology
- can't learn:
- look (color, fonts, ...)
- response time

### Video prototype

- a video to convey the ides shown in the storyboard or paper prototype
- not interactive
- is for:
- showing how final product should be
- show designers/development the intended use/outcome
- focus on message, not on the production quality

### Medium fidelity prototype (mockups)

- interactive
- drawbacks:
- only click, not interact
- paths are static

### High fidelity prototypes

- actual computer application
- expensive, more time on graphic design than interaction design
- can learn:
- screen layout: clear? Overwhelming?
- color, font, icons
- interactive feedback

### Wizard-of-Oz techniques

- used to test an application that is complete without writing code
- approach of the "man behind the curtain"
- the wizard could be visible or hidden

## S06 - Guidelines


- Guidelines: low-level focused advice about good practices and cautions against dangers
- Principles: mid-level strategies or rules to analyze and compare design alternatives
- Theories: high-level applicable frameworks to draw on during design and evaluation

### Design theories

Types:

- descriptive
- UI elements, terminology
- Foley and van Dam theorized the four-level approach
- explanatory
- sequences of events with causal relationships
- Norman's action models (the events during HCI)
- prescriptive
- guidelines for designers
- consistency theory (color, layout, icons, ...)
- predictive
- comparison of design alternatives

### Design principles

- more practical than theories
- more widely applicable and enduring than guidelines

#### Interaction style

- direct manipulation
- menu selection
- form fill-in
- command language
- natural language

#### Norman's principles from action models

| Principles of good design | User failures can occur |
| ---------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| state and action alternatives should be visible | users can form an inadequate goal |
| should be a good conceptual model with a consistent system image | might not find the correct interface object because of an incomprehensible label |
| interface should include mappings between stages | may not know hot to specify or execute a desired action |
| user should receive continuous feedback | may receive inappropriate or misleading feedback |

#### 8 golden rules of interface design

- strive for consistency
- cater to universal usability
- offer informative feedback
- design dialogs to yield closure
- prevent errors
- permit easy reversal of actions
- keep users in control
- reduce short-term memory load

### Design guidelines

- concrete suggestions about _how_ the principles may be satisfied
- often rule-based
- based on best practices
- may be too specific
- examples: Material design, Apple UI, Microsoft _fluent_ design

## 08 - Heuristic evaluation

- Evaluation may take place
- in a lab
- in the field
- Based on expert evaluation
- analytic methods
- review methods
- model-based methods
- heuristics
- Automated evaluation
- simulation software measures
- formal evaluation with models

Evaluation is done by a cognitive walkthrough:

- step by step revision of actions
- evaluators examine each step
- particularly suited for systems designed for learning by exploration

### Heuristic evaluation description

when is it useful?

- before user testing
- before redesigning
- to generate evidence for problems that are known
- before release

Developed by Jacob Nielsen to find usability problems in a design at any stage of the process. Basic idea:

- define a set of heuristics
- give the heuristics to a group of experts
- each expert analyzes design independently and provides feedback
- the discovered violations are used to fix problems or to re-design

Nielsen provided 10 heuristics, but some can be added or ignored depending on the context

No evaluator finds all problems, considering the correlation between the number of evaluators and the cost of conducting the experiment, a good number is 3-5.

Composed by:

- pre-evaluation training
- evaluation
- severity training
- debriefing

| heuristic evaluation | user testing |
| ----------------------------------------- | ---------------------------------------------- |
| faster | need to develop software and setup |
| results are pre-interpreted by evaluators | more accurate because actual users not experts |
| could generate false positives | |
| might miss some problems | |

### 10 Nielsen's usability heuristics

1. visibility of system status
- the system should always keep users informed about what is going on
- e.g.: feedback about time, space, change, action, next steps, completion
2. match between system and the real world
- the system should speak the users' language
- exploit familiarity
- e.g.: use the world _library_ for the list of musics of the user
3. user control and freedom
- Support undo and redo
- allow users to _explore the app_
4. consistency and standards
- users should not have to wonder whether different words, situations, actions means the same thing
- follow platform conventions
- e.g.: consistent layout of navigation, clear and consistent answer options
5. error prevention
- Try to prevent error generation and eliminate error-prone conditions. Use confirmation option before commit
6. recognition rather than recall
- minimize user's memory
- the user should not have to remember information from one part of the dialogue to another
- instructions should be visible or easy to retrieve
- e.g.: avoid codes, avoid to ask/give extra information
7. flexibility and efficiency of use
- allow the use of "accelerators" to cater for both novice and expert users
- e.g.: shortcuts, "mark as spam", exploit background info
8. aesthetic and minimalist design
- dialogues should not contain information which is irrelevant or rarely needed
- e.g.: key information must be "above the fold", minimalistic login procedure
9. help user recognize, diagnose and recover from errors
- error messaged should be expressed in natural plain language, indicate the problem and constructively suggest a solution
- e.g.: make errors easy to identify, provide solutions
10. help and documentation
- if there is the need for docs (should not) it should be easy to search and focused on user's task and not be too large
- e.g.: provide examples, help user understand error gravity, use pop-overs

## 09 - Designing for diversity

We need to design for the user, but who is actually the "normal" user? People like us? Assuming that all senses and abilities are fully enabled means ignoring several people.

### Inclusive design comes in

- design a diversity of ways so that everyone has a sense of belonging
- not _one size fits all_ but _one size fits one_
- 3 principles
- recognize exclusion
- learn from diversity
- solve for one, extend to many
- e.g.: co-pilot mode in a video game

### Universal design

- more of a _one size fits all_ approach
- not consider very specific cases
- born for the physical world, then adopted in the digital one

### Accessibility

- focuses towards disabilities
- provides standards
- it is not the same as inclusive design
- the web provides APIs for accessibility but most of it doesn't exploit them
- W3C created the _Web Accessibility Initiative_ to provide s set of guidelines for accessibility

## S10 - Multimodal interaction

To use more than one sensory channel or mode of interaction. It is to provide both redundancy and enhance the richness of the interaction

Around us:

- Most interaction is visual, it could be overloaded as system become complex
- using multiple modes can increase the bandwidth of interaction
- vision
- the most used way
- gaze
- use gaze to control an interface, in addition or as a substitute to a keyboard and/or mouse
- eye-tracker technology
- smell and taste
- can be used as an early-warning system
- to provide a more immersive experience
- haptic
- braille display
- TeslaTouch (simulate tactile feeling on a display)
- gestures
- hearing
- non-vocal sounds
- voice-based

## S11 - AI interaction

- Interacting with AI could lead to unpredictable behaviors
- focus on feedback and error prevention
- many AI components are inherently inconsistent
- it is important to know when _to AI_ and when _not to AI_
- balance uncertainty of AI systems with proper expectations and feedback
- there exists some guidelines (Microsoft) to AI-based interaction

## S12 - Usability testing

_Let's find someone to use our app, so that we will get some feedback on how to improve it_

- observatory driven
- speeds up projects and produces costs savings
- participants should represent the intended user community, focus to
- background in computing
- education/ability in natural domain language
- usually done in dedicated usability testing labs -> 2 areas:
- testing room
- observation room

Steps in usability testing

1. plan
- who, what, where, how the test
2. run
- one participant at time, multiple sessions
- collect data about interactive system
3. analyze
- extract information from the data

### Plan

- Use 5 participants
- decide which roles to play:
- at least 1 facilitator
- observers
- developers, designers, creators should not be facilitators
- choose which task to perform
- can be introduced with a scenario
- concrete and clear goal
- 5-10
- choose methodology
- think-aloud
- while the participant performs a task she is asked what she is doing and why...
- pros: simple, can provide useful insights and how the system is actually used
- cons: subjective, selective, time of describing can impact performance
- cooperative evaluation
- variation of think-aloud
- participant and facilitator collaborate during evaluation
- pros: less constrained, encouraged to criticize the system
- define success/failure criteria for each task
- prep equipment and informed consent form
- decide whether to have a debrief session at the end with each participant
- develop a _script_ for consistency among instructions
- define metrics
- subjective
- quantitative
- post-task questionnaire
- SEQ - single ease question
- ask user to rate difficulty of activity from very easy to very difficult on a 7-point Likert-scale
- SUS - system usability scale
- quick and dirty usability scale
- measures perceived usability
- 10-item Likert-scale each with 5 options
- final score 0-100, not percentage, a SUS score above 68 is considered above average
- calculate SUS score
- each answer 1-5
- odd question - questionScore = x-1
- even question - questionScore = 5-x
- score = sum(questionScore) \* 2.5
- pros: reliable, free, for wide range of technologies
- cons: subjective, no clues on how improve, not possible 2 compare different systems
- NASA-TLX - NASA Task load index
- measures perceived workload
- 6 questions on a 21-point scale, from _very low_ to _very high_
- each question addresses a dimension of the workload

### Run

- inform the participant that "we are testing the app, not you"
- the facilitator should remain neutral and follow the script
- the facilitator must encourage the participant to adopt and explain the chosen methodology

### Analyze

- analyze the data to find UI failures
- consider collected metrics
- look for trends

## 13 - Controlled experiment

_We want to verify if users of our app perform task X faster/…/with fewer errors than our competitor's
app_

- scientific
- hypothesis driven

### Plan

Choose:

- what to study, which question to answer
- hypothesis
- participants
- experimental method to use
- tasks to disprove hypotheses
- test to analyze results

Variables (example of selection time with menus of different length)

- **independent** (or factors)
- elements of the experiment controlled to produce different conditions for comparison
- can have different values -> levels
- each experimental condition is a combination of a level from each IV
- a good experiment limits the number of IV to 1 or 2, 3 top
- e.g. number of options in menu
- **dependent**
- characteristics measured in the experiment
- depend on the changes made to the IV
- e.g. time to select item in menu
- control
- variables that may influence a DV that are controllable but are not under investigation
- display size, cursor speed
- random
- e.g. gender, height
- confounding
- any circumstance or condition that changes systematically with an IV
- very problematic
- e.g. if you use 2 cameras to track person's eyes in different conditions, the different characteristics of the cameras are confounding variables

Hypotheses

- framed in terms of IVs and DVs
- in the form of a null hypothesis, it states that there is not difference in the dependent variables between the levels of the independent variables
- disprove null, accept alternative
- difference is computed statistically

Subjects

- at least double Nielsen number for usability testing
- sufficient sample

Experimental methods

- Between subjects
- each participant performs only one condition
- no transfer of learning
- more users required
- user variation che bias result
- within-subjects
- each participant performs experiment under each condition
- possible transfer of learning
- less costly and less suffer from user variation
- counter balancing helps minimize the transfer of learning (latin balanced square)

### Analyze

- need to perform statistical analysis but always look before at the data
- types of data
- nominal
- ordinal
- interval
- ratio
- types of tests
- non-parametric
- distribution free
- for all types of data
- parametric
- assume data distribution
- more powerful than non-parametric

**Chi-Square test**

- most-used parametric test, mainly for A/B testing
- 2 assumptions
- not work well with small sample size (<20)
- data points in the categories must be independent from each others (each user can contribute to only one category)
- look at slides and exercise