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.