# Every method on the design process checklist, and when it earns its time.

Ten breeder interviews, a cashier screen I had to rebuild, and all 64 methods of empathise, define, ideate, prototype and test. What each one is for, how to run it, and when to skip it.

https://laithjunaidy.com/writing/design-process-checklist
By Laith Aljunaidy. Published: 2026-10-05.

---

![Wfrah app screens in Arabic: herd evaluation, choosing an animal, and the control panel](https://laithjunaidy.com/writing/wfrah/cover.jpg)

*Wfrah, the herd management app for breeders in the Gulf. The calculator behind these screens came from an interview answer that pointed the wrong way.*

In 2023 I was designing [Wfrah](https://laithjunaidy.com/work/wfrah), an app for sheep and goat breeders in the Gulf. Before any screen existed, the founder, Abdullatif, told us what we were up against. Breeders run the trade the way their fathers taught them, and they do not believe an app knows their animals better than they do.

So we went and listened. Ten in-depth interviews with breeders of different experience, plus time watching the tools they already used. Ask a breeder why the farm loses money and he gives you the same answer every time: feed is expensive and the buyers pay too little.

The interviews showed something underneath that answer. Many breeders could not work out their herd's daily nutritional needs from the equations, and the belief that the market was to blame made them overlook nutrition and management. The most useful thing in the app became a [nutrition calculator](https://laithjunaidy.com/writing/designing-wfrah) that does the maths for each animal and each growth stage. Nobody asked for it. The interviews showed how many needed it.

Three years later I built the cashier counter for [Dot](https://laithjunaidy.com/research/dot), my loyalty app, and the first version was bad. It asked for the amount first, then a country, then the phone, then a button: six taps plus typing, with nothing in focus when the screen opened. The rebuild started from the person, written into the spec in one line: a tired cashier at a busy counter, one hand on the phone and one on the cup. Phone first, the amount field takes focus by itself, and a returning customer now costs two taps.

Same lesson, twice. The screen came out right only after the person came first. That is what a design process is for, and it is why lists like Barbara Vam's [Design Process checklist](https://coconut-baroness-035.notion.site/Design-Process-checklist-7c07a8c25f1a42e385f5205faa8d93a8) exist. Hers holds 64 methods across the five phases of design thinking. This guide walks through every one of them, in her order, with what I have learned using them.

## Key takeaways

- Design thinking has five phases: empathise, define, ideate, prototype, test. It loops back on itself. A failed test usually sends you to define, not to the start.
- No project runs all 64 methods. Each phase has one or two that carry it. Skip those and you are guessing.
- Empathise: interview people about the last time they did the thing, then sort what they said with an affinity map.
- Define: one problem statement and a set of "how might we" questions, written before anyone opens Figma.
- Ideate: draw the user flow before the screens, then cut ideas with a prioritisation matrix.
- Prototype: build the least that answers the open question. Hand off states, not just screens.
- Test: watch five people use it. Measure with SUS. Use A/B tests only when you have the traffic.
- AI helps with drafting, sorting and checking. It cannot replace the person you are designing for.

## How to read this guide

Read the five chapter openings first: what each phase is for, and what breaks when a team skips it. Then use the methods as a reference. Each says what it is, when it earns its time, how to run it, what you walk away with, and the usual mistake. Where a method works well with AI, a short paragraph says how to do it with Claude and what to check.

The free templates along the way share one worked example: Bunn, a fictional coffee app, and Rana, a product designer in Amman who orders coffee for her team.

**Contents**

1. [What are the five phases of the design process?](#what-are-the-five-phases-of-the-design-process)
2. [Empathise: what are people actually doing?](#empathise-what-are-people-actually-doing)
3. [Define: what exactly is the problem?](#define-what-exactly-is-the-problem)
4. [Ideate: how do you get from many ideas to one?](#ideate-how-do-you-get-from-many-ideas-to-one)
5. [Prototype: how much do you build before you know?](#prototype-how-much-do-you-build-before-you-know)
6. [Test: how do you find out if it works?](#test-how-do-you-find-out-if-it-works)
7. [Which templates go with which phase?](#which-templates-go-with-which-phase)
8. [FAQ](#faq)

## What are the five phases of the design process?

The Interaction Design Foundation describes design thinking as a [non-linear, iterative process](https://www.interaction-design.org/literature/topics/design-thinking) that teams use to understand users, challenge assumptions, redefine problems and create solutions. Five phases, each answering one question.

| Phase | The question it answers | Methods on the checklist | The ones I would not skip |
| :- | :- | -: | :- |
| Empathise | What do people actually do, and why? | 12 | User interviews, affinity map |
| Define | Which problem are we solving, for whom? | 12 | Problem statement, how might we |
| Ideate | What could we build, and what goes first? | 19 | User flow, information architecture |
| Prototype | What is the least we can build to learn? | 10 | Wireframes, interactive prototype, handoff |
| Test | Does it work for the people it is for? | 11 | Usability testing, SUS |

A test that fails on wording sends you back to prototype. One that fails because nobody wants the thing sends you back to define.

## Empathise: what are people actually doing?

Empathise is where you stop guessing: who the people are, what they do today, what it costs them, and the words they use for it. A wrong assumption caught here costs a conversation. Caught after launch, it costs the build.

Teams skip it because they think they already know. On Wfrah, the breeders themselves were sure the market was the problem, and the interviews still showed what they were missing. When empathise is skipped, the first version encodes the team's opinion and the second version is spent finding that out.

![User interview script and notes template: 18 questions in five sections beside a notes sheet with quotes, observations and follow ups](https://laithjunaidy.com/store/user-interview/en-light.jpg)

*The free user interview template, filled with the Bunn example. Script on the left, one notes sheet per participant on the right.*

### Define the goal

One sentence on what the project must change and how you will know it did. "Returning customers earn points in under ten seconds" is a goal. "Improve the cashier experience" is a wish. Write it with whoever owns the outcome, with the one number that would prove it, before any research. You walk away with a filter: every method after this serves the goal or waits. The mistake is a goal that names a solution, like "build a loyalty app". GV's [design sprint](https://www.gv.com/sprint/) is a five-day process for answering business questions through design, prototyping and testing, and it opens the same way, with the team agreeing a long-term goal before anyone sketches.

### User interviews

A user interview is one person, one conversation, about what they did, in their words. Nielsen Norman Group's [User Interviews 101](https://www.nngroup.com/articles/user-interviews/) defines it as asking questions, listening and following up to learn who users are, what their experiences are like and what they need. It also names the limit: the data is only as good as the interviewer, and leading questions ruin it.

It earns its time whenever you cannot explain why people behave the way they do. To learn how many do it, use a survey.

**How to run it**

1. Write the research question first: "How do breeders decide what to feed?" Every question in the script must serve it.
2. Recruit five to eight people from the real audience. Not colleagues, not friends who will be kind.
3. Ask about the last time, never about the future. "Walk me through the last time you ordered coffee for the team" gets a story. "Would you use a group order feature?" gets a polite yes.
4. Follow every answer with why, and how, and what happened next. Barbara Vam's own note on this method says it in three words: what, how, why.
5. Stay quiet after each answer. The useful part comes after the pause.
6. Write quotes word for word. Paraphrase is where your opinion sneaks in.

**What you walk away with:** stories, exact quotes, people's own vocabulary, and the workarounds they built because nothing served them.

**The common mistake:** pitching. The moment you show the idea, the interview becomes a sales call and people start protecting your feelings.

The free [interview script and notes](https://laithjunaidy.com/store/user-interview) has 18 questions in five sections, from warm up to "is there anything I should have asked and did not".

**With Claude.** Paste your research question and ask: "Write a 30 minute interview script about the last time this person did the task. No hypothetical questions, no questions that name a feature, and flag any question that suggests its own answer." Then delete every "would you" question it still slipped in. Never let a model play the user; it gives you the average of what it has read.

### Stakeholder interviews

The same conversation, held with the people who own the budget, the system or the risk. Nielsen Norman Group's [Stakeholder Interviews 101](https://www.nngroup.com/articles/stakeholder-interviews/) argues they give you the context and the business goals, and that they increase the stakeholders' support for the work.

Hold them first, before the brief hardens. Ask what success looks like, what failed before, and what they are afraid of. On Wfrah, the founder named the real obstacle before we met a single breeder: distrust of technology. You walk away with the constraints nobody wrote down. The mistake is treating the most senior voice as user research.

### Lean canvas

One page stating the problem, the customer segments, the solution, the unique value, the channels, the revenue, the costs, the key metrics and the unfair advantage. Barbara Vam frames it as a way to document the problem space and act as a catalyst for hypotheses to validate.

Use it while the product is still a bet; skip it on a redesign of a product that already earns. You walk away with the riskiest assumption named, which is what research should test first. Mark the boxes that are guesses. Those are the useful ones.

### Surveys

Fixed questions sent to many people. Use them to measure how common something is after interviews have told you what it is. Run the interviews first, or you will write the options from your own head and measure your own assumptions very precisely.

Keep it under ten questions and pilot it on two people. You walk away with numbers and a few reasons. Nielsen Norman Group's [28 tips for qualitative surveys](https://www.nngroup.com/articles/qualitative-surveys/) argues for open-ended questions when you want to learn more, and for testing every survey before it goes out to remove the problems.


![Survey result in Arabic: are you satisfied with how you buy or sell building materials? Six answers on a scale of one to five, average 2.8](https://laithjunaidy.com/writing/design-process/ibuild-survey-q3.jpg)

*An early iBuild survey question for buyers and suppliers of building materials in Saudi Arabia: are you satisfied with how you buy or sell today? Six answers, average 2.8 out of 5. A signal worth an interview, not a finding.*

### Data analysis

Reading what already exists: support tickets, sales data, search logs, app reviews, old research. It costs the least, so it comes before anything new. You walk away with where to look and the first questions for your interviews.

For [Taken apart, number two](https://laithjunaidy.com/writing/taken-apart-arabic-100) we checked 179 funded MENA startups in order and found 44 percent had no Arabic website. No interview would have produced that number; a careful pass over public data did. The mistake is stopping at the number. Data says where people drop off. It never says why.

### Metrics

The few numbers that say whether the experience is getting better: task success, time on task, conversion, retention, satisfaction. Choose them at the start, record today's value, and you have a baseline to judge the launch against. Nielsen Norman Group's [benchmarking guide](https://www.nngroup.com/articles/benchmarking-ux/) describes exactly this: measuring a product's experience with metrics against a meaningful standard.

On the Dot counter, the measure the spec used was taps per returning customer: six before, two after. Pick numbers that track the user's outcome, the way [nobody wants your product](https://laithjunaidy.com/writing/nobody-wants-your-product) argues. A metric that only tracks clicks will reward the wrong design.

### Competitors

Use the products your users rely on today, including the spreadsheet, the notebook and the WhatsApp group. An afternoon, early, with notes on what each one does well and where it fails. Nielsen Norman Group's case for [competitive usability evaluations](https://www.nngroup.com/articles/competitive-usability-evaluations/) is that seeing what works and fails elsewhere saves you from building useless features.

You walk away with the patterns users already expect and the gaps nobody covers. The mistake is only looking at direct competitors. A breeder's real competitor is his father's notebook.

### Focus groups

Six to nine people discussing a topic with a moderator, for about two hours. Jakob Nielsen's article on [focus groups](https://www.nngroup.com/articles/focus-groups/) is blunt about the limit: they show what people say they do, not what they do, and their proper role is to discover what users want, not to judge usability.

Use them for attitudes, vocabulary and group dynamics. Never use one to judge a design. The loudest person in the room sets the answer, and the rest agree.

### Observations

Watch people do the task where they normally do it: at the counter, in the pen, on their own phone in bad light. Run it whenever the environment shapes the work. Nielsen Norman Group's [field studies](https://www.nngroup.com/articles/field-studies/) article makes the case for leaving the office to learn the unexpected.

On Wfrah, colour and type were tuned for bright sun and low light, because breeders open the app in the pen. You walk away with the workarounds people stopped noticing and so never mention. The mistake is helping. Your job is to watch the struggle.

### Affinity maps

An affinity map takes everything the research produced, one finding per note, and groups the notes by what belongs together until themes appear. Nielsen Norman Group's [guide to affinity diagramming](https://www.nngroup.com/articles/affinity-diagram/) describes it as clustering related observations into themes, and says it works for research findings and for ideas from a workshop alike. They also separate it from card sorting, which is a research method for navigation, not a way to sort your own notes.

Do it straight after research. Without it, the most memorable interview wins the argument, and the most memorable is usually the most extreme.

![Affinity map template: six interviews sorted into five themes for the Bunn coffee app](https://laithjunaidy.com/store/affinity-map/en-light.jpg)

*Six interviews, five themes: speed, price transparency, ordering for others, tracking, repeat orders. Every note carries its participant tag.*

**How to run it**

1. Write one observation per note, in the participant's words where possible, tagged with who said it.
2. Spread every note out. Do not start with categories.
3. Move notes silently into groups. Silence stops the senior person from deciding the themes out loud.
4. Name each group with a sentence that states the finding, such as "The delivery fee shows up late and feels like a trick", rather than a one-word label like "Pricing".
5. Count the participants under each theme. A theme from one person is an anecdote.

**What you walk away with:** five or six themes, each backed by several people.

**The common mistake:** writing interpretations on the notes. "Users want transparency" is your conclusion. "The fee appears at checkout, after I picked everything" is data.

The free [affinity map](https://laithjunaidy.com/store/affinity-map) comes in Arabic and English, light and dark.

**With Claude.** Paste the transcripts and ask: "Extract every observation as one line with the participant ID and an exact quote. Then propose groups. Do not merge anything said by only one participant into a theme." Then check that every note traces to a real quote and no theme is something nobody said. Sorting is what models do well. Filling gaps with plausible findings is what you must catch.

### Context mapping

Participants prepare before the session with small exercises: a diary, photos of their day, a collage. Then they talk you through what they made. The Interaction Design Foundation's page on [context mapping](https://ixdf.org/literature/topics/context-mapping) presents it as a way to reveal user needs and inspire design ideas.

Use it for what people find hard to say out loud: routines, feelings, the setting around a task. You walk away with the life around the task. Never skip the debrief; the photos mean little until the person explains them.

## Define: what exactly is the problem?

Define turns a wall of findings into one decision: which problem, for whom, and why now. It is the narrowest phase and the one teams rush most, because everyone is eager to draw. A team that skips it ships a product that solves several small problems halfway.

On Wfrah, define produced one persona, Awad, and one problem statement: traditional breeders hesitate to adopt new tools even when the gains are real, while struggling with nutrition, environment and admin. Every screen after that had to earn trust before it asked for anything. One sentence did that work.

![Awad, the fictional breeder persona from the Wfrah research, crouching beside a ram in a pen](https://laithjunaidy.com/writing/wfrah/persona.jpg)

*Awad. A fictional persona built from ten real interviews: proud of his family's methods, curious whether there is a better way.*

### Personas

A persona is a fictional, realistic profile of one type of user, built from research: goals, context, behaviours, frustrations, and a line in their own words. Nielsen Norman Group's [personas article](https://www.nngroup.com/articles/persona/) argues they work because people are more captivated by one concrete person than by a range of numbers, and that a good one is based on concrete research.

It earns its time when the team says "the user" and each person means someone different. Before anyone has talked to a user, it is fiction with a stock photo.

**How to run it**

1. Start from the affinity map. Each persona should be a cluster of behaviour you actually saw, not a demographic.
2. Write goals and frustrations as the participants said them.
3. Add the context that changes design: device, place, time pressure, language.
4. Pick a quote that holds the tension. Awad says technology seems too complicated, and that he is open to trying new things if they help. That tension was the brief.
5. Make one primary persona. Two at most. Five personas means no decision has been made.

**What you walk away with:** one person to design for, and a test for every review: would Awad understand this screen?

**The common mistake:** borrowing a template's persona. A persona translated from an English template records what the English author expected. The Arabic version of the free [persona template](https://laithjunaidy.com/store/persona) was written in Arabic for that reason, with a bio that reads like someone from Amman.

**With Claude.** Give it the affinity map and ask: "Draft one persona using only facts in these notes. Mark every line with the participant IDs it comes from. Leave a field empty when the notes do not support it." Delete anything with no ID. A model will happily give your persona a hobby and a dog.

![User persona template in Arabic for Rana, a product designer in Amman, with goals, frustrations and behaviours](https://laithjunaidy.com/store/persona/ar-light.jpg)

*The Arabic persona template. Written in Arabic, right to left, not translated on top of a Latin layout.*

### Empathy map

Four quadrants: what the user says, thinks, does and feels. Fill it as a team straight after interviews. Nielsen Norman Group's [empathy mapping article](https://www.nngroup.com/articles/empathy-mapping/) argues it builds a shared picture of the user and shows the gaps in what you know. The most useful output is where says and does meet: Rana calls the late fee a trick, and she checks it twice before paying. Free [empathy map template](https://laithjunaidy.com/store/empathy-map). The mistake is filling "thinks" and "feels" with guesses; leave them empty where you have no evidence.

### User journey map

A journey map is the whole experience over time, from first hearing of the product to leaving it or coming back, with what the person does, thinks and feels at each stage. Nielsen Norman Group's [Journey Mapping 101](https://www.nngroup.com/articles/journey-mapping-101/) defines it as a visualisation of the process a person goes through to accomplish a goal, built from a timeline of actions with thoughts and emotions added.

Use it when the problem crosses channels or teams: a reel, an app, a courier, a notification. Skip it when the problem lives inside one screen.

![Customer journey map template for Bunn with five stages, goals, actions, thoughts, an emotion curve, pain points and metrics](https://laithjunaidy.com/store/customerjourney/en-light.jpg)

*Five stages from discover to reorder. The emotion curve bottoms out at the order step, where the OTP arrives late.*

**How to run it**

1. Pick one persona and one goal. A journey for everyone is a journey for no one.
2. Lay out the stages as the user names them, not as your org chart does.
3. Fill actions and touchpoints from research, then thoughts in quotes.
4. Plot emotion stage by stage. The lowest point is where to start.
5. Add one opportunity and one metric per stage, so the map ends in work.

**What you walk away with:** the moment that hurts most. On Bunn, the low point is the order step: the OTP arrives late and the field does not read it.

**The common mistake:** mapping the journey you designed instead of the one people take. Free [customer journey map](https://laithjunaidy.com/store/customerjourney), in Arabic and English, light and dark.

### User stories

"As a [user], I want [action], so that [outcome]." Write them when work moves into the backlog, so each item keeps the user and the reason attached. The GOV.UK Service Manual's guide to [writing user stories](https://www.gov.uk/service-manual/agile-delivery/writing-user-stories) treats them as the record of everything a team has to do to build a service that meets user needs. The mistake is stories with no "so that". Without it, nobody can tell if the feature worked.

### Problem statement

A problem statement says who is stuck, at what moment, and what it costs them, in one sentence. Nielsen Norman Group's [problem statements article](https://www.nngroup.com/articles/problem-statements/) argues that teams who start discovery without one meander, and that some start by investigating solutions, which is not discovery at all. Write one on every project. It is the cheapest insurance in this guide.

![Problem statement and how might we template for Bunn: five blanks, the resolved sentence, a jobs to be done block and six how might we questions](https://laithjunaidy.com/store/problem-statement/en-light.jpg)

*One sentence, built from five blanks, followed by the job and six how might we questions.*

**How to run it**

1. Fill five blanks from research: user, needs to, because, but, which makes them feel.
2. Read the sentence aloud. If it sounds like a feature request, the "because" is missing.
3. Check it against the affinity map. Every part should trace to a theme.
4. Agree on it with the people who will build. If they cannot repeat it, it is too long.

**What you walk away with:** the scope. "Rana needs to order coffee for three people in under a minute because the 10:00 meeting starts on time, but the delivery fee only appears at checkout, which makes her feel tricked." Everything that does not serve that sentence waits.

**The common mistake:** hiding a solution inside it. "Users need a better dashboard" names the answer and skips the problem. Free [problem statement template](https://laithjunaidy.com/store/problem-statement).

**With Claude.** Paste the affinity themes and ask for three candidate problem statements in the five-blank format, each citing the theme it comes from. Then pick one yourself. Drafting options is the model's job. Choosing the problem is yours.

### Hypothesis statement

"We believe [change] for [users] will achieve [outcome]. We will know when [signal]." Use it when a solution is already on the table and needs testing instead of defending. Write the pass condition before the result is in, so nobody moves the goalposts. For the Dot counter it would read: we believe putting the phone first will bring a returning customer down to two taps, and we will know when a cashier does it on the shipped screen.

### Narratives

A short story in prose of one person's day with the product in it. Use them to show a stakeholder where the product enters a real routine. Keep them tied to research. Nielsen Norman Group's article on [narrative biases](https://www.nngroup.com/articles/narrative-biases/) warns that UX practitioners over-trust narrative detail and cause-and-effect explanations. A good story persuades whether or not it is true, so every sentence should trace to something a user did.

### HMW method

"How might we" rewrites each problem as a question open enough for several answers and narrow enough to act on. Nielsen Norman Group's [how might we article](https://www.nngroup.com/articles/how-might-we-questions/) argues the format stops people pushing pet solutions that have little to do with the problems found, and keeps ideation focused on the right problem.

Use it at the end of define, as the bridge into ideation. Before a problem statement exists, it only phrases guesses as questions.

**How to run it**

1. Take the problem statement and each strong theme from the affinity map.
2. Write one question per pain: "How might we show the delivery fee before Rana picks a drink?"
3. Check the width. "How might we make coffee better?" is too wide. "How might we add a fee label to the header?" is a solution in disguise.
4. Under each question, write one line on what it opens, without naming a feature.
5. Vote on three to take into ideation.

**What you walk away with:** briefs for ideation, each pointing at a real pain. **The common mistake** is too many. Twenty HMWs is a backlog, not a brief. The free [problem statement template](https://laithjunaidy.com/store/problem-statement) holds six. **With Claude**, ask it to rewrite your list so that none names a solution and none is wider than one moment in the journey; then check it did not quietly change the problem.

### Assumptions mapping

List everything that must be true for the idea to work, then place each item on two axes: how important it is, and how much evidence you have. Run it before building anything expensive. The top-left corner, important and unproven, is the one assumption to test first. On a product like Wfrah, the riskiest assumption is that breeders will trust a number from an app at all. The research said trust was low, which is why the app shows value and stories from other breeders before it asks for anything.

### Task analysis

Break one goal into every step and decision a user takes to reach it, including the steps outside your product. Nielsen Norman Group's [task analysis article](https://www.nngroup.com/articles/task-analysis/) calls it the systematic study of how users complete tasks to reach their goals. Use it for complex or expert work. You walk away with steps to cut, merge or automate. The Dot counter speed pass was a task analysis in practice: every tap was counted, and the tap that moves focus from phone to amount was removed by advancing automatically once the phone number is complete.

### Jobs to be done

Jobs to be done describes the progress a person is trying to make in a situation, whatever product they use for it. People hire a product for a job and fire it when it does not deliver. I wrote about it in [nobody wants your product](https://laithjunaidy.com/writing/nobody-wants-your-product), with Christensen's [milkshake story](https://www.library.hbs.edu/working-knowledge/clay-christensens-milkshake-marketing): new flavours did nothing until the chain learned the shake was hired for a long, dull commute.

Use it when demographics explain nothing about who buys. Nielsen Norman Group's [personas vs. jobs-to-be-done](https://www.nngroup.com/articles/personas-jobs-be-done/) makes the useful counterpoint: jobs focus on needs and outcomes, but they do not build empathy the way a good persona does, and the two work together.

**How to run it**

1. From interviews, find the moment the person decides to act.
2. Write the job in three lines: when I, I want to, so I can.
3. Use the person's words. "When I open Bunn at 9:40 with two orders shouted across the desk" is a job. "When I use the ordering feature" is a product description.
4. List what they hire today for that job. That list is your competition.

**What you walk away with:** a job that survives a redesign, and a competitor list that includes the WhatsApp group.

**The common mistake:** writing the job at the wrong height. "Drink coffee" is too high to design for; "tap reorder" is too low to learn from.

### Competitive analysis

The structured version of the competitor review: feature by feature and flow by flow, measured against the problem you just defined. Barbara Vam's note points to the many forms it takes, from visual analysis to SWOT. Run it once the problem is clear, so you compare the right things. You walk away with where to match the market and where to differ. **With Claude**, give it your problem statement and screenshots of three competitor flows and ask for a table of how each handles that one moment; check every cell against the screenshots, because models describe features products do not have.

## Ideate: how do you get from many ideas to one?

Ideate is the widest phase, 19 methods, with two halves teams forget to separate: going wide, then cutting. The checklist has many ways to generate ideas and none for choosing, so I add one at the end.

Skip the wide half and the team builds its first idea, which is usually the obvious one. Skip the cutting and twelve features ship half-built.

![User flow template for Bunn: open app, signed in decision, home, pick drinks, delivery fee decision, checkout, pay, track, delivered](https://laithjunaidy.com/store/user-flow/en-light.jpg)

*A user flow with both paths. The "no" branches, sign-in and the fee, are where the real design work is.*

### Brainstorming sessions

A group produces as many ideas as it can and holds judgement until later. The Interaction Design Foundation's [brainstorming page](https://ixdf.org/literature/topics/brainstorming) frames it as a way to generate ideas for a clearly defined problem; the "clearly defined" is doing the work. Bring the HMW questions. Have people write alone for five minutes before anyone speaks, so the loudest voice does not set the direction. You walk away with volume. The mistake is debating ideas during the session.

### Mind maps

One topic in the centre, related ideas branching out. Use it alone or in pairs to cover a space fast. The Interaction Design Foundation's [mind map page](https://ixdf.org/literature/topics/mind-maps) treats it as a way to visualise ideas and the links between them. You walk away with connections you would miss in a list, and sometimes a first draft of the navigation.

### Storyboards

A few comic-style frames of a user meeting the problem, then the solution. Draw them before screens to check the idea survives a real situation, like a breeder in a pen with dirty hands. Nielsen Norman Group's [storyboards article](https://www.nngroup.com/articles/storyboards-visualize-ideas/) argues they capture attention and give clarity. You walk away with a story a stakeholder understands in a minute. Stick figures are enough.

### Card sorting

In a card sort, participants group your content into categories that make sense to them. In an open sort they name the categories too. Nielsen Norman Group's [card sorting article](https://www.nngroup.com/articles/card-sorting-definition/) says it uncovers users' mental models of your information architecture, and gives the numbers: at least 15 participants for a qualitative sort, 30 to 50 for a quantitative one. It also warns that the labels participants invent are rarely your final labels, and recommends tree testing over closed sorts for checking navigation.

Run it before you design navigation for anything with more than a dozen items.

**How to run it**

1. Write 30 to 60 cards, one piece of content each, in plain words. Avoid the labels you plan to use, or you will just test those.
2. Run an open sort: participants group the cards and name each group. Ask them to think aloud.
3. Look for cards that land together across most participants, and for the ones that land everywhere. Those are your hardest labelling problems.
4. Draft the structure, then check it with a tree test.

**What you walk away with:** groupings users expect, and the content that will confuse them wherever you put it.

**The common mistake:** sorting the cards yourself. The team's mental model built the confusing navigation in the first place.

### User journey

The main path a user takes to one goal in your product, at a higher level than a flow. Nielsen Norman Group's [user journeys vs. user flows](https://www.nngroup.com/articles/user-journeys-vs-user-flows/) explains that both describe processes users go through to reach a goal but differ in scope, purpose and format. On Wfrah, the journey followed Awad from discovery through doubt to a trial and a decision, and put proof right at the point where he would hesitate. Use it to agree on the main routes before the detail.

### User flow

A user flow is every screen, decision and branch a user passes through for one task, drawn as boxes and arrows. It shows the dead ends and the error paths that screens hide. A screen only ever shows the happy path. Most bad products are a good screen sitting inside a bad flow.

The Dot counter is the clearest case I have. The first version's flow was amount, country picker, country, phone, generate. Every box made sense alone. Drawn as a flow, the cost is plain: a phone keypad has no Next key, so every move between fields is a tap. The speed pass redrew it as phone, amount, add points, and the screens followed.

Draw it before the screens, for every task with a decision in it.

**How to run it**

1. Pick one task and one persona. Write the start and the end.
2. Draw the happy path in boxes, one screen or step per box.
3. At every step, ask what happens if it fails: wrong input, no connection, not signed in, empty result. Each answer is a branch.
4. Mark decisions as diamonds with a yes and a no. Every no needs somewhere to go.
5. Count the steps on the main path. Then try to remove one.

**What you walk away with:** the full list of screens and states. It is always longer than the first guess.

**The common mistake:** drawing only the happy path, which is the one path that needs no design. Free [user flow template](https://laithjunaidy.com/store/user-flow), with the yes and no paths drawn.

**With Claude.** Describe the task and paste your happy path, then ask: "List every failure state for each step: invalid input, timeout, offline, duplicate tap, permission denied, empty data. For each, say what the user sees and where they go next." Check that each state names the field and the fix, the way the Dot counter does: "Nothing added. Phone is short by 1."

### Information architecture

Information architecture is how content is organised, labelled and connected. Nielsen Norman Group's [IA vs. navigation](https://www.nngroup.com/articles/ia-vs-navigation/) draws the line clearly: the IA is the information backbone, documented in spreadsheets and diagrams, and navigation is the part of the interface that lets people reach it. 

On Wfrah, the IA covered herds, the nutrition calculator, environment guidelines, the market, a knowledge base and the account, with progressive disclosure so a new breeder sees the essentials and an expert can go deeper. On [Zain Cash](https://laithjunaidy.com/writing/redesigning-zain-cash), Arabic-first information scent put the cues where a right-to-left reader expects them.

**How to run it**

1. Inventory every piece of content and every task.
2. Group them from the card sort, not from your org chart.
3. Label each group with the words users used in interviews.
4. Decide depth: what is one tap away, what is behind it.
5. Test the structure with a tree test before any visual design.

**What you walk away with:** a structure the navigation can show, and words the copy can use. The common mistake is structuring by department.

### Sitemap

A diagram of every page and how pages nest. Use it to scope a site or app, to find orphan pages, and to count. The page count is the start of the build estimate. Update it every release.


![Part of the iBuild buyer app sitemap: profile and settings, support center and loyalty branches, each page a box](https://laithjunaidy.com/writing/design-process/ibuild-sitemap.jpg)

*Part of the iBuild buyer app sitemap, a construction materials marketplace for Saudi Arabia: the profile, support and loyalty branches. Every box is a page someone has to design, build and keep up.*

### Service blueprints

A journey map extended below the surface: what staff, systems and partners do behind each step the user sees. Nielsen Norman Group's [service blueprints definition](https://www.nngroup.com/articles/service-blueprints-definition/) presents them as a way to visualise the organisational processes behind an experience. Use one when the product depends on operations: delivery, support, a counter. On the Dot counter, the cashier, the fraud checks and the ledger all act on one tap. You walk away with the backstage failure behind the front-stage complaint.

### Business model canvas

Nine blocks on one page: customers, value, channels, relationships, revenue, resources, activities, partners, costs. Strategyzer publishes the [canvas](https://www.strategyzer.com/library/the-business-model-canvas) as a free template. Use it when a design decision changes how the business makes money, such as a free tier or a partner fee. You walk away with each design choice tied to the block it moves.

### Worst idea

The team proposes deliberately terrible solutions, then turns each one around. The Interaction Design Foundation's [worst possible idea](https://ixdf.org/literature/topics/worst-possible-idea) describes the inverted search as a way to relax the team. Use it when a session stalls or people are afraid of looking foolish. "Hide the fee until after payment" flips into "show the fee before sign-in".

### Crazy 8

Fold a sheet into eight panels and sketch eight ideas in eight minutes, one minute each. Google's [Design Sprint Kit](https://designsprintkit.withgoogle.com/methodology/phase3-sketch/crazy-8s) places it in the sketch phase of a sprint. The time limit is the method: nobody can polish in a minute, so nobody gets attached.

Run it right after the HMW vote, before anyone opens a design tool. Without a specific question, eight sketches of "the app" are eight logos.

**How to run it**

1. Take one HMW question and one screen or moment.
2. Fold an A4 sheet three times to make eight panels.
3. Set a timer for eight minutes. One idea per panel. Silence.
4. Each person presents their sheet in two minutes. No critique yet.
5. Everyone puts dot votes on the panels they would build, then the decider picks.

**What you walk away with:** eight rough options per person.

**The common mistake:** letting people skip panels. The obvious idea runs out around the fifth sketch, and the useful ones start.

### Challenging assumptions

List what everyone takes for granted about the problem, then ask what changes if each belief is false. Barbara Vam's note frames it as turning over what the team believes about the problem, to see it fresh. The first Dot counter took for granted that the amount comes first. Questioning that order is what made two taps possible. Use it when every idea comes out the same.

### Sketching and sketch-storming

Rough drawings on paper, fast and disposable, alone or in timed rounds with the team. The Interaction Design Foundation's page on [sketches](https://ixdf.org/literature/topics/sketch) describes them as preliminary, hand-drawn representations of research outcomes, interfaces and interactions. Do it before any design tool, because a tool makes everything look finished.

### Product design principles

A few statements that settle recurring trade-offs. Nielsen Norman Group's [design principles article](https://www.nngroup.com/articles/design-principles/) calls them value statements that frame decisions and keep them consistent across teams. Wfrah had five: considerate, empowering, trustworthy, efficient, familiar. "Efficient" meant removing steps and adding friction only before decisions that matter. Write them once the team keeps having the same argument. A principle nobody can use to reject an idea is decoration.

### Moodboard

Images, type, colour and texture collected to set a visual direction. Nielsen Norman Group's [mood boards article](https://www.nngroup.com/articles/mood-boards/) treats them as a way to collect inspiration and decide on visual direction. Pull from outside your category. When we read [150 shadcn/ui repos](https://laithjunaidy.com/writing/taken-apart-shadcn-defaults), most ran on one of two typefaces and a grey primary. A moodboard built only from your competitors produces the same product.

### Style tiles

One board with fonts, colours and interface elements applied, and no layout. Samantha Warren's [Style Tiles](https://styletil.es/) introduced them as the step between a moodboard and a full mock-up. Show two or three, never one; a single tile is a yes or no question.

### Style guidelines

The written rules for type, colour, spacing, imagery and voice. Write the reason next to each rule, so the next designer can extend it instead of breaking it. A rule like [no pure black in dark mode](https://laithjunaidy.com/writing/stop-using-pure-black-in-dark-mode) holds longer when it says why: it strains the eyes and flattens depth.

### Design system

The style guide turned into shared components, tokens and documentation that design and code both use. Nielsen Norman Group's [Design Systems 101](https://www.nngroup.com/articles/design-systems-101/) defines it as a set of standards for managing design at scale, cutting redundancy and creating a shared language. The [GOV.UK Design System](https://design-system.service.gov.uk/) is a public one worth reading. It earns its cost once more than one team or product builds on the same interface.

![Four landing pages generated by ux-skill from four briefs: a family clinic, a developer tool, a family restaurant, and an Arabic invoicing app](https://laithjunaidy.com/writing/design-process/uxskill-4-brands.jpg)

*Four briefs, four design systems, one engine. A trial run of ux-skill's next version; each build passed 680 WCAG checks with none failing. The brands are fictional.*

That is the idea behind [ux-skill](https://laithjunaidy.com/research/ux-skill): a design system compiled from the brief, instead of one template pasted on everything. I explained why in [brand specs are training data](https://laithjunaidy.com/writing/brand-specs-are-training-data). The Dot counter runs on the Dot design system, and the speed pass mockups invented nothing at token level: every value came from the tokens file, and anything the system lacked was listed as an addition. You walk away with screens assembled instead of redrawn. The mistake is building components before patterns repeat; a system built too early encodes your first guesses. The [design system skill kit](https://laithjunaidy.com/store/dsskill) teaches Claude Code your tokens.

### Prioritisation matrix

Not on the original checklist, and the one I add every time. Plot each idea by impact on the user and effort for the team. The top-left corner, high impact and low effort, ships first. The matrix makes the team say out loud why the rest waits. Score impact from the research, never from enthusiasm.

![Impact and effort prioritisation matrix for Bunn: twelve ideas in four quadrants with a ranked score list](https://laithjunaidy.com/store/prioritisation-matrix/en-light.jpg)

*Twelve ideas from the usability test and the journey map. "Show the fee in the menu header" scores 25 of 25. Loyalty points and badges score 2.*

Free [prioritisation matrix](https://laithjunaidy.com/store/prioritisation-matrix).

## Prototype: how much do you build before you know?

A prototype is a question in a form people can touch. Nielsen Norman Group's guide to [low and high fidelity prototypes](https://www.nngroup.com/articles/ux-prototype-hi-lo-fidelity/) calls it a hypothesis, a candidate solution you test by watching people use it, and adds the line every team should hang on the wall: ripping up code is very expensive, ripping up a prototype is not.

The rule is to build the least that answers the open question. A question about wording needs paper. A question about a gesture or speed needs code. Fidelity is a cost; spend it only where the test needs it.

What goes wrong when teams skip this phase: the first prototype is the product, and the first usability test happens after launch, with real customers.

![Two Bysooq seller screens: a dashboard with total sales, sessions, conversion and orders, and a products grid with stock counts and prices](https://laithjunaidy.com/writing/design-process/bysooq-hifi.jpg)

*[Bysooq](https://laithjunaidy.com/work/bysooq), e-commerce for Iraq and Jordan: the seller dashboard and the products screen in high fidelity. Realistic data, every state designed, every label final. This is where a design gets judged.*

### Paper prototype

Screens drawn on paper and swapped by hand while a user taps with a finger. Nielsen Norman Group's [paper prototyping article](https://www.nngroup.com/articles/paper-prototyping/) argues that it lets you test early ideas at very low cost and fix usability problems before you pay to implement something that does not work. Use it for the earliest test of flow and wording. People criticise paper freely because it obviously cost nothing. You walk away with problems found before anyone opens a design tool.

### Micro-interactions

The small moments of feedback: a toggle, a pull to refresh, an error appearing under its field. Nielsen Norman Group's [microinteractions article](https://www.nngroup.com/articles/microinteractions/) says they show system status, help prevent errors and carry the brand, each one started by a trigger and built for one purpose. Design them once the flow works. On the Dot counter, the micro-interaction that matters most is invisible: focus jumping from phone to amount when the last digit lands. The speed pass spec also removed a 600 millisecond fade-up that played on every visit. Motion that slows a busy counter is not polish.

### Detailed user flows

The ideation flow with every state added: empty, loading, error, success, offline, edge cases. Nielsen Norman Group's [wireflows](https://www.nngroup.com/articles/wireflows/) combine wireframes and flowcharts for exactly this. The Dot speed pass spec lists eight states for one screen, from idle to fraud block to offline, and says what the cashier sees, where focus goes and what the button does in each. Draw them before high fidelity. You walk away with the full list of screens, usually longer than the first estimate.

### Mock-ups

Static, realistic screens with real content and visual design, nothing clickable. Use them to review appearance and to settle copy length in both languages, since Arabic and English lines rarely break in the same place. You walk away with sign-off on the look. Behaviour still needs a prototype; a mock-up approved as "the design" hides every state it does not show.

### Interactive prototype

Linked screens a user can click or tap through, close enough to the real thing that people forget it is fake. The GOV.UK Service Manual's guide to [making prototypes](https://www.gov.uk/service-manual/design/making-prototypes) treats prototypes as the way to try design ideas with users as you build a service.

Use it when the open question is about navigation, sequence or behaviour. Whether anyone wants the thing at all, an interview answers cheaper.

**How to run it**

1. Write the question the prototype must answer. "Can Rana start a group order without help?" is a question. "Does the app work?" is not.
2. Build only the screens on the tested path, plus the error states people will hit.
3. Use real content: real prices, real names, real Arabic. Lorem ipsum hides every layout problem.
4. Run it on the participant's own phone where you can. A prototype on a designer's large monitor tests the monitor.
5. Fix obvious problems between sessions.

**What you walk away with:** evidence about behaviour, and a list of fixes ranked by how many people they stopped.

**The common mistake:** prototyping everything. A 60-screen prototype takes so long that the team is too attached to change it.

![Same strategy game map shown twice: on the left, the first version with models on bare ground; on the right, the same base after several rounds of work, with terrain, roads and buildings](https://laithjunaidy.com/writing/design-process/rts-before-after.jpg)

*A strategy game I am building with Claude. Same map, same game. Left, the first version. Right, after several rounds of work. Nothing comes out right the first time.*

### Wireframes

Wireframes are low-fidelity layouts: structure, hierarchy and content, with no visual style. The Interaction Design Foundation's [wireframing page](https://ixdf.org/literature/topics/wireframe) describes them as basic representations of an interface's structure and layout. Their value is what they leave out. With no colour, the only argument left is what goes where and what matters most. Use them on any screen whose hierarchy is not obvious.

**How to run it**

1. Start from the detailed flow. One wireframe per screen and per important state.
2. Place content in order of importance for the task. On the Dot counter: phone, customer, amount, then the button.
3. Mark the one primary action per screen. If you cannot choose one, the screen does two jobs.
4. Check reach. The Dot counter's main button sits in the thumb zone, right above the keypad, which is [Fitts's law](https://laithjunaidy.com/writing/fitts-law-bigger-and-closer) at work: the important thing bigger and closer.
5. If the product is Arabic, draw the right-to-left version now. Late mirroring breaks layouts.

**What you walk away with:** an agreed skeleton for each screen before anyone argues about colour.

**The common mistake:** wireframes so polished that people review them as finished design.

### High fidelity designs

Final visual design with real copy, real data and every state. Make them for the screens that will ship. Every value should come from the design system's tokens, so engineering builds rules rather than measuring pixels. You walk away with what engineering builds. The mistake is designing only the success state at high fidelity and leaving errors as notes.

### Hand-off

A handoff is everything a developer needs to build the design without guessing: screens in flow order, the connections between them, every state, the tokens, and the behaviour. I wrote the full version in [design handoff](https://laithjunaidy.com/writing/design-handoff-to-developers), and the rule from it holds here: the handoff is a deliverable, not an export, and the engineer is the most important user of your file.

Plan it from the first screen, on every project that goes to engineering.

![Bysooq order details screen: line items, customer, payment and delivery, and the order timeline](https://laithjunaidy.com/writing/design-process/bysooq-order-details.jpg)

*A Bysooq order details screen. A handoff carries every field, every status and every state behind a screen like this, not just the picture of it.*

**How to run it**

1. Order and name screens by flow: "Counter, invalid phone", not "Screen 12 final v3".
2. Hand over every state with the same care as the happy path. The Dot spec has a table: state, what the cashier sees, where focus goes, what the button says.
3. Write the copy rules, not only the copy. On Dot, every failure line starts with the ledger truth, "Nothing added.", because a cashier's first question after an error is whether it went through.
4. Write the rules that are not visible: never clear what the cashier typed on an error, return to idle after 30 seconds so the next customer does not see the last one's balance.
5. Stay reachable through the build and review the staging link.

**What you walk away with:** fewer questions mid-sprint.

**The common mistake:** handing off pictures. A screen shows what to build, never how it behaves.

**With Claude.** Paste your detailed flow and ask: "For every screen and state, write the handoff row: what the user sees, where focus goes, what each button does, what happens on timeout and on a double tap. Mark any state the flow does not define." The gaps it marks are the questions an engineer would have asked you on day three.

### Design documentation

The record of why: decisions, rejected options, and the research behind them. Keep it short and write it as you go. The Dot counter spec explains in one paragraph why the phone comes first: iOS number keypads have no Next key, and only a field of known length can advance by itself. Six months later, nobody has to guess.

### HTML/JS prototypes

A prototype coded in the real medium. Use one when the question depends on real data, speed, animation, a keypad, or a gesture a design tool cannot fake. Auto-advance and keyboard behaviour do not exist in a static frame, so the Dot tap count could only be proven in code. With Claude Code and a design system, a coded prototype is often faster than a clickable one; the free [Claude Code and Figma guide](https://laithjunaidy.com/store/system) covers the setup. The mistake is shipping the prototype without the tests.

## Test: how do you find out if it works?

Test is where the team stops being the judge. Nielsen Norman Group's [Usability Testing 101](https://www.nngroup.com/articles/usability-testing-101/) says even the best designers cannot get an interface right without iterative design driven by watching real users.

What goes wrong when teams skip it: they find the problems through support tickets, one angry customer at a time, after the budget is spent.

![Usability test template for Bunn: plan, five tasks with pass, partial and fail results, and findings sorted by severity with evidence quotes](https://laithjunaidy.com/store/usability-test/en-light.jpg)

*Five moderated sessions, five tasks, findings sorted by severity. The critical finding, the late delivery fee, is the same pain the interviews found.*

### Usability testing

In a usability test, a facilitator gives a participant a realistic task, then watches and stays quiet while they attempt it.

How many people? Nielsen's [why you only need to test with 5 users](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/) shows that the first five users find about 85 percent of the usability problems, and that while finding all of them takes at least 15, it is better to spend those 15 on three rounds of five, fixing the design between rounds.

Run it on every round, from paper to shipped product. It does not answer preference questions.

**How to run it**

1. Write the goal, then five tasks as realistic scenarios with a success condition and a time limit: "You are at the office and want a flat white. Before you pick anything, find out how much delivery costs."
2. Recruit five people who match the persona. Run a pilot session first to catch broken tasks.
3. Ask them to think aloud. Do not help. When they ask "what should I do?", answer "what would you do if I were not here?"
4. Mark each task pass, partial or fail, and note the time and the quote at the moment it went wrong.
5. Log every finding with its severity, where it happened, the evidence quote, and the fix. Critical findings ship first.

**What you walk away with:** where people get stuck, why, and the quote that convinces the stakeholder who was sure it was fine.

**The common mistake:** testing with colleagues. They know what the button is supposed to do. Free [usability test template](https://laithjunaidy.com/store/usability-test), with the plan, the script and the findings table.

**With Claude.** After the sessions, paste your notes and ask: "Group these into findings. For each, give severity (critical blocks the task, serious slows it, minor annoys), the participants who hit it, and one exact quote. Do not add any finding without a quote." Then set the severities yourself. The model cannot know which delays cost money.

### Shadowing

Follow one person through a real day of using the product or service. The Interaction Design Foundation's page on [shadowing](https://ixdf.org/literature/topics/shadowing) describes it as a long-established research technique that has only recently come into regular use in UX research. Use it for work tools and services that stretch over hours, like a cashier's shift. You walk away with how the product fits the rest of the work, or where it does not. Agree beforehand when you may ask questions, so you do not interrupt the work you came to watch.

### A/B testing

An A/B test runs two live versions of a design, splits real traffic between them at random, and compares one metric. Nielsen Norman Group's [A/B testing 101](https://www.nngroup.com/articles/ab-testing/) defines it as a quantitative method for finding which variation performs best against a predetermined business metric, and says the variant should ideally differ from the original in one element only.

It earns its time when you have enough traffic and a measurable goal. The required sample size depends on your baseline rate and the smallest change you care to detect, so on a small product you may wait months for an answer a usability test gives in a week.

**How to run it**

1. Start from a hypothesis grounded in research: "Showing the fee in the menu header will raise menu-to-checkout rate."
2. Change one thing. Two changes and you will not know which one worked.
3. Pick the metric and the sample size before launch, and the duration with it.
4. Do not stop the test early when the line looks good. Early peeks produce false winners.
5. Keep the variant only if it wins with statistical significance.

**The common mistake:** treating the winner as an explanation. An A/B test tells you which version won. A usability test tells you why the other one lost.

### SUS testing

The System Usability Scale is ten statements with five answer options each, given right after a usability session. MeasuringU's [guide to SUS](https://measuringu.com/sus/) records that John Brooke released it in 1986 as a "quick and dirty" scale, that it has since been tested on hardware, software, websites and phones, and that the average score across 500 studies is 68.

Use it when you want a number to compare between rounds. It does not tell you what is wrong; the session does.

**How to run it**

1. Use the ten standard statements unchanged. Translate carefully if you test in Arabic, and keep the order.
2. Give it after the tasks, before any discussion.
3. Score it: for odd items subtract 1 from the answer, for even items subtract the answer from 5. Add the ten results and multiply by 2.5. The total runs from 0 to 100.
4. Compare against 68 and against your last round.

**The common mistake:** reading the score as a percentage. MeasuringU's point is that 68 is the average, so a 70 is barely above it, not "70 percent usable".

### Heuristic evaluation

In a heuristic evaluation, a few evaluators review an interface against a set of principles, most often [Jakob Nielsen's ten usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/), first published in 1994. Nielsen Norman Group's guide on [how to conduct one](https://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/) says it is good at finding glaring problems, works on almost any interface including prototypes, and is especially useful early.

Use it as a cheap check before testing with users, and on any screen you inherited. Experts find what breaks rules. Users find what breaks their day.

**How to run it**

1. Fix the scope: one persona, one task, one device.
2. Have each evaluator walk the task alone, as a user would, then a second time against each heuristic.
3. Keep the evaluations separate until everyone is done, as the guide insists.
4. Merge the findings, cite the heuristic for each, and rate severity.
5. Fix the critical ones, then test with users.

**What you walk away with:** a list of violations ranked by severity, at the cost of an afternoon.

**The common mistake:** one evaluator. Separate evaluators catch different problems. **With Claude**, give it a screenshot and the ten heuristics and ask for violations with the heuristic, the element and the fix. Treat the result as one more evaluator. It is weak at anything that needs the flow around the screen.

### Analytics

Behaviour data from the live product: where people drop off, what they search for, which paths they take. Read it continuously. Nielsen Norman Group's [analytics in UX article](https://www.nngroup.com/articles/analytics-user-experience/) argues analytics adds the most value when it is joined to qualitative research instead of replacing it. Analytics shows where the problem is. Testing shows what it is.

### Performance testing

Measure how fast the product loads and responds on real devices and real networks. Nielsen Norman Group's [response times article](https://www.nngroup.com/articles/website-response-times/) sets the three limits: 0.1 second feels instant, 1 second keeps the user's flow, and 10 seconds is the limit of attention. The GOV.UK Service Manual has a practical guide to [testing frontend performance](https://www.gov.uk/service-manual/technology/how-to-test-frontend-performance). Speed was one of three ideas behind the [Zain Cash redesign](https://laithjunaidy.com/writing/redesigning-zain-cash), because most of its visitors are on phones. The Dot counter spec runs the customer lookup while the cashier types the amount, so nothing waits on the network. Test on a mid-range phone on mobile data, not on the office fibre.

### Observation

Watching the shipped product in real use, in its real setting. Do it after launch, once behaviour has settled into habit. Nielsen Norman Group's [contextual inquiry](https://www.nngroup.com/articles/contextual-inquiry/) pairs observation with interviewing in context to uncover what other methods miss. You walk away with the gap between how you designed it to be used and how it is used. A cashier who learns to type the phone with one thumb while holding a cup is telling you where the next speed pass starts.

### Desirability observations

Show the design and ask people to pick, from a fixed list of words, the ones that describe it, then explain each choice. Nielsen Norman Group's guide to the [Microsoft Desirability Toolkit](https://www.nngroup.com/articles/microsoft-desirability-toolkit/) presents it as a controlled-vocabulary test of attitudes toward a design. Use it to test a visual direction with evidence instead of taste. You walk away with whether the design reads the way the brand intends. If you meant "calm" and people pick "empty", the moodboard was wrong, not the users.

### Metrics

The numbers chosen in empathise, measured again. Check them after launch and then on a schedule. The GOV.UK Service Manual's guide to [measuring success](https://www.gov.uk/service-manual/measuring-success) covers measuring, reporting and the analytics behind it. You walk away with whether the change worked, against the baseline. A metric that moved without a baseline is a story, not a result.

### Eye-tracking

Hardware or webcam software records where people look and for how long. The Interaction Design Foundation's [eye tracking page](https://ixdf.org/literature/topics/eye-tracking) covers how it is used to study engagement and usability. Use it for narrow questions about attention, such as whether anyone sees the price or the warning. You walk away with heatmaps. Read them carefully: looking is not understanding, and a long gaze can mean confusion as easily as interest.

## Which templates go with which phase?

Every free template ships in Arabic and English, light and dark. The Arabic pages are written in Arabic and mirrored right to left. Research that starts in the wrong language starts with the wrong user.

| Phase | Method | Free template |
| :- | :- | :- |
| Empathise | User interviews | [User interview script and notes](https://laithjunaidy.com/store/user-interview) |
| Empathise | Affinity maps | [Affinity map](https://laithjunaidy.com/store/affinity-map) |
| Define | Empathy map | [Empathy map](https://laithjunaidy.com/store/empathy-map) |
| Define | Personas | [User persona](https://laithjunaidy.com/store/persona) |
| Define | Problem statement, HMW, jobs to be done | [Problem statement and how might we](https://laithjunaidy.com/store/problem-statement) |
| Define | User journey map | [Customer journey map](https://laithjunaidy.com/store/customerjourney) |
| Ideate | User flow | [User flow](https://laithjunaidy.com/store/user-flow) |
| Ideate | Prioritisation | [Prioritisation matrix](https://laithjunaidy.com/store/prioritisation-matrix) |
| Test | Usability testing, SUS | [Usability test](https://laithjunaidy.com/store/usability-test) |

The nine also come as one paid bundle, [UX AI Kit Pro Max](https://laithjunaidy.com/store/uxkit), with Claude prompts, a facilitation guide and a second worked example for each.

## FAQ

### What are the 5 stages of the design process?

Empathise, define, ideate, prototype and test. Teams loop back between them; a failed test usually sends you back to define, not to the start.

### Do you need every method on a design process checklist?

No. Pick the one or two per phase that remove the most guessing. For most products: interviews and an affinity map, a problem statement and how might we questions, a user flow, a small prototype, and a usability test.

### How many users do you need for a usability test?

Five per round. Five people find about 85 percent of the problems. Run several small rounds and fix the design between them.

### Which design methods work with no budget?

Most of them. Existing data, five interviews, an affinity map on a wall, a problem statement, a paper prototype and a usability test in a café cost time and no money. Eye-tracking, large surveys and A/B tests need tools or traffic.

### What is the difference between a user journey and a user flow?

A journey covers the whole experience across time and channels, including the parts outside your product. A flow covers the steps inside the product for one task, with every branch. Map the journey to find the problem, then draw the flow to design the fix.

### Can AI replace user research?

No. A model drafts scripts, sorts transcripts and lists failure states well. It cannot tell you what Awad does in his pen or why Rana checks the fee twice. Ask it to play your user and you get the average of what it has read, which is the assumption research exists to test.

### Which methods matter most for vibe coders building with AI?

The ones that happen before the prompt. A problem statement and a user flow with every failure state give the model something specific to build, and a five-person usability test catches what it got wrong. AI makes building cheap, so the expensive mistake moves upstream: building the wrong thing quickly.

### Where does Barbara Vam's checklist come from?

Barbara Vam published the [Design Process checklist](https://coconut-baroness-035.notion.site/Design-Process-checklist-7c07a8c25f1a42e385f5205faa8d93a8) as a Notion page, with short notes and reading links for most methods. The method list and its order are hers. The explanations, the stories and the templates here are mine.