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