UX design is a repeatable process for making products that people can actually use. This intermediate course walks through the whole loop on one project of your choice: plan and run user interviews, synthesise the notes into an affinity map and a persona, map the user's journey, organise content with a card sort and a sitemap, diagram task flows, sketch wireframes, link them into a clickable prototype in free Figma, review it against Nielsen's usability heuristics, run a small usability test, measure task success and the System Usability Scale, and finish with a portfolio case study. Every lesson has a short reading, curated videos and a hands-on task you can do with paper, free Figma and a few willing friends. It builds on Visual Design Fundamentals and prepares you for UI/UX design and front-end roles.

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

## Why it matters

Every product has a user experience, whether or not anyone designed it. A bus ticket app that hides the cheapest fare, a form that wipes your answers when you make one mistake, a thermostat nobody in the house can program: these are all experiences, just bad ones. UX design is the discipline of shaping that experience on purpose, so the product is useful, usable and pleasant for the people who actually use it.

UX is often confused with UI (user interface). UI is the visible layer: screens, buttons, colours and type. UX is wider. It includes what problem the product solves, whether people can find what they need, how long a task takes, what happens when something goes wrong, and how people feel afterwards. A beautiful interface can still be a poor experience if it solves the wrong problem.

## The core idea: a process, not a talent

Good UX comes from a repeatable process that keeps checking assumptions against real people. The most widely used picture of that process is the **double diamond**, published by the UK Design Council in 2005. It has four phases in two diamonds:

1. **Discover** (diverge). Go wide. Talk to users, watch them work, read support tickets and analytics. Collect far more than you need.
2. **Define** (converge). Narrow down. Synthesise what you learned into a clear problem statement: who is struggling, with what, and why it matters.
3. **Develop** (diverge). Go wide again. Sketch many possible solutions, prototype the promising ones, and get feedback early.
4. **Deliver** (converge). Narrow to the solution that works, test it, refine it and ship it.

The first diamond is about **designing the right thing**. The second is about **designing the thing right**. Teams that skip the first diamond often build a polished solution to a problem nobody has.

The diamonds are not a one-way conveyor belt. A usability test in Deliver may show that you misunderstood the problem, and you go back to Discover. That loop is normal and healthy.

## Worked example: a library app

Imagine a city library wants an app so members can renew books.

- **Discover.** You interview eight members and two librarians. You learn that renewals are rarely the problem: members mostly forget due dates, and the real pain is late fees on children's books.
- **Define.** Your problem statement becomes: "Parents who borrow many children's books need to know what is due soon, because late fees on children's books cause most complaints." Notice it names a user, a need and an insight. It does not name a solution.
- **Develop.** You sketch a due-date calendar, push reminders, a family account view and automatic renewal. Paper prototypes with four parents show that automatic renewal plus a weekly reminder is the clearest.
- **Deliver.** You build a clickable prototype, test it with five parents, fix two confusing labels and hand it to developers with a spec.

The final product is not "an app to renew books". It is "never pay a late fee on your kids' books again", which is a far better result, and it came from the first diamond.

## Where UX work happens

Most UX roles mix several activities from this course:

| Activity | Typical output | Lesson |
|---|---|---|
| User research | Interview notes, findings | Interviews, synthesis |
| Synthesis | Affinity map, persona | Synthesis and personas |
| Mapping | Journey map, sitemap, flows | Module 2 |
| Design | Wireframes, prototypes | Module 3 |
| Evaluation | Test report, metrics | Module 4 |
| Communication | Case study, presentation | Case study |

In a small company one designer does all of this. In a large one, the work may be split between UX researchers, product designers, content designers and information architects. The process is the same.

## Common mistakes

- **Starting with the solution.** "We need a chatbot" is a solution. Ask what problem it solves and for whom before you design anything.
- **Treating yourself as the user.** You know the product too well. Your intuition is a hypothesis to test, not evidence.
- **Research theatre.** Running interviews and then ignoring the findings because the roadmap was already fixed. Research is only useful if it can change decisions.
- **Going linear.** Refusing to revisit an earlier phase because "we already did research". New evidence should send you back.
- **Confusing UX with UI polish.** Colours and shadows matter, but they come after the product solves the right problem in a usable way.

## Quick recap

- UX covers the whole experience of using a product, not just how it looks.
- The double diamond has four phases: Discover, Define, Develop and Deliver.
- The first diamond finds the right problem; the second finds the right solution.
- Going back to an earlier phase when evidence changes is part of the process.

## Try it

This lesson has a short quiz on the Do tab. In the next lesson you will choose a small project for the rest of the course and plan your first round of interviews.


Understand what user experience design covers and how the double-diamond process moves from research to a tested solution.

What UX is

What is UX (Not)?

What Is the Double Diamond Design Process?

Write your project topic and a one- or two-sentence research goal that says what you need to learn (not what you will build).

Write two or three participant criteria, for example "has split a bill with housemates in the last month".

Draft a discussion guide with an intro, a warm-up, five to eight open questions about specific past events, and a wrap-up. Use the funnel: broad first, then narrower.

Review each question: rewrite any that are yes/no, leading, about the future or asking two things at once.

Recruit five people who match your criteria and who do not know your project idea. Tell them it takes about 30 minutes.

Run each interview. Ask permission before recording or taking notes, keep to your guide loosely, probe with "tell me more" and leave silences.

Within a day of each session, write up the notes as separate short observations in the person's own words (one fact, quote or behaviour per line). Do not include full names or contact details.

After all five, list three things that surprised you and one question you wish you had asked.

