If your app or website is not converting the way you expected, and you have already tweaked the colors, rewritten the copy, and rearranged the buttons, the problem might not be visible from where you are standing. It might require actually asking users what is happening when they use your product.
That is what UX research is. It is one of the most-searched topics by founders and product teams trying to understand why something is not working, and yet it remains one of the most misunderstood parts of the design process. This post breaks down the most common UX research methods in plain language, what each one is good for, and when it makes sense to use them.
Why UX Research Matters Before You Redesign Anything
A common mistake non-design teams make is jumping straight to solutions. Users are dropping off at checkout, so the team redesigns the checkout page. Conversions barely move. The reason is often that the redesign addressed a guess about the problem, not the actual problem.
UX research exists to close that gap. Instead of guessing why users behave a certain way, research methods let you observe or ask directly, which means any redesign that follows is solving a real, confirmed problem rather than an assumed one.
Broadly, UX research methods fall into two categories: methods that tell you what users are doing, and methods that tell you why they are doing it. Most effective research combines both.
Qualitative Methods: Understanding the "Why"
Qualitative methods involve smaller numbers of people but go deep into motivations, frustrations, and thought processes. These methods are best for understanding why something is happening, not how often.
User Interviews
A user interview is a one-on-one conversation with someone who represents your target audience, either an existing user or someone in your target market who has not used your product yet. The goal is to understand their needs, habits, frustrations, and how they currently solve the problem your product addresses.
Good interviews avoid leading questions. Instead of asking "would you like a feature that does X," which almost always gets a polite "yes," good interviews ask about past behavior: "tell me about the last time you tried to do this task, what did you do, and how did it go?"
Interviews are most useful early in a project, when you are trying to understand the problem space, or when something is clearly not working and you need to understand the underlying reasons rather than just the symptoms.
Usability Testing
Usability testing involves giving someone a specific task, such as "sign up for an account" or "find and purchase a product," and watching them attempt it, ideally without any guidance. The goal is to observe where they hesitate, get confused, click the wrong thing, or give up entirely.
This method is particularly powerful because it reveals the gap between how a team assumes a product works and how real users actually experience it. A flow that seems perfectly obvious to the team that built it can turn out to be confusing to someone seeing it for the first time.
Even a small number of test sessions, often five to eight people, tends to reveal the majority of significant usability issues. The value comes from depth of observation, not number of participants.
Diary Studies
A diary study asks participants to record their experiences with a product over an extended period, often days or weeks, noting when and how they use it, what frustrates them, and what works well. This method is useful for understanding behavior that happens infrequently or over time, such as a subscription service, a fitness app, or a tool used periodically rather than daily.
Because diary studies happen in the participant's real environment rather than a test setting, they often surface context that would never come up in a single interview or test session.
Quantitative Methods: Understanding the "What" and "How Many"
Quantitative methods involve larger numbers of people and produce data that can be measured, compared, and tracked over time. These methods are best for understanding patterns at scale, identifying where problems exist, and measuring whether changes have actually improved things.
Surveys
Surveys collect structured feedback from a larger group of users, typically through multiple-choice or rating-scale questions, sometimes combined with a few open-ended questions. They are useful for measuring satisfaction, gauging interest in a potential feature, or understanding broad patterns across your user base.
The limitation of surveys is that they tell you what people say they think, which does not always match what people actually do. Surveys work best when paired with behavioral data rather than used alone.
Analytics and Behavioral Data
Analytics tools track what users actually do inside your product: which screens they visit, where they drop off, how long they spend on a page, and which buttons they click. This data is extremely valuable for identifying where a problem exists, even if it does not explain why.
For example, analytics might show that 60 percent of users abandon a signup flow at step three. That is valuable information, but it does not tell you whether they are confused, frustrated, or simply distracted. This is where qualitative methods come back in, to investigate the reason behind the pattern analytics revealed.
A/B Testing
A/B testing involves showing two different versions of a screen or flow to different groups of users and measuring which version performs better against a specific goal, such as sign-ups or completed purchases. It is one of the few methods that can directly attribute a change in outcome to a specific design decision.
A/B testing works best for refining something that is already functioning reasonably well. It is less useful for diagnosing a fundamentally broken experience, since testing small variations of something that does not work for a deeper reason will not reveal that deeper reason.
Card Sorting and Tree Testing: Understanding How Users Think About Structure
These two methods focus specifically on navigation and information architecture, how content and features are organized and labeled.
Card Sorting
In a card sorting exercise, participants are given a set of items (features, content categories, or menu items) and asked to group them in a way that makes sense to them, sometimes also naming the groups. This reveals how users mentally categorize information, which is often quite different from how a team internally organizes it.
Tree Testing
Tree testing takes an existing or proposed navigation structure, stripped of any visual design, and asks participants to find where they would look for a specific piece of information or feature. It is useful for validating whether a navigation structure makes sense before investing time in designing the actual screens around it.
Both methods are particularly valuable for products with a lot of content or features, where users frequently report that they "can't find" something that technically exists.
Choosing the Right Method for Your Situation
With so many methods available, the right choice usually comes down to the question you are trying to answer.
If you do not know why users are not converting, start with interviews or usability testing to understand the experience from their perspective. If you know something is wrong but not where, start with analytics to identify the specific point of failure, then follow up with qualitative methods to understand why. If you are choosing between two design directions, A/B testing can provide a clear, measurable answer, as long as both directions are reasonably solid to begin with. If users struggle to find things in your app, card sorting or tree testing can reveal how they actually think about your content, which may differ significantly from your internal structure.
Importantly, these methods are not mutually exclusive. A thorough research process often combines a few of them: analytics to spot the problem, interviews or usability testing to understand it, and A/B testing to confirm that a proposed fix actually works.
What This Means for Non-Technical Founders
You do not need to become a researcher to benefit from this. What matters is recognizing that "the design feels off" or "people aren't converting" are starting points for investigation, not conclusions on their own. A good design partner should be able to suggest which of these methods fits your specific situation, run it efficiently, and translate the findings into concrete design decisions.
If a redesign proposal skips straight from "here's the problem" to "here's the new design" without any research step in between, it is worth asking what the recommendation is actually based on. The answer should be more specific than "best practices" or "what looks modern."
The Bottom Line
UX research is not an academic exercise reserved for large companies with dedicated research teams. At its core, it is simply a structured way of replacing assumptions with evidence, whether that means watching five people try to use your app, reviewing analytics to find where they drop off, or asking the right questions in the right way.
The methods themselves are not complicated. What matters is matching the right method to the actual question you need answered, and being willing to let the answer change your assumptions about what needs to be fixed.
