Most app failures are not build failures. They are insight failures.
User research is the discipline that tests assumptions before they become expensive mistakes. It tells you what your users actually need, how they currently behave, and where the opportunity genuinely sits.
Every app is built on assumptions. The ones that turn out to be wrong are the expensive ones.
Some assumptions are correct. The ones that are not show up later as abandoned sessions, negative reviews, and retention curves that fall off a cliff. By the time the data confirms what went wrong, the budget has already been spent fixing the wrong things.
User research catches those assumptions early. It does not tell founders what to build. It tells them what their users actually need, how they currently behave, and where the opportunity genuinely sits. The rest follows from there.
WAA conducts user research as a core part of its strategy and UX design process. It is also available as a standalone engagement for founders who want to validate before committing to design and development. The work below explains what UX research is, the methods we use, how we run it, and when it makes sense to commission it.
What is UX research?
UX research is the practice of understanding user behaviour, needs, and motivations. It is the work of finding out who your users are, what they are trying to do, and why they currently struggle to do it. Everything that follows in design and development depends on that understanding being accurate.
People often confuse research with analytics. Analytics shows what users do. Research reveals why they do it. A drop-off on a sign-up screen is an analytics finding. The reason behind it, perhaps the language feels invasive, perhaps the value is unclear at that moment, only comes out in research. Both are useful. Only one tells you what to change.
Research sits earliest in the product development process. Ideally before design, always before development. The cost of changing a flow on paper is small. The cost of changing it after a development team has built it is large. Research moves the expensive decisions to the cheap end of the timeline.
There are two broad families of method. Qualitative research, like interviews and usability sessions, answers questions about behaviour and motivation. Quantitative research, like surveys and analytics, answers questions about how many people behave or feel a particular way. Most projects need both, in the right order. Qualitative work shapes the questions. Quantitative work confirms the answers at scale.
The most useful research produces findings the team did not expect. If the research only confirms what the founder already believed, it has either been done badly or been pointed at the wrong questions. Good research often proves you wrong. That is its value, not a problem with it.
The main types of app user research.
Each method answers a different question. The skill is in choosing the right one for what you actually need to learn, and running it well enough that the answers can be trusted.
User interviews
The most valuable and most misused research method. User interviews reveal motivations, frustrations, and mental models that surveys cannot capture. Done well, a handful of interviews shifts the entire direction of a product. Done poorly, they confirm what the founder already believed.
Usability testing
Testing how real users interact with a product or prototype. Where do they hesitate? Where do they get stuck? What do they do that designers did not anticipate? Usability testing catches UX problems when they are still cheap to fix.
Competitor research
Understanding what users already use, what they tolerate, and what they wish worked differently. Competitor research identifies genuine gaps rather than assumed ones. It also stops a team building a feature that the market has already rejected for reasons no one noticed.
Surveys and quantitative research
Useful for validating qualitative findings at scale. Surveys answer questions about how many users feel a particular way. Interviews answer why. Both have a place. Neither replaces the other.
Analytics and behavioural data
For products already in market, behavioural data reveals where users drop off, which features they use, and how long they stay. It is a starting point for research, not a substitute for it. Analytics tells you where to look. Research tells you what you are looking at.
How we approach user research.
Five stages, run in order. Each one exists because skipping it produces a predictable failure mode further down the line.
Research planning
Every research engagement begins with a clear set of questions. Not "what do users think?" but specific, testable hypotheses that the research is designed to confirm or challenge. Without this, research produces interesting observations that do not change decisions.
Participant recruitment
Research is only as good as the people who participate in it. We recruit participants who match the target user profile, not convenience samples of colleagues, friends, or existing customers. This is where most internal research efforts go wrong.
Interviews and testing
User interviews conducted with a structured but flexible guide. Usability testing run against prototypes or existing products. Sessions recorded and analysed systematically rather than by selective memory, so the team is reviewing evidence, not impressions.
Synthesis and insight
Raw research data is not insight. We synthesise findings into patterns, identify the assumptions the research has confirmed or challenged, and produce clear recommendations that feed into design decisions.
Validated personas
Research outputs include validated user personas. Real descriptions of real people built from research evidence, not demographic assumptions. These become the reference point for every design decision that follows.
Into design
The research outputs feed directly into App UX Design and App Planning & Strategy. The personas, the insights, and the design recommendations become the brief, not a separate document that sits beside it.
Want to know what our research process would look like for your product?
Tell us about the product and the problem. We will come back with what makes sense for your stage.
The deliverables.
Every research engagement leaves the client with a complete, usable set of outputs. No interpretation needed. Each document has a job to do in the work that follows.
When to commission user research.
Four moments where research changes what happens next. The earlier of these you are at, the more the research saves you. The later you are, the more the research has to recover.
Before design begins
Validating the problem and the audience before committing to a solution. This is the cheapest point in the project to discover that the brief has a hole in it. It is also the point at which most teams skip the work and then pay for it later.
Before a significant feature build
Testing whether the feature solves a real user problem, or only solves a problem the team thinks users have. A small piece of research here protects a large piece of development budget.
When performance is below expectations
Understanding why users are not engaging or returning. Analytics will tell you where they fall away. Research tells you what was happening in their head at that point, which is the only way to fix it.
Before a rebrand or rebuild
Ensuring the new direction addresses the actual problem. Rebuilds based on internal opinion tend to reproduce the same issues in a new visual language. Research grounds the new direction in evidence rather than fatigue with the old one.
Not sure if research is the right next step?
A short call is usually enough to work out whether a research engagement is what you need at this stage.
Frequently asked questions.
How many users do I need to research?
Five to eight participants for qualitative research reveals the majority of usability issues. This surprises most founders, who assume larger numbers are always better, but the maths is settled. After about five sessions the same patterns start repeating, and each additional participant adds less new information than the one before.
The exception is when you have multiple distinct user groups. If your product serves two clearly different audiences, you need five to eight of each, because their behaviours and motivations will diverge. Quantitative research is a different story and does benefit from larger samples, but for the qualitative work that shapes design decisions, small and well-recruited beats large and convenient every time.
Can I do user research myself?
Yes, with caveats. Founders are emotionally invested in their product, which makes it very hard to hear what users are really saying. The most common failure modes are leading questions, defending the idea instead of probing it, and remembering the responses that confirm the original assumption while quietly forgetting the ones that did not.
If you do run the sessions yourself, write the questions in advance, record everything, and have someone else review the recordings with you. Better still, watch a small number of professionally run sessions first so you can see the difference between asking and selling. You can read more on the common pitfalls in Why do user interviews often give wrong app design answers?
How long does a research engagement take?
Two to four weeks typically. The variable is recruitment, which can take a few days for a broad consumer audience and a couple of weeks for niche or hard-to-reach groups. Scope matters too. A single round of interviews against a defined hypothesis is faster than a mixed-method engagement combining interviews, usability testing, and competitor work.
For a sense of what fits inside a tight timeframe, read more in What does a research sprint actually deliver in two weeks?
How does user research fit with WAA’s other services?
Research feeds directly into UX design. The personas, insights, and recommendations from the research engagement become the brief for the design work, rather than a separate document the team has to translate. You can read more in App UX Design and App Planning & Strategy.
For founders earlier in the process, research can also be the starting point on its own. The output is enough to validate or reshape the direction of a product before any design or development budget is committed.
Three ways to take this forward.
Choose the route that matches where you are. Whichever you pick, the next step is a real conversation, not a sales pitch.
Tell us about your project.
Share what you are building and where you have got to. We will come back with whether research is the right next step and what it would look like for your product.
Send project details →Book a discovery call.
Thirty minutes to talk through where you are and what you are trying to learn. If research is the right next step we will tell you. If it is not, we will tell you that too.
Book a call →See how we price.
What a research engagement costs, what is in it, and how it sits next to strategy and design. Useful if you need to scope a budget before you talk to anyone.
See pricing →