Research real users, define the problem, design and prototype a solution, test it and write it up as a portfolio case study.

UX Design Process

Write one or two test goals and the success criteria for each task.

Write three realistic scenario tasks. Check that none uses the exact words on the buttons you want people to find.

Write a script: intro (thanks, "we're testing the design, not you", think aloud, consent to record), the tasks with a follow-up question after each, and closing questions.

Pilot the whole session with one person and fix any confusing tasks or prototype dead ends.

Recruit five people who match your persona criteria and were not involved in the design.

Run each session. Stay neutral, prompt with "What are you thinking?", and only help if someone is completely stuck (record it as assisted).

Straight after each session, record for each task: success, success with difficulty, or failure, plus key observations and quotes.

Merge observations into findings with participant counts, severity and a recommendation for each.

Write a one-page report: summary, task success table and the top three findings.

## Why it matters

A **usability test** means watching real people try to complete real tasks with your design. It is the single most reliable way to find out whether a design works. Teams are often surprised: the button everyone in the meeting thought was obvious goes unnoticed by four out of five participants. Five sessions of 30 minutes, run with a clickable prototype, usually reveal the biggest problems.

## The core idea: tasks, think-aloud and silence

In a typical **moderated** test, a facilitator sits with one participant (in person or on a video call), gives them realistic tasks and asks them to **think aloud**: say what they are looking at, trying and expecting. The facilitator mostly stays quiet and watches. A note-taker, if you have one, records what happens.

You are testing the design, not the person. Say this at the start, and mean it.

## Planning the test

**1. Goals.** What do you need to learn? "Can people split a bill unequally and send requests without help?"

**2. Participants.** Five people who match your persona's criteria and did not help design the product. For practice, the same recruiting approach as your interviews works.

**3. Tasks.** Write tasks as realistic scenarios with a goal, not instructions:

| Weak task | Better task |
|---|---|
| Click "Split this bill", then choose "No". | The internet bill just arrived. Leo agreed to pay $20 because he works from home. Ask everyone for their share. |
| Find the settings page. | You keep getting reminders at 7 a.m. Make them come later. |

Avoid words that appear on the button you want them to find; otherwise you test word-matching, not understanding.

**4. Script.** Write an intro (thanks, purpose, "we're testing the design, not you", think aloud, consent to record), the tasks, a follow-up question after each task, and closing questions.

**5. Success criteria.** Decide in advance what counts as success for each task (for example "reaches Confirmation with Leo at $20").

**6. Pilot.** Run the whole test once with a friend and fix confusing tasks.

## Moderating

- Start each task by reading it aloud and handing over a written copy.
- When people go quiet, prompt neutrally: "What are you thinking?"
- If they ask "Should I tap this?", reflect it back: "What would you do if I weren't here?"
- Do not help unless they are completely stuck. If you must, note it: the task becomes "completed with assistance".
- Watch behaviour more than opinions. "I like it" means little if they took three minutes and tapped the wrong button twice.
- After each task, ask a short question, such as "How easy or difficult was that?" (you will measure this formally in the next lesson).

Remote unmoderated tools exist with free trials or limited free tiers, but limits change often; for this course, moderated sessions on a free video call or in person are the simplest option.

## Analysing and reporting

Right after each session, write down what happened on each task: success, success with difficulty, failure, and the key observations with timestamps if recorded.

After all sessions, merge observations into **findings**. Each finding should have:

- What happened (the observation), and how many participants it affected.
- Why it probably happened (your interpretation).
- Severity (for example: critical blocks the task; serious causes delay or errors; minor is an annoyance).
- A recommendation.

Example finding:

```text
F1 (critical, 4 of 5): Participants did not notice the "Split equally: No" option and
edited the bill total instead. They read "Split equally" as a heading, not a control.
Recommendation: replace the radio pair with a clear "Change amounts" button under the
list of shares.
```

A short report has a one-paragraph summary, the task success table, the top findings ordered by severity, and highlights such as short quotes or clips (with consent).

## Common mistakes

- **Leading tasks** that name the control to use.
- **Helping too soon.** Struggle is the data.
- **Defending the design** during the session.
- **Testing with teammates.** They know too much.
- **Long reports nobody reads.** Lead with the top three findings and recommendations.
- **Testing once.** Fix, then test again: two small rounds beat one big one.

## Quick recap

- Usability tests watch people attempt realistic tasks while thinking aloud.
- Plan goals, five matching participants, scenario tasks, a script and success criteria; pilot it.
- Moderate neutrally, let people struggle, and record behaviour.
- Report findings with counts, severity and recommendations, then iterate.

## Try it

On the Do tab you will plan, run and report a five-person usability test of your prototype.


