Topic 4 — User research basics

Goal: Learn to design for real people by understanding them first.

Lesson 4.1 — The cure for designing in your own head

Tessa's first solo task at Wanderwell, the travel-booking startup, was to redesign the screen where people pick their trip dates. She spent two days on a calendar she loved: clean, airy, the way she'd have wanted it. Marcus Bell, her mentor and the lead product designer, looked at it for a while and asked one question: "Who told you they wanted a calendar?"

Nobody had. She'd designed for the one user she knew best — herself.

That instinct is the trap every new designer falls into, and user research is the cure. Research is the work of learning what real people need and do, before you decide what to build, so your choices rest on evidence instead of your own taste. In Tessa's old job styling retail spaces, she could trust her eye. Software is different: the people using Wanderwell aren't designers, they don't think like her, and they'll use the app in moments she can't picture — on a cracked phone, on a delayed train, with a crying toddler nearby.

"The user is not you." Research is the habit that keeps you honest about it.

Tessa had heard that line in her course and nodded along. Watching her beautiful calendar quietly die taught her what it meant. Research is how you stop guessing, not extra polish reserved for big teams with budgets.

Lesson 4.2 — Two flavors: the why and the what

When Tessa asked how you actually do research, Marcus drew a line down the whiteboard. Two columns.

On one side: qualitative research. This is the why and the how — talking to people, watching them use the product, listening to how they describe their frustration. You sit with a handful of users and go deep. Five people, but you understand them. Interviews and observation live here.

On the other side: quantitative research. This is the what and the how many — numbers gathered from lots of people. Surveys, and analytics (the data your app records about where users tap, scroll, and quit). Thousands of people, but each one is a faint signal. You learn that something happens, rarely why.

	Qualitative	Quantitative
Answers	why and how	what and how many
Methods	interviews, observation	surveys, analytics
People	few, deep	many, shallow
Gives you	rich insight	measurable scale

Beginners often think they have to pick a side. The strong designers combine them. Hannah Reyes, Wanderwell's UX researcher, showed Tessa why with the booking funnel. Analytics said 60% of people abandon the payment form — that's the what, and it's alarming, but it's mute. So Hannah sat with six users, and the why fell out in the first session: "it suddenly asks for my passport ID and I got nervous — is this even a real company?" Numbers find the bleeding. Conversations tell you where the wound is.

Lesson 4.3 — The interview: your most powerful, most available tool

You can't run a thousand-person survey in your first month. You can talk to five people this week. That's why the user interview — a focused, friendly conversation with one real user — is the tool to learn first. It needs no budget and no special software, and done well it'll teach you more than any dashboard.

It also goes wrong easily. There's one mistake that ruins more beginner interviews than all the others combined, and it's the subject of the next lesson. The other rules are quieter but matter just as much:

• Ask open questions, then go quiet. "What was that like?" beats "Was that frustrating?" And after they answer, don't fill the silence. Tessa's habit was to jump in and rescue the pause. Marcus told her to count to five in her head instead. People reach for the real, awkward truth when the silence makes room for it.
• Dig into the why, a layer or two down. When a user says "the search was annoying," that's the surface. "Annoying how? Walk me through what you were trying to do." The usable insight almost always sits below the first complaint.
• Never lead or pitch. "You'd love a feature that saves your trips, right?" is a sales line wearing a question mark, not a real question. It gets a polite yes that means nothing. You're there to learn, not to sell.

You don't need a research title to do this. Five honest conversations can quietly demolish an assumption your whole team was building on.

Lesson 4.4 — Ask about the past, not the future

Here's the mistake that wrecks more interviews than any other.

Early on, Tessa wanted to validate a new "trip ideas" feed, so she asked her five users a clean, obvious question: "Would you use a feature that suggests trips for you?" All five said yes. She walked into the team meeting glowing. Priya Anand, the product manager, raised one eyebrow and asked, "When did any of them last go looking for trip ideas in a real app?" Tessa didn't know. She'd never asked.

