Research Needs and User Journeys

Introduction

This is lesson 1 of chapter 7, aligned with course 7 of the Meta Front-End Developer pathway ("Principles of UX/UI Design", domain ux-ui). Until now you have asked "how do I build this interface?" This chapter starts earlier and asks a harder question: should we build it, for whom, and what problem does it solve?

Front-end developers who understand users make better decisions about labels, error messages, defaults, and layout, even when a designer is on the team. On small teams, you may be the designer too. This first lesson covers the research side of design: finding out what people need, summarizing it into personas and journey maps, and turning findings into requirements you can build and test.

The scenario is original. Harbor Workshops, the fictional community center from earlier chapters, wants to redesign how people discover and book workshops. Attendance is flat, phone calls to the front desk are rising, and nobody is sure why.

Learning objectives

By the end of this lesson you can:

Explain the difference between UX design and UI design, and how both relate to front-end work.
Describe the stages of a human-centered design process.
Choose between qualitative and quantitative research methods and plan a short interview.
Write a problem statement and user stories with acceptance criteria.
Build a persona and a user journey map from research notes.
Prioritize findings and turn them into design requirements.
Avoid common research biases.

1. UX and UI: two words, one product

Term	Meaning	Example question
UX (user experience)	The whole experience of using a product: finding it, learning it, completing tasks, feeling about it	"Can a first-time visitor book a workshop in under two minutes?"
UI (user interface)	The visible and interactive layer: layout, colors, typography, controls	"Is the Reserve button easy to see and press?"
Usability	How effectively, efficiently, and satisfyingly users reach goals	"How many errors occur in the booking form?"
Accessibility	Whether people with different abilities can use the product	"Can a screen reader user complete the booking?"

A good UI cannot rescue a bad UX. A beautiful booking page still fails if people cannot tell which workshops have seats left. And a sound UX can be damaged by a poor UI, for example text that is too small to read. Front-end code is where both meet: your HTML structure, CSS, and component behavior directly create the experience.

2. The design process

Most teams follow a loop with names that vary slightly. A common version is the double diamond, or the five-step design thinking cycle:

Empathize: learn about users through research.
Define: state the problem clearly.
Ideate: explore many possible solutions.
Prototype: make a cheap, testable version.
Test: put it in front of users, learn, and loop back.

The process is a loop, not a line. Test results often send you back to define or even empathize. Cheap steps early (sketches, conversations) prevent expensive steps late (rewriting code that nobody wants).

3. Research methods

Research reduces guessing. You do not need a laboratory; you need a question and a method that fits it.

Qualitative versus quantitative

Type	Answers	Typical sample	Examples
Qualitative	Why people behave as they do	5 to 10 people	Interviews, observation, diary studies, usability sessions
Quantitative	How many or how often	Hundreds or thousands	Surveys, analytics, A/B tests, funnel data

Neither is better. Analytics might show that 60% of visitors leave the booking page at the payment step (the what). Interviews reveal that people were surprised by a cancellation fee they could not find earlier (the why).

Common methods

Method	Best used for	Strength	Limit
User interview	Understanding goals, context, frustrations	Rich detail	What people say may differ from what they do
Contextual observation	Seeing real behavior in the real place	Reveals workarounds	Time-consuming
Survey	Measuring opinions across many people	Scale and numbers	Shallow; depends on question wording
Analytics review	Finding where behavior drops	Real behavior at scale	Does not explain why
Competitor review	Learning conventions and gaps	Fast	Does not show your users' needs
Card sorting	Organizing navigation labels and groups	Matches users' mental models	Needs several participants
Support ticket review	Finding recurring problems	Free data	Biased toward people who complain

Planning a short interview

Good interviews feel like conversations about past behavior, not about opinions on hypothetical features.

Recruit people who match your audience (for Harbor Workshops: residents who attended, or considered attending, a workshop in the last year).
Write 6 to 8 open questions, such as "Tell me about the last time you looked for something to do on a weekend."
Ask "why" and "can you show me?" rather than "would you like a feature that…?"
Keep neutral. Do not hint at the answer you hope for.
Ask permission before recording, and protect privacy.
Take notes of quotes and observations separately from your interpretations.

