WhatsApp
FigmaWhat UX research is
UX research studies the people who use — or might use — your product: their goals, context, behaviour and frustrations. It answers two kinds of question: what should we build (generative research) and does what we built work (evaluative research).
Even small amounts of research change decisions. A handful of interviews can reveal that customers care about a different problem than expected; a few usability sessions can show why a feature has low adoption.
Problems we solve
- Product decisions based on the loudest opinion in the room
- Low conversion or adoption with no clear reason
- Features requested by sales that customers rarely use
- Assumptions about users that have never been checked
- Disagreement about priorities between teams
What’s included
User interviews
One-to-one conversations about goals, workflows and pain points.
Usability testing
Moderated and unmoderated sessions on prototypes or live products.
Surveys
Quantitative input from larger groups of users.
Analytics & session review
Funnels, heatmaps and recordings to find where users struggle.
Card sorting & tree testing
Evidence for navigation and information architecture.
Personas & journey maps
Shared, evidence-based pictures of users and their experience.
Usability testing done well
In a moderated usability test, a participant who matches your target audience attempts realistic tasks while thinking aloud. A researcher observes without leading. Five participants typically uncover most major usability problems in a given flow. Findings are prioritised by severity and frequency and turned into concrete design recommendations, often with redesigned screens.
Recruiting the right participants
Research is only as good as the participants. We recruit from your customer base, trial users or specialist panels using screening criteria that match your audience — role, industry, experience level and usage patterns. For B2B products, we help you invite customers in a way that strengthens relationships rather than burdening them.
Choosing a research method
| Question | Suitable methods |
|---|---|
| What problems do users have? | Interviews, contextual inquiry, diary studies |
| Can users complete key tasks? | Moderated or unmoderated usability testing |
| How should we organise content? | Card sorting, tree testing |
| Which version performs better? | A/B tests, preference tests |
| How many users experience this? | Surveys, product analytics |
| How do we compare with competitors? | Competitive usability benchmarking |
Qualitative methods explain why; quantitative methods show how many. Most projects benefit from a mix.
Turning research into decisions
Research only creates value if it changes what the team builds. We make findings easy to act on:
- Short summaries with prioritised findings and severity, not long reports
- Video clips of real users that bring issues to life for stakeholders
- Clear recommendations linked to specific screens or flows
- A shared research repository so insights are not lost between projects
- A follow-up check to confirm whether changes solved the problem
Research on a small budget
Even a handful of usability sessions per round reveals most major issues in a flow. Short, regular rounds — testing a prototype every few weeks — are usually more valuable than one large study at the end.
Ethics and consent in research
Participants share their time, opinions and sometimes sensitive information. Good practice includes clear consent forms explaining how recordings and data will be used, fair incentives, the right to stop at any time, storing recordings securely with limited access and deleting them after an agreed period. Research with vulnerable groups, patients or employees needs extra care, and sometimes approval from legal or compliance teams. Treating participants well also produces more honest feedback.
Research across the product life cycle
Research is most useful when the method matches the question you need answered at that moment. Early on, the risk is building something nobody needs; later, it is building something people cannot use; after launch, it is not knowing why behaviour changes. Each stage calls for different tools.
| Stage | Key question | Methods that fit |
|---|---|---|
| Discovery | What problem matters most, and to whom? | Interviews, contextual inquiry, diary studies, support-ticket analysis |
| Concept | Does this solution make sense to users? | Concept tests, card sorting, paper or clickable prototypes |
| Design | Can people complete key tasks? | Moderated usability tests, tree testing, first-click tests |
| Pre-launch | Is anything blocking adoption? | Unmoderated tests, accessibility reviews, beta programmes |
| Post-launch | What is happening, and why? | Analytics, session recordings, surveys, follow-up interviews |
Most projects combine two or three methods rather than relying on one.
Qualitative and quantitative research together
Quantitative data — analytics, funnels, survey scores — tells you what is happening and how often. Qualitative research — interviews and usability sessions — tells you why. Used alone, each misleads: analytics can show that half of users abandon a form but not that a confusing label causes it; five interviews can surface a problem but not how widespread it is.
We usually start from the numbers to find where to look, then use qualitative sessions to understand the cause, and finally check the fix with the numbers again. This loop keeps research focused on decisions with measurable impact rather than on interesting observations that change nothing.
Building a research repository
Research loses value when findings live in slide decks nobody opens again. A lightweight repository makes insights reusable across teams and stops the same questions being studied twice.
- A single place for findings, tagged by product area, user type and theme
- Short, plain-language insight statements linked to the evidence behind them
- Recordings and notes stored with consent and retention rules applied
- A simple way for product managers and engineers to search before starting new work
- Regular reviews to retire findings that no longer reflect the product
Common research mistakes
- Asking users what they want — people are poor predictors of their own future behaviour; observe what they do instead.
- Leading questions — “Wouldn’t it be easier if…” produces agreement, not insight.
- Testing with colleagues — internal staff know too much about the product to represent real users.
- Researching after decisions are made — research that cannot change the plan is wasted effort.
- Reporting everything — a list of 60 observations is harder to act on than the five that matter most.
How to tell whether research is paying off
Good research shows up in product outcomes rather than in the number of studies completed. Signs it is working include fewer features rebuilt after launch, faster task completion in usability tests between rounds, fewer support tickets about confusing workflows, and product decisions that reference evidence instead of opinion. We agree two or three of these measures at the start of a research engagement so its value can be judged honestly.
Research findings feed directly into product design and design systems work, so improvements carry across the whole product.
Sharing findings so teams act on them
Research only matters if it changes what gets built. We present findings in short sessions with the people who make decisions — product, design and engineering — and show short video clips of real users struggling or succeeding, which is often more persuasive than any slide. Each finding is paired with a severity rating and a recommended next step, and we agree owners before the session ends.
Related services
Research feeds product design and is part of our UI/UX design services. For accessibility needs see accessibility testing.
This page is part of UI/UX Design Services — see the full overview for related services, approach and pricing.