That's the rule that separates research from theater: ask about real past behavior, not hypotheticals. People are bad at predicting their own future actions, and on top of that they're polite — when you describe your idea and ask if they'd use it, they hear please say yes and they oblige. A hypothetical "would you…?" almost always returns a friendly, useless yes.

The fix is to anchor every question in something that already happened.

Instead of (hypothetical)	Ask (past behavior)
"Would you use a trip-planning feature?"	"Tell me about the last trip you planned. Walk me through it."
"Would you pay for trip insurance?"	"The last time you booked travel, did you add insurance? Why or why not?"
"Is saving trips useful to you?"	"Show me the last thing you tried to save or come back to in an app."

Past behavior is evidence. Future intentions are guesses wearing a confident face.

When Tessa re-ran her interviews the right way, the "trip ideas" excitement evaporated — none of them had ever hunted for ideas in an app; they all texted a friend who'd been there. That single reframe saved the team from building a feature five people had cheerfully promised to use and never would have.

Lesson 4.5 — From a pile of notes to a sharp insight

After her interviews, Tessa had eleven pages of messy notes and a familiar panic: now what? Notes aren't research. The job is turning them into something the whole team can design around. There are two outputs worth making, and neither is a long report.

The first is a persona — a short, realistic profile of one type of user, capturing their goals, their context, and their frustrations. Not a real individual, but a believable composite drawn from the patterns you heard. Tessa wrote Wanderwell's:

Dana, 34 — works full-time, two kids. Books a family trip maybe twice a year and hates spending an evening on it. Wants to go from "let's go somewhere" to a confirmed booking in under fifteen minutes, on her phone, after the kids are asleep. Distrusts any screen that suddenly asks for sensitive ID.

A persona keeps the team designing for a concrete human instead of a vague "the user." When Dev Okonkwo, the frontend engineer, argued for adding three filter options to the search, Tessa just asked, "Would Dana, at 11pm, tired, use those?" The room went quiet. That's the persona doing its job.

The second output is a handful of key insights — also called problem statements — the sharp, evidence-backed findings that will actually steer the design. From Tessa's interviews:

• Users abandon sign-up because it asks for a passport ID before they trust the company — it feels too soon and too personal.
• People plan trips in tired, distracted moments, so speed matters more than choice.

That's it. Two sentences, each a clear problem the team can attack. The goal of research was never a fat deck nobody reads — it's a few sharp insights everyone can act on.

And there's a quiet career bonus. When Tessa says "we should move the ID step later, because users told us it scares them off here," she wins arguments she used to lose. A designer grounded in research is far more persuasive than one defending personal taste.

Worked example — Five conversations that changed the form

Wanderwell's checkout was leaking. Analytics flagged the what: 60% of users abandon the payment form, most on the screen that requests a passport ID. Priya wanted it fixed, and Marcus handed the discovery to Tessa.

She recruited five recent abandoners and ran short interviews, asking about the past, not the future: "Walk me through the last time you tried to book a trip with us and stopped." She kept questions open and counted to five through the silences. She did not ask "would a shorter form help?"

The pattern showed up by the third interview. Three of five said almost the same thing: the form felt fine until it asked for the passport number, then they got nervous and bailed — "I didn't know if you were legit, and that's a lot to hand over." One added she'd have happily entered it after she trusted the site, just not on first contact.

Tessa turned eleven pages of notes into two outputs. A persona — Dana, 34, tired, fast, allergic to early ID requests — and one problem statement: users abandon because the form asks for sensitive ID before they trust us. No report.

She brought both to the team. Dev proposed moving the passport field to a final, post-payment step, and Tessa redesigned the flow around it. The change wasn't her taste — it was five honest conversations, made undeniable. That's the entire loop: numbers found the wound, interviews explained it, a persona and an insight made it impossible to ignore.