Weak question: "Would you use an easier booking page?" (leading, hypothetical, everyone says yes.) Better: "Walk me through the last time you tried to sign up for a class. What happened first?"

4. Problem statements and requirements

Raw research produces many notes. You need to make them usable.

Synthesis with an affinity map

Write each observation on a sticky note (physical or digital), then group similar notes. Name each group with a theme, for example "Unsure whether seats remain" or "Prefers calling because the form feels risky". The themes with the most notes, and the strongest emotion, are candidates for priority.

Problem statement

A good problem statement names the user, the need, and the reason, without prescribing the solution.

Busy parents who attend weekend workshops need to see seat availability and total cost before they start booking, because they plan around childcare and do not want to discover problems at the payment step.

Compare with a solution disguised as a problem: "We need a bigger Reserve button." That skips the learning.

User stories and acceptance criteria

A user story has the form: As a [type of user], I want [goal], so that [benefit]. Acceptance criteria describe how you will know it works.

Story: As a parent, I want to see remaining seats on each workshop card,
so that I do not waste time on workshops that are full.

Acceptance criteria:
- Each card shows "N seats left" or "Sold out".
- When seats reach 0, the Reserve button is disabled and explains why.
- The seat count is available to screen readers as text, not only color.
- The count updates after a booking without reloading the page.

These criteria translate directly into your tests from the previous chapter.

5. Personas

A persona is a fictional but research-based profile that represents a group of users. It keeps the team focused on real needs. A persona must come from data, not imagination; invented stereotypes mislead.

A compact persona has:

Name and role (a made-up name to humanize the profile).
Goals: what they want to achieve.
Context: devices, time, environment, skills, assistive technology.
Frustrations: what blocks them today.
Quote: a short representative phrase from research.

Example from the Harbor Workshops research:

Field	Content
Persona	Maya, 38, parent of two, part-time nurse
Goals	Find a weekend activity she and her child can both enjoy; confirm quickly
Context	Browses on her phone in short breaks; unstable mobile data in the hospital basement
Frustrations	Cannot tell if seats remain; fears paying for the wrong date; forms that lose data when the connection drops
Quote	"I only have five minutes, and if it's confusing I'll just call."

Create two or three personas at most. Include at least one with accessibility needs, such as someone who uses a screen reader or magnification, because designing for them improves the product for everyone.

6. User journeys

A user journey map shows the steps a persona takes to reach a goal, with their actions, thoughts, emotions, and pain points at each stage. It reveals where the experience breaks.

Journey for Maya booking a workshop:

Stage	Action	Thinking	Emotion	Opportunity
Discover	Searches "family pottery class" on her phone	"Is there something this Saturday?"	Curious	Make date filters prominent
Evaluate	Opens two workshop pages	"How much, and are there seats?"	Uncertain	Show price and seats at the top
Decide	Compares dates	"Which fits our day?"	Hesitant	Allow side-by-side comparison
Book	Fills in the form	"What if it fails?"	Anxious	Autosave, clear validation, show total
Confirm	Receives the confirmation	"Did it work?"	Relieved	Show a clear confirmation and calendar link
After	Day of workshop	"Where do we go?"	Neutral	Send reminder with address and time

A related tool is a user flow: a diagram of the screens and decisions along one task, such as "search, choose, sign in, pay, confirm". A journey map captures feelings and context; a flow captures the product's logic. Use both.

Worked example: from interview notes to requirements

Problem. Five interviews and a look at three months of front-desk phone logs produced these notes:

4 of 5 interviewees said they were unsure whether seats were left until after clicking.
3 of 5 said the total price, including materials, appeared only at the last step.
2 of 5 mentioned that the form lost their entries after a mobile connection drop.
The phone log shows 38% of calls ask "is there still room?" and 21% ask "what do I need to bring?"
1 of 5 uses a screen reader and could not find the Reserve button on the list page.