Plan, moderate and report a small usability test of your prototype using realistic tasks and the think-aloud method.

Usability testing

Usability Testing 101

Introducing a Participant to a Usability Test: A Demonstration

## Why it matters

Findings like "four of five people missed the button" are powerful, but teams also need numbers: to compare two designs, to show that a redesign helped, or to track a product over time. **UX metrics** give you those numbers. The most common ones are simple to collect in the usability tests you already run.

## The core idea: measure behaviour and attitude

UX metrics fall into two families:

- **Behavioural** (what people do): task success, time on task, errors.
- **Attitudinal** (what people say): ease ratings and questionnaires such as the System Usability Scale.

Use both. People sometimes rate a task as easy even after failing it, and sometimes complete a task while hating every second.

## Task success rate

The most important usability metric. For each task, record whether each participant succeeded, using the success criteria you set before testing.

```text
success rate = successful attempts / total attempts x 100
```

Decide up front how to count **assisted** completions (when the facilitator helped). A strict approach counts only unassisted successes. If 5 participants did a task with results success, fail, success, assisted, success, the strict rate is 3 / 5 = 60%.

## Time on task and errors

**Time on task** is how long a participant takes from the start of a task to success. It is most useful for comparing designs or tracking frequent tasks. Times are skewed by a few slow participants, so report the **median** (or the geometric mean) rather than the plain average, and only include successful attempts.

**Errors** are wrong actions, such as tapping the wrong option or entering an invalid value. Count them per task to show where people stumble.

## Single Ease Question (SEQ)

After each task, ask: "Overall, how easy or difficult was this task?" on a 1 (very difficult) to 7 (very easy) scale. It takes seconds and adds an attitude measure per task.

## The System Usability Scale (SUS)

SUS, created by John Brooke in 1986, is a ten-item questionnaire given at the end of a test. Participants rate each statement from 1 (strongly disagree) to 5 (strongly agree):

1. I think that I would like to use this system frequently.
2. I found the system unnecessarily complex.
3. I thought the system was easy to use.
4. I think that I would need the support of a technical person to be able to use this system.
5. I found the various functions in this system were well integrated.
6. I thought there was too much inconsistency in this system.
7. I would imagine that most people would learn to use this system very quickly.
8. I found the system very cumbersome to use.
9. I felt very confident using the system.
10. I needed to learn a lot of things before I could get going with this system.

Odd-numbered items are positive; even-numbered items are negative. That is why scoring needs care:

- For odd items (1, 3, 5, 7, 9): contribution = response - 1.
- For even items (2, 4, 6, 8, 10): contribution = 5 - response.
- Add the ten contributions (0 to 40) and multiply by 2.5. The result is 0 to 100.

**Worked example.** Responses: 4, 2, 4, 2, 4, 2, 4, 2, 4, 2.

- Odd items: 4 - 1 = 3, five times = 15.
- Even items: 5 - 2 = 3, five times = 15.
- Sum = 30; 30 x 2.5 = **75**.

A SUS score is **not a percentage**. Across many published studies the average is about 68, so 75 is above average. Scores around 80 or more are generally considered good. With five participants, treat SUS as a rough signal, not a precise measurement; it becomes more reliable with more participants and is most useful for comparing versions of the same product.

## Reporting metrics honestly

- Report the number of participants next to every number: "60% (3 of 5)".
- With small samples, avoid decimals that suggest precision you do not have.
- Pair numbers with findings: the metric tells you *how much*, the observations tell you *why*.
- Compare like with like: same tasks, same type of participants.

## Common mistakes

- **Averaging raw SUS responses** instead of applying the odd/even scoring.
- **Calling SUS a percentage.** 68 is average, not "68% usable".
- **Mean time on task** dominated by one very slow participant.
- **Counting assisted completions as success** without saying so.
- **Numbers without context**: a success rate with no participant count.

## Quick recap

- Measure behaviour (task success, time, errors) and attitude (SEQ, SUS).
- Task success = successes / attempts; decide how to treat assisted completions in advance.
- SUS: odd items response - 1, even items 5 - response, sum x 2.5; average is about 68.
- Report sample sizes and pair metrics with qualitative findings.

## Try it

On the Do tab you will write small JavaScript functions that calculate task success rate and SUS scores, then use them on your own test data.


Measure usability with task success, time on task and the System Usability Scale, and calculate SUS scores correctly.

UX metrics

The System Usability Scale (SUS)

4.10. Measuring Usability - Task Success and Time on Task (User Experience Design)

Write a title and one-line summary that names the user, the problem and the outcome.

Write the overview: your role, timeline, tools, constraints and that it was a course project.

Write the problem section with your problem statement and two or three research insights with participant counts.

Pick the two or three most important design decisions. For each, write the evidence, the decision and the result.

