UX Research Methods: When and How to Use Each

TL;DR: What You Will Learn

• Research methods split along two axes: attitudinal (what people say) versus behavioural (what people do), and qualitative (why) versus quantitative (how many).
• No single method does everything, so the skill is matching the method to the question you are trying to answer.
• Use exploratory methods early to understand needs, and evaluative methods later to validate designs before you ship.
• This article walks through each method and the exact situation it fits, so you can stop guessing.

Jump to whichever section matches your situation, or read straight through to build a mental map of the full toolkit.

Why User Research Matters Before You Build

I have watched teams spend three sprints building a feature nobody wanted, then quietly kill it after launch. That is the quiet cost of skipping research, and it is entirely avoidable.

The core idea behind user research methods is simple: they replace guesswork with evidence before you commit engineering time and money. When you understand who your users are and what trips them up, you de-risk every decision that follows.

Assumption-led design says “users will probably get this.” Evidence-led design says “we tested it with eight people and six got stuck on step two, so we changed the label.” One of these ships confidently. The other ships and hopes.

Consider a government service team improving a task flow on the LifeSG app. After running usability sessions, they might discover that users abandon a form because a field name is ambiguous. A small copy change, informed by watching real people, can lift task completion far more cheaply than a full redesign later.

The Cost of Skipping Research

Rework is the most obvious tax. Every wasted development sprint on a misunderstood feature is budget you cannot get back, plus the morale hit of scrapping work.

Churn is the sneakier cost. A local bank rolling out a new digital onboarding flow might see drop-off spike at identity verification, and without research, they are left guessing whether it is the copy, the layout, or the third-party integration.

Research also reduces support tickets. When you fix confusion upstream, your customer service team stops fielding the same three questions every day, which finance leaders notice quickly.

Attitudinal Versus Behavioural Insight

These two axes attitudinal versus behavioural, and the qualitative versus quantitative split covered next come from Christian Rohrer’s method-mapping framework at the Nielsen Norman Group. There is a gap between what people say and what they actually do. Attitudinal data captures opinions and stated preferences, useful for understanding motivation and perception.

Behavioural data captures actions: where someone clicks, where they hesitate, where they rage-quit. If a user tells you they love a feature in an interview but analytics show they never open it, the behaviour is the truth you build on.

You need both. Attitudinal insight tells you why, behavioural insight tells you what, and mature teams triangulate the two.

Qualitative Versus Quantitative Data

Qualitative methods, like interviews and usability tests, explain the reasons behind behaviour with small samples and rich detail. They answer “why is this happening?”

Quantitative methods, like surveys and analytics, measure how widespread a pattern is across many users. They answer “how many” and “how often.”

Reach for qualitative when you are exploring a problem you do not yet understand, and quantitative when you need to size or validate it. This choice becomes clearer once you grasp the difference between UI and UX, because research shapes the experience, not just the screen.

Research is not overhead; it is how you protect conversion, retention, and your development budget all at once.

User Interviews for Deep Qualitative Insight

When I need to understand why people behave the way they do, nothing beats a one-on-one conversation. Among all the user research methods I reach for, interviews are the ones I trust most in early discovery, before a single wireframe exists.

Interviews shine when you are trying to uncover motivations, pain points, and the messy context around a problem. If a survey tells you what people do, a good interview tells you why they do it.

Picture this. Say your team is designing a QR payments feature for hawkers. Before you build anything, I would spend an afternoon at a hawker centre in Toa Payoh, talking to stall owners about how they handle cash, GST, and the rush at lunch. You will hear things a spreadsheet never captures, like a fear of fumbling with a phone while a queue builds up behind an impatient office crowd.

The same applies to SME owners. Interview a small trading firm before designing an invoicing tool, and you might learn they still WhatsApp photos of paper receipts to their bookkeeper. That single insight can reshape your whole design.

Structuring Your Interview Guide and Asking Open Questions

I write a loose guide, not a script. It usually opens with easy warm-up questions, moves into a handful of core topics, then wraps up with a broad “anything I did not ask about” question.

The golden rule is to ask open, non-leading questions. Instead of “Do you find cash payments annoying?”, which plants an answer, I ask “Walk me through the last time you took payment at your stall.” Then I stay quiet and let them talk.