## Why it matters

User interviews are the fastest way to learn how people really think about a problem: what they do today, what frustrates them, and what words they use. Five good conversations will usually teach you more than a week of guessing in a meeting room. They are also cheap. You need a goal, a list of questions, a few willing people and a way to take notes.

## The core idea: ask about the past, not the future

People are good at describing what they did and bad at predicting what they will do. "Would you use an app that reminds you about due dates?" almost always gets a polite yes. "Tell me about the last time you returned a library book late" gets a real story with real details: where they were, what they forgot, what it cost and how they felt.

So a good interview is mostly **open questions about specific past events**, followed by **probes** that dig deeper:

- "Tell me about the last time you..."
- "Walk me through how you did that."
- "What happened next?"
- "Why was that important?" or "How did that feel?"
- "You mentioned X. Can you say more about that?"

Then you stay quiet. Silence feels awkward, but people fill it with the most useful detail.

## Planning a five-person round

**1. Write a research goal.** One or two sentences about what you need to learn, for example: "Understand how parents keep track of library books and due dates, and what goes wrong."

**2. Choose who to talk to.** Write two or three criteria, such as "borrowed at least three books in the last two months" and "has children under 12". Five participants who match is a sensible first round. Patterns usually appear by the fourth or fifth conversation, and more people per round give diminishing returns.

**3. Write a discussion guide.** This is a loose script, not a questionnaire:

```text
Intro (2 min)
  Thanks, purpose, no right answers, ask permission to take notes or record.
Warm-up (3 min)
  Tell me a little about how often you use the library.
Main topic (20 min)
  Tell me about the last time you borrowed books for your kids.
  How did you know when they were due?
  Tell me about a time a book came back late. What happened?
  What do you do today to keep track? Show me if you can.
Wrap-up (5 min)
  Is there anything I should have asked but didn't?
  Thanks; explain what happens next.
```

Use the **funnel technique**: start broad, then narrow to specific topics. Leave room to follow interesting tangents.

**4. Recruit.** For practice, friends of friends, classmates or online community members who match your criteria are fine. Avoid people who already know your idea. Tell them how long it takes (30 minutes) and what you will do with their answers.

**5. Get consent.** Ask before recording or taking photos, explain how notes will be stored, and do not collect more personal information than you need. In a real job your company will have consent forms and data rules; follow them.

## Running the session

- One person asks questions; if possible, a second person takes notes.
- Write down what people **say and do**, using their words, not your interpretation. "I put the receipt on the fridge" is data. "User is disorganised" is a judgement.
- Note emotions and workarounds: sticky notes, spreadsheets, reminders to self. Workarounds point straight at unmet needs.
- If a person asks "What do you think I should do?", turn it back: "What would you expect?"

## Worked example: a weak question rewritten

| Weak question | Problem | Better |
|---|---|---|
| Do you like the library app? | Yes/no, invites politeness | Tell me about the last time you opened the library app. |
| Wouldn't reminders be helpful? | Leading | How do you remember due dates today? |
| How often do you return books late? | Asks for an estimate | Tell me about the most recent late return. |
| Would you pay for this? | Prediction | What have you done or spent to avoid late fees? |

## Common mistakes

- **Pitching your idea.** As soon as you describe your solution, people start giving feedback on it instead of describing their lives.
- **Leading questions.** "Isn't it annoying when...?" tells the person the answer you want.
- **Asking two things at once.** "How do you track due dates and do you use the app for it?" Ask one question at a time.
- **Interrupting silence.** Count to five before you speak again.
- **Only interviewing people like you.** Recruit against your criteria, not from your own team.
- **No notes until later.** Memory fades within hours. Write up each session the same day.

## Quick recap

- Set a research goal, criteria and a discussion guide before you recruit.
- Ask open questions about specific past events, then probe.
- Five participants is a sound first round.
- Record what people say and do, not your judgement, and get consent first.

## Try it

On the Do tab you will choose a project for this course, write a research goal and guide, and run a five-person interview round.


Write a research goal and discussion guide, recruit five people and run interviews that reveal real behaviour.

User interviews

Five User Interview Mistakes to Avoid (in 5 Minutes)

The 3 Types of User Interviews: Structured, Semi-Structured, and Unstructured

Write every observation from your notes on its own sticky note: one fact, quote or behaviour each, tagged with the participant code (P1 to P5). Aim for 40 or more notes.

Spread the notes out and move related ones next to each other without naming any groups yet. Keep moving them until the clusters feel stable.

Name each cluster with a short statement in the user's voice, such as "I forget until it's too late".

Count how many participants appear in each cluster and write the count on the label.

Group related clusters into three to five larger themes.

For each theme, write one insight sentence: what is true, why it matters, and the evidence count.

Write a one-page persona from your strongest themes: name and descriptive line, context, goals, pain points, behaviours, one real quote and an evidence line. Leave out details that would not change a design decision.

Photograph or export the map and persona and keep them; you will use them in every remaining lesson.

## Why it matters

After five interviews you might have a hundred notes. Raw notes do not tell a team what to build. **Synthesis** is the work of turning those notes into a few clear insights that everyone agrees on. Two of the most common synthesis tools are the **affinity map**, which groups observations into themes, and the **persona**, which describes a typical user in a way the whole team can remember.

## The core idea: bottom-up grouping

An affinity map is built from the bottom up. You do not start with categories and sort notes into them. You start with individual observations and let the groups emerge from what is actually there.

