UX Research: User Needs, Personas, and Journey Maps

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 lesson develops UX research skills: finding out what people need, summarizing it into personas and journey maps, and turning findings into requirements you can build and test.

The original scenario follows Harbor Workshops, a fictional community center redesigning workshop discovery and booking. Attendance is flat and front-desk calls are rising. All participant counts, quotations, personas, analytics, and outcomes in this lesson are invented teaching fixtures, not reports of research we conducted. In a real project, label assumptions and collect evidence before treating them as findings.

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

Two useful frameworks organize human-centered design. The Design Council's Double Diamond has four stages: Discover, Define, Develop, Deliver, opening up and narrowing down the problem and then possible solutions. Stanford d.school describes five design thinking modes, which we use below:

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.

These frameworks are related but have different names and structures. Neither requires a rigid sequence: testing can change the problem definition, and early prototypes can support discovery. Sketches and conversations can expose mistaken assumptions before substantial implementation work.

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	Useful questions	Sample planning	Examples
Qualitative	How people approach a task, and possible reasons or barriers	Iterative rounds chosen for the audience and research question	Interviews, observation, diary studies, usability sessions
Quantitative	How often something happens, or how measured outcomes differ	Depends on precision, variability, recruitment, and the effect being studied	Surveys, analytics, controlled A/B tests, funnel data

Neither is inherently better, and neither has a universal sample size. If analytics show 60% leaving at payment, interviews might suggest that an unexpected cancellation fee contributes. That is a hypothesis to investigate, not proof that the fee caused every exit. Observation, interviews, and quantitative evidence answer complementary questions; choose methods by the decision they must support.

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	Exploring navigation labels and groups	Suggests groupings meaningful to participants	Does not by itself validate a finished navigation
Support ticket review	Finding recurring problems	Uses existing records	Analysis takes effort; records overrepresent people who contact support

Planning a short interview

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

Recruit people who match the relevant audience, including people who abandoned booking or could not use the service. Recruiting only successful customers misses barriers.
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.
Explain the research purpose and obtain informed consent before collecting or recording personal information. Limit collection, restrict access, and agree how long recordings and notes will be kept. Avoid requesting real payment details for a prototype.
Take notes of quotes and observations separately from your interpretations.

Weak question: "Would you use an easier booking page?" (leading and hypothetical; it encourages agreement rather than an account of actual behavior.) 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". Keep participant identifiers separate from personal details so several notes from one person are not counted as several people. Prioritize by task impact, accessibility barriers, observed recurrence, and confidence in the evidence. Note counts and emotional language alone do not establish prevalence in the whole audience.

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.

Text

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, Reserve is unavailable, with visible adjacent text saying why; the explanation does not depend on focusing a disabled button.
- The seat count is available to screen readers as text, not only color.
- After the server confirms a booking, the displayed count updates without a full reload.
- A failed request or concurrent sell-out shows an understandable error instead of claiming a reservation succeeded.

These criteria guide the user-facing tests from the previous chapter. Use accessible forms and validation semantics to turn a written requirement into labels, instructions, and recoverable errors.

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.
Evidence: traceable observations and, where appropriate, an anonymized quotation used with consent. Label a composite paraphrase as such rather than presenting it as a participant's exact words.

Illustrative provisional persona, to be checked against real research:

Field	Content
Persona	Maya, a parent booking family activities during short breaks
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
Invented illustrative phrase	"I only have five minutes, and if it's confusing I'll just call."

Keep the set manageable and distinguish needs only when evidence supports the distinction; there is no fixed maximum. Include relevant accessibility contexts throughout the research. One screen reader user cannot represent everyone who uses assistive technology, and a single accessibility persona cannot stand for all disabilities.

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.

Hypothetical journey for Maya, with thoughts and emotions to investigate rather than assume:

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

Autosave is a proposal, not an automatic requirement: consider shared devices, data sensitivity, retention, and whether keeping entries in the current session is sufficient. Real journeys can branch, repeat, or fail. For the next design step, turn this map into wireframes and a testable prototype.

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 (simulated evidence). Imagine five interviews and 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.

Rank three immediate requirements and record the remaining issue for follow-up. Treat interview counts and call proportions as different samples; their percentages cannot be added together.

Reasoning, step by step.

Group the notes: availability, total price, form resilience, and an inaccessible Reserve control. Four themes remain four themes; do not hide two unrelated fixes inside one requirement.
Assess impact and uncertainty: the inaccessible action is a reported task blocker and needs immediate reproduction and repair. Availability and price are recurring concerns. The resilience issue also matters, but neither its cause nor its implementation effort is known.
Rank three immediate outcomes:
1. Make Reserve reachable by keyboard and correctly named for assistive technology.
2. Display seat availability as text on list and detail pages.
3. Show the total payable price, including materials, before the booking form starts.
Define checks: inspect keyboard behavior and accessible names, involve participants using their familiar assistive technology, ask users to locate an available workshop, and ask them to state the full price before proceeding. A team may set a task-time target, but a few moderated sessions cannot establish a population-wide timing benchmark.
Keep the fourth issue visible: investigate failed submissions and specify how to preserve entries safely. Assign an owner and follow-up rather than assuming this is cheap or silently dropping it.

Solution. The three priorities address access to the action and the information needed to choose it. Form resilience stays in the backlog for investigation. A WCAG review complements user sessions; neither substitutes for the other.

Why other approaches are weaker.

Ranking only by mentions can dismiss a severe accessibility blocker.
Starting with color changes bypasses the supplied evidence about information and task completion.
Commissioning a large opinion survey immediately does not resolve the observed control failure. A well-designed quantitative study could later estimate prevalence; its value depends on the decision and sampling plan.

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

Study tip: identify the research question and the evidence needed. Analytics can locate exits; observation and interviews can suggest causes to investigate. Keywords such as "why" do not mechanically determine the method, and reported reasons alone do not establish causation.

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 understand what information is required to choose a shift, because unclear questions may discourage completion." The interview reports suggest a cause to investigate; analytics alone do not prove it.
User story: "As a new volunteer, I want to understand which skills information is needed, so that I can choose an appropriate shift confidently." Criteria: explain required qualifications and provide a plain-language example; clearly mark optional preferences and allow submission without those optional answers. Confirm operational and safety needs before making a genuinely required field optional.
Next step: prototype the clarification and observe a new round with relevant volunteers. Investigate remaining hesitation and monitor abandonment using a defined denominator and period. Small rounds find problems; a before-and-after percentage alone cannot attribute changes to this edit.

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 into experiences and context / measurement of quantities and differences.
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.