Recruiting and Screening the Right Participants

Talking to the wrong people is worse than talking to no one. I always write a short screener to filter for the actual users, so if the feature is for hawkers who currently avoid digital payments, I screen out those who already use them daily.

Aim for people who genuinely represent your target segment. Five to eight well-screened participants usually surface most of the big themes, a range that lines up with saturation research on qualitative interviews: across sixty in-depth interviews, Guest, Bunce and Johnson found the main thematic elements emerging as early as six interviews, with saturation typically reached within twelve Guest, Bunce & Johnson, 2006.

A quick word on PDPA. If you record audio or video, get clear consent first, explain how the recording will be used, store the files securely with access limited to your team, and delete them once your analysis is done.

Synthesising Transcripts Into Themes

Raw transcripts are not insight. I read through each one, tag recurring ideas, then cluster those tags into themes such as “distrust of digital fees” or “speed matters more than features”.

From there, I write insight statements, short sentences that capture a finding, like “Hawkers avoid QR payments because reconciling takings at closing feels risky.”

Two pitfalls to avoid. Leading questions quietly bias your data, and a tiny unrepresentative sample can send you confidently in the wrong direction.

Interviews reveal the why, not how widespread an issue is. That is exactly why I pair them with surveys, which I will cover next, to size up how common the patterns really are.

Surveys for Scale and Quantitative Validation

When I have talked to eight users and they all seem to want the same thing, my next question is always: how many of our actual customers feel this way? That is exactly what surveys are built for.

Among user research methods, surveys are the tool I reach for when I need to measure how widespread a need, attitude, or behaviour is across a large group. Interviews tell you a story. Surveys tell you how many people share it.

Picture a Singapore SME running a small chain of dental clinics. They can use SkillsFuture-funded upskilling to train a staff member to run a customer satisfaction survey or measure Net Promoter Score after each visit, so they know whether one grumpy patient reflects a broader problem or just a bad day.

Writing Unbiased, Single-Focus Questions

The fastest way to ruin a survey is a leading question. If you ask “How much did you love our fast, friendly service?” you have already told respondents the answer you want.

Keep each question to one idea. “Was the booking process easy and was the price fair?” is really two questions, and you will never know which half someone was answering.

For attitudes, I lean on a balanced Likert scale, usually five or seven points from strongly disagree to strongly agree, with a genuine neutral option in the middle. Avoid stacking a scale with three positive labels and one negative.

Sampling and Reaching Useful Numbers

A survey with twelve responses is just a slow interview. To validate anything quantitatively, you need enough responses to be confident the pattern is real and not noise.

Send it to a representative slice of your users, not just your most loyal fans who reply to everything. If you distribute via email, tools like these 9 user-friendly email marketing tools make it easier to reach a broad list and track who actually responded.

Under the PDPA, you must get clear consent to collect and use responses, and you should anonymise data wherever you can. Tell people why you are asking and how their answers will be handled.

Analysing Closed Versus Open Responses

Closed questions, scales, and multiple-choice give you clean numbers you can chart and compare over time. Open text boxes give you nuance, but they take real effort to read and code into themes.

I usually keep open questions to one or two, placed near the end, so I capture the “anything else?” without exhausting people.

That last point matters. Survey fatigue is real, and a bloated form gets abandoned or answered carelessly.

Remember what surveys can and cannot do. They tell you what and how many, but rarely the deeper why, which is why I pair a strong survey with a handful of follow-up interviews to understand the reasoning behind the numbers.

Usability Testing to See Real Users Struggle and Succeed

Most of us fall in love with our own designs. Usability testing is the reality check that shows you where real people get stuck, because you watch them attempt genuine tasks instead of asking whether they like your layout.

Picture a small Singapore fashion brand selling on a Lazada storefront. You hand a shopper a phone and ask them to add a dress in size M to the cart and complete checkout, then you sit quietly and watch them hunt for the size selector, hesitate at the delivery options, and abandon at the payment screen.

That moment of struggle is the finding. The same approach works on a government portal, say, a resident trying to submit a form on an HDB or CPF service page– where you learn exactly which field wording confuses people.