Add the testing section: tasks, key findings, task success and SUS with the number of participants, and what you changed.

Choose four to six artefacts (affinity map, persona, journey map, flow, wireframes, final prototype screens) and write a caption for each. Crop them so they are readable.

Write a short reflection: what you would do next and one thing that did not go to plan.

Remove any participant names, faces or personal details, and add alt text to every image.

Ask someone to read it in five minutes and tell you the problem, your main decision and the result. Revise anything they could not answer.

## Why it matters

Designers are hired on their portfolios, and portfolios are made of **case studies**. A case study is a short story of one project: the problem, what you did, why you made the decisions you made, and what happened. Hiring managers often skim a case study in a few minutes, looking for evidence that you can think through a problem, not just make attractive screens. Your course project, from interviews to usability test, is exactly the raw material you need.

## The core idea: show decisions, not deliverables

A weak case study is a gallery: persona, journey map, wireframes, final screens, with no explanation. A strong one explains **why**. For each major step, answer: what did I need to learn or decide, what did I do, what did I find, and what did I decide as a result?

A reliable structure:

1. **Title and one-line summary.** "Splitting house bills without the awkward chase: a mobile concept that cut task failures from 4 of 5 to 1 of 5."
2. **Overview.** Your role, timeline, tools, team (or "solo course project"), and constraints. Be honest: a course project is fine.
3. **The problem.** Who has it and why it matters, with research evidence. Include your problem statement.
4. **Research.** What you did (five interviews), what you found (two or three key insights with counts), and one artefact (affinity map photo or persona).
5. **Define.** The journey map low point you chose, the flow and the sitemap decisions.
6. **Design.** Wireframes and prototype, with the two or three most important design decisions and the reasons for them. Show options you rejected and why.
7. **Testing.** What you tested, the key findings, metrics (task success, SUS with sample size) and the changes you made.
8. **Outcome and reflection.** What changed between versions, what you would do next, and what you learned.

## Worked example: a decision written well

Weak:

> I made wireframes for the split screen.

Strong:

> **Decision: let the app do the chasing.** In interviews, 3 of 5 people said asking housemates for money felt like nagging, and the journey map's lowest point was the chase. So the confirmation screen promises an automatic reminder in three days, and the request comes from "the house", not from the person who paid. In testing, 4 of 5 participants said the confirmation made them feel the follow-up "wasn't on them".

The strong version links evidence to a design choice and then to a result. That chain is what reviewers look for.

## Showing results honestly

- Use numbers with sample sizes: "Task success rose from 1 of 5 to 4 of 5 after the redesign" or "SUS 62 then 78 (5 participants each round)".
- Course and personal projects rarely have business metrics, and that is fine. Show research and testing outcomes instead.
- Never invent results. Reviewers ask follow-up questions in interviews, and made-up numbers fall apart quickly.
- Say what did not work. "My first card sort used jargon labels, so participants grouped by word" shows you can learn.

## Writing and layout tips

- **Lead with the outcome.** Put the summary and the final design near the top; many readers stop after the first screen.
- **Scannable headings** for each section, short paragraphs and captions on every image ("Affinity map: 46 notes from 5 interviews, grouped into 4 themes").
- **Show artefacts at a readable size.** A tiny photo of a wall of sticky notes proves nothing; crop to a readable section.
- **Keep it focused.** A good case study takes five to eight minutes to read. Cut steps that did not influence decisions.
- **Protect privacy.** Remove participants' names and faces unless you have permission, and do not share an employer's confidential work.
- **Accessible format.** Real text, not text baked into images; alt text on images; good contrast.

Where to publish: a free portfolio site builder, a personal site built with HTML and CSS, a PDF, or a free design community profile. The format matters less than the clarity of the story.

## Common mistakes

- **A gallery of deliverables** with no reasoning.
- **"We" with no "I".** Make your own contribution clear, especially in team projects.
- **Hiding the mess.** Real projects change direction; showing why is a strength.
- **Only final, polished screens.** Without the process, reviewers cannot judge your thinking.
- **Walls of text.** Break it up with headings, visuals and captions.

## Quick recap

- A case study tells the story of one project: problem, process, decisions, results, reflection.
- Link evidence to each decision and each decision to an outcome.
- Report honest results with sample sizes; never invent numbers.
- Lead with the outcome, keep it scannable, protect privacy.

## Try it

On the Do tab you will write a case study for the project you have worked on throughout this course.


Turn your course project into a clear portfolio case study that shows your process, decisions and results.

Writing a UX case study

Creating a UX Design Portfolio Case Study

Presenting Your UX Case Study in an Interview

Run a usability test, measure task success and SUS, and write the project up as a portfolio case study.