Turn these into a ranked set of three requirements.

Reasoning, step by step.

Group the notes by theme: availability visibility (4 of 5 plus 38% of calls), price transparency (3 of 5), form resilience (2 of 5), accessibility of controls (1 of 5, but severe: a complete blocker).
Weigh frequency and impact. Availability is the most frequent and drives phone volume. Price transparency affects trust before payment. The screen reader blocker affects fewer people but prevents task completion entirely, so it cannot be postponed. Form resilience is less frequent but cheap to fix.
Write requirements as outcomes:
1. Show seat availability on list and detail pages, as text.
2. Show the total price including materials before the form starts.
3. Make the Reserve control reachable and named for assistive technology; preserve form entries on connection loss.
Define a way to check each one: a task test ("find a workshop with seats left in under 30 seconds"), a price comprehension question, and a screen reader walkthrough.

Solution. The ranked list above, with the accessibility blocker kept in the top three even though few interviewees mentioned it.

Why other approaches are weaker.

Ranking only by number of mentions would drop the screen reader issue, though it excludes users completely.
Starting with a visual redesign would skip the evidence that the main problems are information and trust, not color or style.
Surveying 500 people first would be slower and would not explain why people hesitate; interviews and logs already point to clear themes that can be tested.

Common biases and mistakes

Pitfall	What happens	Prevention
Confirmation bias	You notice only evidence that supports your idea	Write hypotheses first and look for disconfirming notes
Leading questions	Participants echo your assumption	Ask open questions about past behavior
Designing for yourself	You assume everyone uses the product like a developer	Recruit real users; include varied abilities and devices
Tiny or biased sample	Conclusions from friends and colleagues	Recruit outside your circle; mix methods
Solution-first thinking	The problem statement describes a feature	Rewrite it as user, need, reason
Ignoring accessibility	Large groups cannot use the result	Include assistive technology users from the start

Exam tip: questions often ask which method answers a given need. Remember: why means qualitative (interview, observation); how many means quantitative (survey, analytics); where do people drop out starts with analytics, then interviews explain it.

Mini case study: the volunteer sign-up page

A food bank wants a page where volunteers sign up for shifts. The director says, "Make the sign-up button orange and bigger." Phone volunteers report that many people start the form and quit. Analytics show 70% abandon at a field called "Skills (required)". A short interview with four volunteers reveals that they do not know what to write, and two fear that a wrong answer could disqualify them.

Tasks. Write the problem statement, one user story with two acceptance criteria, and the next step.

Commented solution.

Problem statement: "New volunteers need to sign up for a shift without being asked for information they do not understand, because uncertainty makes them abandon the form."
User story: "As a new volunteer, I want to choose a shift without describing my skills, so that I can sign up quickly." Criteria: the skills field is optional and has a short example; a volunteer can submit with only name, contact, and shift.
Next step: change the field, then measure abandonment again and run a quick test with three new volunteers. The button color is not the evidence-supported problem, so it is not the first change.

Key terms

UX / UI: the whole experience / the visible interface layer.
Persona: a research-based fictional profile of a user group.
User journey map: stages, actions, thoughts, and emotions across a task.
User flow: a diagram of screens and decisions for one task.
Qualitative / quantitative: research about why / about how many.
Affinity map: grouping notes into themes.
User story: a short statement of a user's goal and benefit.
Acceptance criteria: testable conditions for a story.
Double diamond: a process of exploring and focusing on both the problem and the solution.

Summary checklist

I can distinguish UX, UI, usability, and accessibility.
I can name the stages of the design process and explain that it loops.
I choose qualitative or quantitative methods for the question at hand.
I write open, non-leading interview questions about past behavior.
I produce a problem statement, user stories, and acceptance criteria.
I build personas and journey maps from data, including accessibility needs.
I prioritize by frequency and impact, not frequency alone.
I recognize common research biases.