To keep users talking, I use a think-aloud protocol: ask them to narrate their thoughts as they go, so you hear the hesitation before the click, not just the outcome. Among the many user research methods available, usability testing is the one that most directly exposes friction in something you have already built.

Moderated Versus Unmoderated Testing

Moderated testing means you are present, live, either in person or over a video call, so you can probe with follow-up questions when someone pauses. It suits complex flows or early prototypes where you need to understand the why behind a stumble.

Unmoderated testing sends the task to participants who complete it on their own time through a tool that records their screen. It is faster and cheaper, and it fits simple, well-defined tasks where you mainly need to see where people click.

If your budget is tiny, you can still run guerrilla testing. Set up at a mall atrium or even a void deck, offer someone a kopi or a small voucher, and ask three or four passers-by to try one task on your phone.

Writing Realistic Tasks and Success Criteria

A good task scenario mirrors real life and never hints at the answer. Instead of saying “click the blue Buy button”, say “You want this dress delivered before Chinese New Year, so order it and choose the fastest delivery.”

Define success before you start. For that checkout, success might be reaching the order confirmation screen without help within two minutes, which gives you a clear pass or fail rather than a vague gut feeling.

Finding Real Problems with a Handful of People

You do not need a crowd. This is one of the most established findings in the field: Jakob Nielsen of the Nielsen Norman Group showed that testing with just five users typically uncovers around 85% of a design’s usability problems, because after the first few people, the same issues keep resurfacing.

The figure comes from a mathematical model of usability-problem discovery that Nielsen developed with Thomas Landauer Nielsen & Landauer, 1993. So with around five participants you will surface the biggest, most repeated issues, and additional testers mostly confirm what you already saw. (Nielsen’s caveat is worth keeping in mind, though: five is a guide for iterative testing on a fairly similar group of users, not a universal cutoff for every study.)

After each session, I give every problem a severity rating, from minor cosmetic annoyances to blockers that stop the task entirely, so the team fixes the painful issues first. When you prototype these flows to test, a step-by-step Figma tutorial for beginners walks you through building a clickable version fast: a step-by-step Figma tutorial for beginners.

One caveat: usability testing measures how well an existing design works. It tells you nothing about what to build from scratch, so pair it with discovery methods when you are still deciding what the product should even do.

Analytics and Behavioural Data to Reveal What Users Actually Do

When you ask people what they do on your website, they often tell you what they think they do, or what they wish they did. Behavioural data cuts through that by showing what actually happened, at a scale no interview can match.

This is one of the most underrated user research methods because the data is often already sitting in your account, waiting to be read. If you want a grounding in the mindset, it helps to understand what data analytics is and why it matters before you start pulling reports.

Funnels and Drop-Off Analysis

Picture a Singapore online retailer selling homeware, watching sales stall despite strong traffic. In Google Analytics 4, you build a funnel from product page to cart to checkout to purchase, and suddenly the leak is obvious: most people add to cart, but a huge share vanish at the shipping step.

That single view tells you where to look. Maybe delivery costs only appear at the end, or the guest checkout is buried.

A funnel tells you where users drop off, but never why they drop off. That gap is exactly why analytics alone is not enough.

Heatmaps, Session Recordings, and Click Tracking

To get closer to behaviour, tools like Hotjar or Microsoft Clarity add heatmaps, session recordings, and click tracking. On that same checkout page, a heatmap might show everyone clicking a promo banner that leads them away, while session recordings reveal people repeatedly tapping a form field that will not accept their postal code.

These recordings are powerful, but they involve capturing user activity, so you must handle them responsibly. Under Singapore’s PDPA, and given cookie consent expectations, you need a clear cookie banner and privacy notice explaining what you track before recording sessions or setting analytics cookies.

Event Tracking to Answer Specific Questions

Standard reports answer general questions. Event tracking answers your specific ones.

If you suspect a filter is confusing, set up an event in GA4 that fires when someone applies it, then compare conversion rates for users who use it versus those who do not. You can track events like these:

• Clicks on a specific call to action button
• Use of on-site search and the terms entered
• Applying or clearing product filters
• Reaching a particular scroll depth on a long page

Design your events around a hypothesis, not just to collect everything. Vague tracking produces dashboards nobody acts on.

