Understand what user experience design covers and how the double-diamond process moves from research to a tested solution.
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:
- Discover (diverge). Go wide. Talk to users, watch them work, read support tickets and analytics. Collect far more than you need.
- Define (converge). Narrow down. Synthesise what you learned into a clear problem statement: who is struggling, with what, and why it matters.
- Develop (diverge). Go wide again. Sketch many possible solutions, prototype the promising ones, and get feedback early.
- 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.