1. **One observation per note.** Write each fact, quote or behaviour on its own sticky note (paper, or a free whiteboard such as FigJam's free plan). Add the participant code (P1, P2...) so you can trace it back.
2. **Cluster.** Put notes that feel related next to each other. Do not name the groups yet. Move notes freely.
3. **Name the clusters.** Once clusters settle, give each one a short label written as a statement from the user's point of view, for example "I only remember due dates when it is too late" rather than "Reminders".
4. **Group the groups.** Related clusters form larger themes.
5. **Write insights.** For each theme, write an insight: what is true, why it matters and how strong the evidence is ("4 of 5 participants").

Doing this with two or three people is better than alone: others will see connections you miss, and the team ends up owning the findings.

## Worked example: bill splitting

Notes from five interviews about splitting shared bills included:

- P1: "I screenshot the bill and send it to the group chat."
- P2: Keeps a spreadsheet; housemates never look at it.
- P3: "I don't want to be the one who nags."
- P4: Paid the full internet bill for three months and gave up asking.
- P5: "We use an app but only one of us actually logs things."
- P1: "Chasing money feels awkward with friends."

Clusters that emerged:

| Cluster label | Notes | Count |
|---|---|---|
| "Asking for money feels awkward" | P1, P3, P4 | 3 of 5 |
| "One person does all the tracking" | P2, P4, P5 | 3 of 5 |
| "We already use chat for everything" | P1, P5 | 2 of 5 |

Insight: *The social cost of asking is a bigger problem than the maths. One housemate ends up as the unpaid bookkeeper and often absorbs costs to avoid conflict.* That is a far more useful starting point than "people need a calculator".

## Personas

A **persona** is a short, realistic profile of a type of user, based on research. It helps a team make decisions by asking "would this work for Sam?" instead of "would I like this?". A useful persona fits on one page and includes:

- A name and a short descriptive line ("Sam, the reluctant house bookkeeper").
- Context: situation, devices, how often they face the problem.
- **Goals**: what they are trying to achieve.
- **Pain points**: what gets in the way, linked to your themes.
- **Behaviours and workarounds** you observed.
- A real (anonymised) quote from an interview.

```text
Sam, the reluctant house bookkeeper
Shares a flat with three others; pays the rent and internet, then collects shares.
Goals: get paid back without awkward conversations; spend < 5 min a month on it.
Pain points: housemates ignore the spreadsheet; feels like a nag; absorbs costs.
Behaviours: screenshots bills into the group chat; keeps a private spreadsheet.
Quote: "I don't want to be the one who nags."
Evidence: themes from 4 of 5 interviews.
```

Leave out details that do not affect design decisions. A favourite colour or star sign adds nothing and makes the persona feel fictional.

Some teams prefer lighter **archetypes** or **proto-personas** (written from assumptions before research). Proto-personas are fine as a starting point if they are clearly labelled as assumptions and replaced once you have data.

## Common mistakes

- **Sorting into pre-made categories.** You only find what you expected. Let groups emerge.
- **Multiple ideas per note.** Split them, or the note cannot move to the right cluster.
- **Topic labels.** "Payments" says nothing. "I don't trust the app to remember who paid" is an insight.
- **Invented personas.** A persona with no research behind it is fiction that sounds like evidence.
- **Too many personas.** Start with one primary persona; add another only if their needs truly conflict.
- **Stereotypes.** Base details on what you observed, not on assumptions about age, gender or background.

## Quick recap

- Synthesis turns raw notes into a few insights the team agrees on.
- Affinity maps are built bottom-up: one note per observation, cluster, then label.
- Write cluster labels and insights from the user's point of view, with evidence counts.
- A persona is a one-page, research-based profile with goals, pain points, behaviours and a quote.

## Try it

On the Do tab you will turn your interview notes into an affinity map and a persona.


Turn raw interview notes into themes with an affinity map, then capture what you learned in an evidence-based persona.

Synthesis and personas

Affinity Diagramming: Collaborate, Sort and Prioritize UX Ideas

Personas 101

Learn what UX is, then plan and run interviews and turn the notes into an affinity map and a persona.

User Research

Write the persona, one scenario with a clear start and end, and "current state" at the top of the sheet.

List five to seven stages from start to end as columns.

Add rows for actions, touchpoints, thoughts, emotions and pain points. Fill in actions and touchpoints from your interview notes, including steps that happen outside any product.

Fill in thoughts, using real quotes from interviews wherever you can.

Draw the emotion line across the stages, from positive at the top to negative at the bottom.

Mark each pain point at the low points and note which participants it came from.

Under the two lowest points, write two or three opportunities each, starting with "How might we...".

Circle the single pain point you will design for in the rest of the course, and write one sentence on why.

## Why it matters

Interviews and personas tell you who your user is. A **journey map** tells you what they go through over time to reach a goal, including the parts that happen away from your product. It shows the team where things go wrong, which is where design effort pays off. Journey maps are also one of the best tools for getting a whole team (design, engineering, support, management) to see the same picture.

## The core idea: one persona, one scenario, over time

A journey map always answers three questions first:

- **Who?** One persona (or one clear user type).
- **What scenario?** One goal with a start and an end, such as "Sam collects this month's internet bill from three housemates".
- **Current state or future state?** A current-state map shows what happens today, based on research. A future-state map shows what you want to happen after your design. Start with current state.

Then the map is laid out as a grid. Columns are **stages** of the journey, left to right. Rows are **lenses**:

| Row | What goes in it |
|---|---|
| Actions | What the user does at each stage |
| Touchpoints | Where it happens: app, chat, email, in person |
| Thoughts | What they are thinking, ideally real quotes |
| Emotions | A line rising and falling between positive and negative |
| Pain points | Problems and frustrations |
| Opportunities | Ideas for improvement (added last) |

The emotion line is what makes journey maps memorable. The low points are your pain points, and they become the focus of design.

## Worked example: collecting the internet bill

Persona: Sam, the reluctant house bookkeeper. Scenario: collect three shares of a 60 dollar internet bill. Current state.

| Stage | Bill arrives | Work out shares | Ask housemates | Wait | Get paid (or not) |
|---|---|---|---|---|---|
| Actions | Opens email, downloads PDF | Divides by four in calculator | Screenshots bill into group chat | Checks bank app daily | Marks spreadsheet, chases one person |
| Touchpoints | Email | Calculator | Group chat | Bank app | Spreadsheet, chat |
| Thoughts | "Again already?" | "Easy enough." | "I hope this doesn't sound pushy." | "Did they see it?" | "I'll just pay it myself." |
| Emotion | Neutral | Neutral | Low | Lower | Lowest |
| Pain points | | | Feels like nagging | No visibility of who has seen it | Absorbs cost to avoid conflict |

Reading the emotion line, the worst moments are not the maths. They are asking and chasing. Opportunities follow directly: *let the request come from "the house" rather than Sam*, *show who has seen and paid without Sam asking*, *make paying one tap from the request*. Each opportunity is tied to a pain point and to evidence from interviews.

## How to make one

1. Pick the persona, scenario and scope. Write them at the top.
2. List the stages from start to end. Five to seven stages is typical.
3. Fill in actions and touchpoints from your interview notes.
4. Add thoughts, using real quotes where you have them.
5. Draw the emotion line.
6. Mark pain points at the low points.
7. Only now, add opportunities beneath the pain points.
8. Share it with someone who was not involved and ask what they would fix first.

Paper and sticky notes work perfectly. Digital templates are available in free whiteboard tools.

## Journey maps vs. other maps

- A **user flow** (lesson 3 of this module) zooms in on the screens and decisions inside one product task.
- An **experience map** covers a general human activity, not tied to one product.
- A **service blueprint** adds backstage processes: staff, systems and policies.

Pick the zoom level that matches your question.

## Common mistakes

- **Mixing personas or scenarios.** Two personas on one map produce an average journey that is true for nobody.
- **Inventing the content.** A current-state map with no research behind it is a guess. Mark assumptions clearly if you must use them.
- **Only mapping your product.** Many pains happen outside the app (in the group chat, at the bank). Include them.
- **Jumping to solutions too early.** Fill in what happens first; add opportunities last.
- **Making it a poster and forgetting it.** A journey map is useful when it drives a decision: pick the top one or two pain points to design for.

## Quick recap

- A journey map shows one persona working through one scenario over time.
- Stages run across; actions, touchpoints, thoughts, emotions and pain points run down.
- The emotion line's low points are where design will have the most impact.
- Add opportunities last, each linked to a pain point.

## Try it

On the Do tab you will map the current-state journey for your persona and choose the pain point you will design for.


Map a user's journey across stages, actions, thoughts and feelings, and mark the pain points and opportunities.

Journey maps

Customer Journey Mapping 101

The 5 Steps to Customer Journey Mapping

List 20 to 30 pieces of content or features your product might contain, based on your persona and journey map.

Write each item on its own card in plain words. Check that no two cards share a giveaway word like "Money:".

With each participant, shuffle the cards and ask them to group them in any way that makes sense, then name each group. Allow a "not sure" pile and ask them to think aloud.

Photograph or write down every participant's groups and names, plus any cards they hesitated over.

Make a table of card pairs that were grouped together by most participants, and list the group names used most often.

Draft a sitemap with three to seven top-level sections, using participants' words for labels. Keep it no more than three levels deep.

For each card that participants placed in very different groups, decide on one home and note whether it needs a cross-link.

## Why it matters

People cannot use what they cannot find. **Information architecture (IA)** is the structure and labelling of content: what goes where, what it is called, and how sections relate. Good IA feels invisible; people click the right menu first time. Poor IA makes people guess, search, give up or call support. It also matters to developers, because the IA becomes routes, menus and page templates.

## The core idea: organise by the user's mental model

Teams naturally organise content the way their company is organised ("Billing team pages", "Product team pages"). Users do not know or care about your org chart. They have a **mental model**: their own idea of what belongs together and what things are called. IA work is about discovering that model and building the structure around it.

IA has three parts:

- **Organisation**: how items are grouped (by task, topic, audience, time...).
- **Labelling**: the words used for groups and links.
- **Navigation**: how people move between them (menus, breadcrumbs, links, search).

## Card sorting

A **card sort** is the classic way to learn users' mental models. You write each content item on a card and ask people to group them.

- **Open card sort**: participants make their own groups and name them. Use it early to discover how people think.
- **Closed card sort**: participants sort cards into categories you provide. Use it later to check whether your proposed structure works.

How to run an open card sort:

1. Choose 20 to 40 content items from your product idea. Write each on a card using plain words, not the category name you have in mind.
2. Recruit five or more participants (more improves confidence; 15 or so is common for a real study).
3. Ask each person to put the cards into groups that make sense to them and name each group. Tell them there are no wrong answers and they can make a "not sure" pile.
4. Ask them to think aloud. Note hesitations and cards they move several times.
5. Record every group and its cards.

Paper index cards are perfect. Free tiers of online card-sorting tools exist for remote sorts, but limits change, so check before you rely on one.

## Worked example: a house-sharing app

Twelve cards included: *Split a bill, Who owes what, Add a housemate, Chore rota, House rules, Bin day reminder, Payment history, Leave the house, Notification settings, Shared shopping list, Move-out checklist, Contact landlord*.

Five participants produced groups. A simple table of how often two cards were grouped together (a similarity matrix) showed strong patterns:

| Card pair | Grouped together |
|---|---|
| Split a bill + Who owes what | 5 of 5 |
| Who owes what + Payment history | 5 of 5 |
| Chore rota + Bin day reminder | 4 of 5 |
| Add a housemate + Leave the house | 4 of 5 |
| House rules + Contact landlord | 3 of 5 |

Group names participants used most: "Money", "Jobs around the house" and "The house" (or "Our place"). The team had planned a menu called "Finance", "Tasks" and "Admin". The research suggested friendlier labels.

## From card sort to sitemap

A **sitemap** is a diagram of the structure: the top-level sections, what sits under each, and how deep it goes.

```text
Home
├── Money
│   ├── Split a bill
│   ├── Who owes what
│   └── Payment history
├── Jobs
│   ├── Chore rota
│   ├── Bin day reminders
│   └── Shopping list
├── Our house
│   ├── Housemates (add, leave)
│   ├── House rules
│   ├── Contact landlord
│   └── Move-out checklist
└── Settings
    └── Notifications
```

Good sitemap habits:

- Keep the top level small: about three to seven sections.
- Prefer a broad, shallow structure over a deep one; every extra level is another click and another guess.
- Use the labels participants used, not internal jargon.
- Put an item where most people expected it. If it is split evenly, consider a cross-link from the second place.

## Common mistakes

- **Organising by org chart.** Users do not know your departments.
- **Clever labels.** "Hub", "Spaces" and "Explore" sound modern but say nothing. Plain words win.
- **Cards that give away the answer.** If three cards start with "Money:", people will group them by the word, not the meaning.
- **Treating card sort results as final.** A card sort shows tendencies. Check your sitemap with a **tree test** (people find items in a text-only version of the structure) before building.
- **Too deep.** Five levels of menus hides content.

## Quick recap

- IA is organisation, labelling and navigation, built around users' mental models.
- Open card sorts discover groups and labels; closed card sorts check a proposed structure.
- Look for strong pairings and common group names, then draft a broad, shallow sitemap.
- Use users' words for labels, and test the structure before building it.

## Try it

On the Do tab you will run an open card sort with paper cards and draft a sitemap for your project.


Use an open card sort to learn how users group content, then turn the results into a sitemap with clear labels.

Information architecture

Information Architecture: 3 Key Models

Card Sorting: Why & When

Write the task, persona, realistic entry point (for example a notification or link) and success state at the top.

Draw the happy path with an oval for start and end, rectangles for screens and labelled arrows for actions.

Count the steps. Remove or merge at least one step, or write why each one is needed.

Add every decision point as a diamond, including system checks such as "logged in?" or "input valid?".

Add at least two unhappy paths (for example invalid input and a network failure) and the screen state or message for each.

Trace every branch with your finger and fix any that do not reach an end.

Walk a friend through the flow as your persona and note any step they question.

## Why it matters

Before you design screens, you need to know which screens exist and how a person moves between them. A **user flow** is a diagram of the path someone takes through your product to complete a task: where they start, the steps and decisions along the way, and where they end. Flows catch problems early, such as dead ends, missing error states and unnecessary steps, when changing them costs a pencil line rather than a sprint of development.

## The core idea: one task, one entry, one goal

A flow is always about a single task with a clear **entry point** and a clear **success state**. "Use the app" is not a flow. "Sam requests a housemate's share of the internet bill, starting from a notification that the bill has arrived" is.

Terms you will hear:

- **Task flow**: a single, linear path for one task with no branches. Good for a first pass.
- **User flow**: the same task with decisions and branches, for example what happens if the person is not logged in or a payment fails.
- **Wireflow**: a flow drawn with small wireframes instead of boxes (useful once you start sketching screens).

## Standard shapes

You do not need special software. Most teams use a few simple shapes:

| Shape | Meaning |
|---|---|
| Rounded box or oval | Start or end |
| Rectangle | A screen or page |
| Diamond | A decision (yes/no, valid/invalid) |
| Arrow | Movement, labelled with the action ("taps Send") |
| Small note | System action, such as "sends email" |

Keep arrows going one direction (left to right or top to bottom) where possible, and label each arrow with what the user does.

## Worked example: request a share of a bill

Entry: Sam taps a notification "Internet bill added". Goal: all housemates have been asked to pay.

```text
(Start: taps notification)
  -> [Bill detail screen]
  -> taps "Split"
  -> [Split screen: equal split pre-filled]
  -> <Split equally?> -- no --> [Edit amounts] -> <Totals match bill?> -- no --> [Inline error: "Shares add up to 55, bill is 60"] -> back to [Edit amounts]
                                                                       -- yes --> [Review]
                     -- yes --> [Review]
  -> taps "Send requests"
  -> (system: posts request to house feed, notifies housemates)
  -> [Confirmation: "Requests sent. We'll remind them in 3 days."]
  -> (End: success)
```

Drawing this exposed three questions the team had not answered:

1. What if a housemate has left the house since the bill period? (New decision: who is included.)
2. What does Sam see if the network drops on "Send"? (New error state.)
3. Does Sam need the Review screen, or can the split screen show a summary? (Possible step to remove.)

Every one of those questions is cheaper to answer now than after screens are designed.

## How to draw a flow

1. Write the task, the persona, the entry point and the success state at the top.
2. Draw the **happy path** first: the shortest route when everything goes right.
3. Count the steps. For each, ask "is this step necessary?" Remove or merge where you can.
4. Add decisions: where the user chooses, and where the system checks something (logged in? valid input? enough balance?).
5. Add the **unhappy paths**: errors, empty states, cancel and back. Each one needs a screen state or message.
6. Check every branch reaches an end. A branch with no end is a dead end for a real user.
7. Walk through it with your persona: does each step make sense from where they are?

Paper is fine. Free diagramming tools such as FigJam on the free plan, or the free diagrams.net, make it easier to edit.

## Common mistakes

- **Mapping the whole app at once.** Flows get unreadable. One task per flow.
- **Only the happy path.** Real users mistype, lose connection, cancel and come back later. Those paths need design too.
- **Unlabelled arrows.** An arrow should say what triggers it: a tap, a choice or a system event.
- **Starting at the home screen every time.** Many real tasks start from a notification, an email link or a search result. Use the realistic entry point.
- **Mixing a flow with a sitemap.** A sitemap shows structure (what exists). A flow shows a path through it (what someone does).

## Quick recap

- A user flow shows how one person completes one task, from a real entry point to a success state.
- Use simple shapes: ovals for start/end, rectangles for screens, diamonds for decisions, labelled arrows.
- Draw the happy path, trim steps, then add decisions and error paths.
- Every branch must reach an end.

## Try it

On the Do tab you will diagram the flow for the key task in your project, including at least two error paths.


Diagram the screens, decisions and error paths a user goes through to complete one task in your product.

User flows

User Journeys vs. User Flows (And When to Use Each)

User Flow Diagram Basics

Map the user's journey, organise content with a card sort and a sitemap, and diagram the task flows you will design.

Defining the Problem

Pick the three screens from your flow that matter most for the task and write the goal of each in one sentence.

For the most important screen, fold a sheet into eight panels and do Crazy 8s: eight different sketches in eight minutes.

Circle the best ideas from your eight sketches and combine them into one layout.

Wireframe all three screens at phone size with real headings, labels and example data (no lorem ipsum).

Check hierarchy: on each screen, make sure exactly one element is clearly primary.

Add at least one state that your flow needs, such as an error, empty or loading state.

Annotate any behaviour you cannot draw in the margin.

Show the three screens to someone for 10 seconds each and ask what they think each screen is for. Note any mismatch with your goal sentences.

## Why it matters

A **wireframe** is a simple drawing of a screen that shows what goes where: content, controls and their priority, without colour, images or polish. Wireframes let you test structure and content cheaply. When something looks rough, people comment on whether it works ("I can't find the total") instead of how it looks ("I don't like that blue"). That is exactly the feedback you need at this stage.

## The core idea: fidelity matches the question

**Fidelity** is how close a design is to the final product.

| Fidelity | Looks like | Good for |
|---|---|---|
| Low | Pen sketches or grey boxes, real-ish words | Layout, content, priority, flow; many options fast |
| Mid | Clean grey-scale screens in a tool | Spacing, components, realistic content |
| High | Final colour, type and imagery | Visual polish, brand, final sign-off |

Start low. You should be able to throw a low-fidelity wireframe away without regret. Move up only when the questions you are asking need it.

## What goes into a wireframe

- **Real content**, or close to it. Write the actual heading, button label and an example amount. "Lorem ipsum" hides problems, such as labels that are too long or a missing total.
- **Priority**. Make the most important element obvious (larger, higher or bolder), as you learned in Visual Design Fundamentals.
- **Standard placeholders**. A box with a cross for an image, horizontal lines for body text, rounded rectangles for buttons.
- **States** that matter: an empty list, an error message, a loading state, where the flow needs them.
- **Annotations**: short notes in the margin for behaviour you cannot draw, such as "pre-filled with equal split" or "only shows if a housemate owes money".

## Worked example: three screens for the bill flow

From the user flow in the last lesson, the three key screens are Bill detail, Split and Confirmation.

**Bill detail**
```text
+--------------------------------+
| <  Internet - October          |
|                                |
|   $60.00                       |  <- largest element
|   Due 28 Oct  ·  Paid by Sam   |
|                                |
|  [ Split this bill ]           |  <- primary button
|                                |
|  View PDF                      |  <- secondary link
+--------------------------------+
```

**Split**
```text
+--------------------------------+
| <  Split $60.00                |
|  Split equally  (o) yes ( ) no |
|  Sam (you)        $15.00       |
|  Priya            $15.00       |
|  Leo              $15.00       |
|  Jordan           $15.00       |
|  Total            $60.00  ok   |  <- turns red if totals differ
|  [ Send requests ]             |
+--------------------------------+
Note: housemates who left before the bill date are not listed.
```

**Confirmation**
```text
+--------------------------------+
|        (tick)                  |
|   Requests sent to 3 people    |
|   We'll remind them in 3 days. |
|   [ Back to the house ]        |
+--------------------------------+
```

Notice the decisions made on paper: the amount is the hero on Bill detail; the total check is visible on Split so the error from the flow has a home; the confirmation reassures Sam that the app, not Sam, will do the chasing, which addresses the "nagging" pain point.

## Crazy 8s for options

Before settling on one layout, sketch options fast. In **Crazy 8s** you fold a sheet into eight panels and sketch eight versions of one screen in eight minutes. Most will be bad. One or two will contain an idea you would never have reached by polishing your first attempt.

## Paper or Figma?

Both work. Paper is fastest for exploring. Figma's free plan is good once you want to rearrange, duplicate and later link screens into a prototype (next lesson). In Figma, use a phone-sized frame, grey rectangles and plain text; avoid colour for now. Free wireframe kits are available in the Figma Community.

## Common mistakes

- **Starting in high fidelity.** You will defend pixels instead of testing ideas.
- **Placeholder text everywhere.** Real words reveal real problems.
- **No hierarchy.** Every element the same size and weight; nothing reads first.
- **Designing one perfect option.** Sketch several before choosing.
- **Forgetting states.** The empty, error and loading versions are part of the design.
- **Decoration.** Shadows, gradients and icons distract from structure at this stage.

## Quick recap

- Wireframes show layout, content and priority without visual polish.
- Match fidelity to the question; start low.
- Use real content, clear priority, standard placeholders and short annotations.
- Explore several options (for example with Crazy 8s) before refining one.

## Try it

On the Do tab you will sketch options and then wireframe the three key screens of your flow.


Sketch low-fidelity wireframes for the three key screens of your flow, focusing on layout, content and priority.

Wireframes

Prototypes vs Wireframes in UX Projects

How To Create Your First Wireframe (A UX Tutorial)

Write the one question your prototype must answer, for example "Can people split a bill unequally without help?".

List the screens and states needed to answer it, including any extra frames that fake logic (such as an error state).

Put each screen in its own phone-sized frame (or on its own sheet of paper) and name it.

In Figma's Prototype tab, connect every button on the tested path to its destination and set the first frame as the flow's starting point.

Add back navigation from every screen so a wrong tap is recoverable.

Give every other visible button a response, even if it only shows a "not part of this test" frame.

Present the prototype and click through every path yourself.

Pilot it with one person: give them the task, say nothing, and note every place they hesitate or tap something that does not respond.

## Why it matters

A wireframe shows a screen. A **prototype** lets someone use it. When people tap through a prototype, they reveal problems no static picture can: buttons they do not notice, steps they did not expect, and moments where they do not know what to do next. A prototype is also the clearest way to explain a flow to stakeholders and developers. Clicking through takes a minute; reading a spec takes much longer.

## The core idea: just enough to answer a question

A prototype is a question in disguise. Before you build one, write what you want to learn: "Can people split a bill unequally without help?" Then build only what is needed for that question. A prototype does not need every screen, real data or working logic. It needs the path being tested, plus enough surrounding screens that people do not hit a wall immediately.

Prototypes come in fidelities too:

- **Paper prototype**: hand-drawn screens; a person plays "the computer" and swaps paper when the participant taps. Very fast and surprisingly effective.
- **Clickable wireframes**: grey-scale screens linked with hotspots.
- **High-fidelity prototype**: close to the real look, with transitions and realistic content.

## Prototyping in Figma (free plan)

Figma's free Starter plan includes prototyping. The basic steps:

1. **Frames are screens.** Put each wireframe in its own phone-sized frame (Frame tool, then choose a phone preset).
2. **Switch to Prototype mode.** In the right-hand panel, open the Prototype tab.
3. **Add connections.** Select a button or hotspot; drag the small circle that appears onto the destination frame. Each connection is an **interaction**: a trigger (On click/tap), an action (Navigate to) and an optional animation (Instant, Dissolve, Smart animate).
4. **Set a starting point.** The first frame of the flow becomes the flow's starting point. You can have several flows in one file.
5. **Add back navigation.** Connect back arrows using the "Back" action so people can recover.
6. **Present.** Press the play button to preview, or share the prototype link with test participants.

Keep transitions simple ("Instant" or "Dissolve"); fancy animations take time and rarely answer your question.

## Worked example: the bill-split prototype

Question: *Can people split a bill unequally and send requests without help?*

Screens needed: Bill detail, Split (equal), Split (edit amounts), Split (totals do not match error), Review, Confirmation, plus a simple Home so participants have a realistic start.

Connections:

| From | Hotspot | To |
|---|---|---|
| Home | Notification card "Internet bill added" | Bill detail |
| Bill detail | "Split this bill" | Split (equal) |
| Split (equal) | "No" radio | Split (edit amounts) |
| Split (edit amounts) | "Send requests" | Split (error) |
| Split (error) | "Fix amounts" | Review |
| Review | "Send requests" | Confirmation |

Notice the trick in row 4: the prototype cannot calculate, so the first press of Send always shows the error state. In a test, you set up a scenario ("Leo owes 20, the others share the rest") that leads people to that state naturally. Prototypes often fake logic with extra frames like this.

## Making prototypes testable

- Use realistic content that matches your test scenario (names, amounts, dates).
- Make sure every visible button on the tested path does something, even if it only shows a "Not part of this test" message. Dead buttons confuse participants and spoil data.
- Put a frame number or name on each screen in the file so you can follow along during a test.
- Click through the whole prototype yourself, then ask one person to try it before a real session.

## Common mistakes

- **Prototyping everything.** Weeks spent wiring an entire app. Build what answers the question.
- **Polishing before testing.** High fidelity too early makes it painful to change.
- **Hotspots that are too small or missing.** Participants tap a label instead of the button; nothing happens; the test stalls.
- **No way back.** Without back links, one wrong tap ends the session.
- **Testing the prototype tool instead of the design.** If people are confused by the prototype's limits, say so up front and design the scenario around them.

## Quick recap

- A prototype lets people use a design so you can watch what happens.
- Start from a question and build only the screens and links needed to answer it.
- In Figma: frames as screens, Prototype tab, drag connections, set a starting point, present.
- Fake logic with extra frames, make every visible control respond, and pilot before testing.

## Try it

On the Do tab you will turn your wireframes into a clickable prototype and pilot it with one person.


Link your screens into a clickable prototype in free Figma so people can try the flow before anything is built.

Interactive prototypes

Figma For Beginners: Build prototypes (3/4)

Pencils vs. Pixels for UI Protyping and Sketching

## Why it matters

You will not always have time or budget to test every screen with users. **Heuristic evaluation** is a fast way to find many usability problems by inspecting a design against a set of well-known principles. **UI patterns** are proven solutions to common problems, such as tabs, steppers and inline validation, that people already know how to use. Together they let you catch obvious problems before you spend participants' time on them.

## The core idea: Nielsen's ten heuristics

Jakob Nielsen published ten "usability heuristics" in the 1990s. They are rules of thumb, not strict rules, and they are still the most widely used checklist in UX.

1. **Visibility of system status.** Keep people informed about what is happening, with timely feedback. Example: a progress indicator while a payment sends.
2. **Match between the system and the real world.** Use the user's words and familiar concepts. Example: "Who owes what" instead of "Outstanding receivables".
3. **User control and freedom.** Provide clear exits: undo, cancel, back. Example: "Undo" after deleting a bill.
4. **Consistency and standards.** Follow platform conventions and be consistent within your product. Example: the primary button always looks and sits the same way.
5. **Error prevention.** Prevent problems before they happen. Example: disable "Send" until shares add up to the total, or pre-fill an equal split.
6. **Recognition rather than recall.** Show options instead of making people remember them. Example: show housemates' names to choose from instead of asking for their email addresses.
7. **Flexibility and efficiency of use.** Offer shortcuts for frequent users without confusing new ones. Example: "Split like last month".
8. **Aesthetic and minimalist design.** Remove information that competes with what matters. Example: hide the bill's PDF metadata behind "Details".
9. **Help users recognise, diagnose and recover from errors.** Error messages in plain language that say what went wrong and how to fix it. Example: "Shares add up to $55. The bill is $60." rather than "Error 422".
10. **Help and documentation.** Ideally not needed, but if it is, make it short, searchable and in context. Example: a one-line tip beside "Split unequally".

## How to run a heuristic evaluation

1. Choose the flow or screens to review and the user's goal.
2. Walk through the flow at least twice: once to get a feel for it, once to inspect each element.
3. For each problem, write: where it is, what the problem is, which heuristic it breaks, and a **severity** rating (for example 0 = not a problem, 1 = cosmetic, 2 = minor, 3 = major, 4 = catastrophic: blocks the task).
4. Have three to five evaluators work independently, then merge their lists. One person typically finds only around a third of the problems.
5. Prioritise by severity and fix the biggest first.

Heuristic evaluation finds many problems, but not all, and it can flag things real users do not mind. It complements usability testing; it does not replace it.

## Worked example: an evaluation table

| Location | Problem | Heuristic | Severity |
|---|---|---|---|
| Split screen | Totals can differ from the bill with no warning until Send | 5 Error prevention | 3 |
| Error after Send | Message says "Validation failed" | 9 Error recovery | 3 |
| Confirmation | No sign of when reminders will go out | 1 System status | 2 |
| Bill detail | Delete has no undo | 3 Control and freedom | 3 |
| Menu | "Ledger" label | 2 Real-world match | 2 |

## Common UI patterns

Patterns save you from reinventing solutions. A few you will use constantly:

- **Inline validation**: check a field when the user leaves it, with the message next to the field.
- **Stepper (wizard)**: break a long task into numbered steps with progress shown.
- **Empty state**: explain what goes here and offer the first action ("No bills yet. Add your first bill").
- **Undo toast**: a short message after a destructive action with an Undo button.
- **Tabs and segmented controls**: switch between views of the same content.
- **Progressive disclosure**: show the essentials, hide advanced options behind "More options".

Use the standard pattern unless you have strong evidence that something else works better. Familiarity is itself a usability feature (heuristic 4).

## Common mistakes

- **Using heuristics as an opinion shield.** "This breaks heuristic 8" must point to a real problem for the user, not your taste.
- **No severity.** A long unranked list does not help a team decide.
- **One evaluator.** You will miss most issues.
- **Skipping user testing.** Heuristics find likely problems; users show actual ones.
- **Custom controls for standard jobs.** A home-made date picker usually performs worse than the platform's.

## Quick recap

- Nielsen's ten heuristics are a checklist for spotting usability problems quickly.
- Record location, problem, heuristic and severity; merge several evaluators' findings.
- Standard UI patterns are familiar and usually the best starting point.
- Heuristic evaluation complements, and never replaces, testing with users.

## Try it

The Do tab has a quiz that asks you to match real problems to heuristics. Afterwards, review your own prototype against the ten heuristics before you test it in the next module.


Review an interface against Nielsen's ten usability heuristics and use familiar UI patterns to fix what you find.

UI patterns and heuristics

Heuristic Evaluation of User Interfaces

Usability Heuristic 1: Visibility of System Status

Sketch wireframes, link them into a clickable prototype and review it against Nielsen's usability heuristics.

Designing Solutions

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.

UX Design Process

About this course

Course content

User Research

Defining the Problem

Designing Solutions

Validating

Where this course leads

Next course on the path

Careers that use it