Turning Numbers Into Hypotheses To Validate

Here is the discipline that ties it together. Read the data, form a clear hypothesis such as “users abandon because shipping cost is a surprise”, then validate it qualitatively.

Run three or four quick usability sessions or short interviews with recent buyers to hear the real reason in their own words. Analytics points you to the problem at scale; talking to people confirms the cause so you fix the right thing.

Field Studies and Contextual Inquiry in the Real World

Some things you will never learn from a survey or a lab session. You have to go and watch.

Among all the user research methods I use, field studies are the ones that consistently surprise me, because they capture the context that people forget to mention when you interview them in a quiet room.

Why Leaving the Office Changes Everything

A lab is clean, quiet, and controlled. Real life is not.

Picture shadowing a food delivery rider in Singapore during the lunch rush. In a lab, they might tell you the app works fine. On the ground, you see them squinting at a screen in glare, fumbling one-handed while balancing a thermal bag, and losing signal in a basement carpark at a condo drop-off.

None of that shows up in a questionnaire. You only capture it by being there.

I have seen the same gap when observing clinic staff using a new appointment system. They had memorised awkward workarounds so ingrained that they no longer noticed them, so they described the workflow as smooth when it clearly was not.

Contextual Inquiry: Observe and Ask

Contextual inquiry is my favourite structure for fieldwork. Developed by Hugh Beyer and Karen Holtzblatt as part of their Contextual Design methodology (Beyer & Holtzblatt, 1998), it works through a master-apprentice relationship where the user is the master, and you are the apprentice.

You watch them do their real task, then ask questions in the moment: why did you tap there, what are you waiting for, what happens if this fails? You interpret what you see together, then validate your understanding by playing it back to them.

Doing this while a commuter uses a transport app on a crowded MRT reveals things no screen recording will. You notice they check the map before the platform doors open, then stop looking once it gets packed because they cannot raise their arm.

When it is Worth the Effort, and the Practicalities

Field research is time-intensive, so I do not reach for it lightly. Reserve field studies for high-stakes or poorly understood problems, especially complex workflows, physical environments, and edge cases you cannot recreate in an office.

Before you go, sort out consent and photography permissions. Under PDPA, you need clear consent to observe, take notes, and especially to capture photos or video, and you must be careful about any bystanders or third parties who appear in your recordings.

A few practical habits I rely on:

• Get written consent that names exactly what you will record and how it will be used.
• Take timestamped notes and jot direct quotes, not just your interpretations.
• Ask before every photo, and blur or avoid faces and screens showing personal data.

The payoff is rich, situated insight you simply cannot fake. Just go in knowing it costs real time, so use it where the stakes justify the trip.

Choosing the Right Method for Your Question and Stage

By now you have seen that every method answers a different question. The hard part is not knowing the methods; it is picking the right one for the decision sitting in front of you.

The single best filter is your research question, not your budget or your habit. Start by asking what kind of answer you actually need before you reach for a tool.

Matching Methods to Discovery Versus Evaluation

If your question is “why do people behave this way” or “what do they even need”, you are in discovery, and you want generative, qualitative work like interviews and contextual inquiry.

If your question is “does this design work” or “how well does it perform”, you are in evaluation, and you want usability testing, surveys, or analytics.

Here is a simple if-this-then-that guide you can keep on hand:

• If you need to understand a problem you barely know yet, then run in-depth interviews.
• If you need to know how many users feel a certain way, then run a survey.
• If you need to know whether people can complete a task, then run a usability test.
• If you need to know what real users actually do at scale, then read your analytics.
• If you need to decide between two designs quickly, then run an A/B test or a first-click test.

Triangulating Multiple Methods for Confidence

No single method gives you the full picture, and mixing methods is how you buy confidence.

Picture a Singapore SME building a home services booking app. They start in discovery with six interviews to learn why customers abandon bookings, then send a survey to a wider list to size how common each reason is, then run usability testing on the redesigned checkout to confirm the fix works.

That sequence- interviews, then survey, then usability testing- moves them from “why” to “how many” to “how well” across one product cycle. Each method covers the blind spots of the last.

Budgeting Time and Money Realistically

Be honest about what you can afford, because a rushed study of the wrong type is worse than a small, focused one done well.

