# UCD

## Lecture 1

Usability is the extent to which a product can be used by **specified users to achieve specified goals with effectiveness, efficiency and satisfaction**.

UCD process:

- Planning
- Understand context of use
- Specify the user requirements
- Produce solutions to meet requirements
- Evaluate and iterate (above stages)

Usability goals:

- Effectiveness (Completeness)
- Efficiency (Ease of use)
- Satisfaction (Perceived ease of use)

## Lecture 2 (Understand context of use)

Requirement extraction process:

- Elicit
- Analyse
- Extract

Vision statement: **Explains the system to outsiders** is **short** and **can change over time**.

### Research

Data gathering methods:

- Interviews (contextual)
- Observation (contextual)
- Surveys/Questionnaires
- Card sorting

#### Surveys/Questionnaires

Semantic Differential:

Good for getting peoples feelings about a system.
e.g.:

``` text
hard        1 2 3 4 5       easy
confusing   1 2 3 4 5       understandable
```

Likert Scale:

Good for measuring opinions and feelings.
e.g.:

``` text
Strongly    1 2 3 4 5       Strongly
disagree                    agree
```

#### Card sorting

Good for finding out how people think information should be organised.

Method:

- Prepare set of cards
- Shuffle
- Ask users to sort cards
- Examine which cards are grouped together

Qualitative data:

- Interview comments
- Observations

Synthesising raw data:

- Paraphrase
- Break up statements
- Provide references for statements (e.g.: participant number)
- Write in users perspective (e.g.: `I`, `my`)

#### Affinity Diagram

Good for organising and grouping qualitative data.

Process:

- Write synthesised statement on separate card
- Try to group them into themes by analysing notes
- Label each group
- Find groups of groups

## Lecture 3 (Specify the user requirements)

### Functional requirements

The **services (or functionality) that the system should provide** and **how the system reacts to input and how it behaves in specific situations**. Are **user requirements**.
e.g.:

```text
The user shall be able to register a new account with an email
address and a password of their choice.
```

### Non-functional requirements

Requirements **not concerned with specific functions**, may relate to **performance requirements**. Are **usability requirements**.

e.g.:

```text
qualitative: the user is not distracted by information that is irrelevant to
their goal
quantitative: the user can register an new account in less than 30 seconds
```

Writing requirements:

```text
Name of major feature or category
Name of second level feature or category
Requirement statement [with source from affinity diagram]
Rationale (if useful): Rationale statement
Note (optional): Commentary about requirement
```

System Usability Scale (SUS):

- Satisfaction measure (out of 100)
- Odd question: Subtract 1 from *score* (Score-1)
- Even question: Subtract score from 5 (5-Score)
- Add all up and multiply by 2.5

Modelling user characteristics:

- User profile: list of user characteristics
- User persona: description of ‘typical’ user

Modelling task information:

- Workflow model
- Hierarchical task description/inventory (structured sub-tasks)
- Scenarios
- Essential use case (captures interaction between user and system)

## Lecture 4 (Produce solutions to meet requirements)

Sketching is about **getting the right design**.
Prototyping is about **getting the design right**.

Mental Models: How a user thinks the system works.

## Lecture 5 (Produce solutions to meet requirements continued)

Affordance: an **attribute of an object** that **allows people to know how to use it**.

Sensory Affordance:

- C: Contrast
- R: Repetition
- A: Alignment
- P: Proximity

Prototyping fidelity:

- Low (paper prototyping)
- Mid (software used to present prototype)
- High (some level of programming)

## Lecture 6 (Evaluate and iterate)

Formal evaluation: For designing.
Summative evaluation: For gauging a final design.

### Types of evaluations

**Quick and dirty evaluation:**

- Quick
- Cheap
- Not precise
- For low-fi prototype designing

**Controlled evaluation:**

- Expensive
- Time consuming
- Very precise
- For summative evaluation

**Field evaluation:**

- Done in real environment
- For hi-fi prototype testing

**Remote evaluation:**

- For hi-fi prototype testing

### Severity ratings

**Frequency:**

- Common
- Rare

**Importance:**

- Difficult to overcome
- Easy to overcome

**Persistence:**

- Ongoing problem
- One time only

Heuristics == Guidelines