A tight discovery sprint of five interviews can be done in a fortnight by one person. A survey with clean, unbiased questions takes longer to design than most teams expect, so plan for iteration.

If your team is thin on skills, this is where SkillsFuture course subsidies help. Sending a designer or product owner on a subsidised UX course means the next study is planned properly rather than reinvented from scratch, and it pays back across every project after.

If you are hiring for this capability instead, these 10 UX designer interview questions will help you probe whether a candidate can actually match method to question rather than just naming tools.

The takeaway is simple: there is no best method, only the best method for the decision you must make right now. Start from the question, respect the product stage, and layer methods when the stakes are high.

Common Mistakes That Undermine UX Research

Even the best user research methods fall apart when the process around them is sloppy. I have watched teams pour weeks into research, then quietly ignore what they found. Let me walk you through the traps I see most often and how to sidestep each one.

Recruiting the Wrong People and Leading Them Astray

Picture a fintech startup in Singapore validating its budgeting app only with founders’ friends and family. Everyone nods politely, so the team feels reassured. The problem is that friends are not your target users, and they will not tell you the app is confusing.

The fix is simple: screen for people who match your actual audience, even if that means recruiting slower or paying for participants.

Once you have the right people, do not undo it with leading questions. Asking “You’d find this dashboard helpful, right?” plants the answer. Instead, ask neutral, open questions like “Walk me through how you’d check your spending this week.”

Confirmation Bias and Single Method Over-Reliance

Confirmation bias creeps in during analysis, when you highlight the two quotes that support your idea and skim past the five that contradict it. I always ask a second person to review raw notes independently, then we compare themes before concluding.

Over-relying on one method is another silent failure. A single usability test tells you where people struggle, but it will not tell you how many users hit that wall. Pair qualitative sessions with a survey or analytics to triangulate, so your confidence rests on more than one source.

Researching Too Late and Ignoring PDPA

The most expensive mistake is researching after the product is built. If findings arrive when the code is shipped, leadership will override them because changing course feels too costly. Run research early, when a rough prototype can still be reshaped cheaply.

Finally, do not forget PDPA. If you record interviews or store participant data, you need clear consent on what you collect, why, and how long you keep it. I use a short consent form before every session, and delete recordings once analysis is done.

Here is a quick recap of the pitfalls and their remedies:

• Wrong participants: Screen against your real audience.
• Leading questions: Ask open, neutral prompts.
• Confirmation bias: Have a second reviewer check themes.
• Single method: Triangulate qualitative and quantitative.
• Research too late: Start at prototype stage.
• Ignoring PDPA: Get consent and manage data properly.

A good process is a learnable skill, and it is often what separates hires from rejections, as I explain in why most UX designer job applications get rejected. Structured training turns these mistakes into habits you never repeat.

Conclusion

If you take one thing from this guide, let it be this: great UX research is not about running every method in the book. It is about choosing the one that answers the question in front of you.

We started with a familiar pain: teams building product on top of untested assumptions. The antidote is not more research; it is the right research at the right moment.

So keep the core distinctions handy. Interviews reveal why people behave the way they do. Surveys tell you how many. Usability testing shows how well your design actually works when a real person tries to complete a task. Analytics and field studies reveal what people do in their real context, not what they say in a room.

The strongest insights rarely come from a single source. A dip in checkout conversions in your analytics becomes far more useful once a handful of usability sessions show you exactly where people hesitate. This habit of triangulation, cross-checking one method against another, is what separates confident decisions from guesswork.

Whatever you run, do it responsibly. Recruit with consent, store recordings and personal data carefully, and stay aligned with the PDPA so trust is never the price of your insight.

And do not wait for the perfect project. Pick one method this week, apply it to a real decision you are facing, and let evidence replace assumption.

The fastest way to internalise all of this is to practise it on real problems, with someone experienced looking over your shoulder. If you are serious about moving into UX, Equinet Academy’s UX/UI Design Career Programme takes you through the full process end to end- user research, wireframing, Figma prototyping, and usability testing- and out the other side with a portfolio-ready case study and post-programme career support built around getting you hired. It is SSG-funded, so it is a realistic next step whether you are switching careers or deepening the craft you already practise.