Research that turns product uncertainty into decisions
Most research decks get read once. We run interviews, usability tests and journey mapping designed to settle a specific decision you are stuck on, and we deliver findings ranked by what they should change.
When should product teams invest in research?
Invest in research when a decision is expensive to reverse, when the team is not the user, or when a credible internal disagreement has stalled progress. Otherwise, intuition plus a fast experiment is often better value.
A big build about to start on an untested assumption is the classic case: two weeks of research is cheap insurance against months of building the wrong thing. So is the moment when analytics show precisely where people drop off and nobody can say why. Numbers locate the problem; qualitative research explains it well enough to fix.
Research matters most when you design for people unlike yourselves: operations staff, students, drivers, developers. When the team is not the user, which is most of the time in B2B, intuition fails in ways that are invisible from inside.
Research methods
We choose the method from the decision, not the other way round.
User interviews
Structured conversations that surface behaviour and context rather than opinions and feature requests.
Usability testing
Task-based testing on your live product or a prototype, moderated or unmoderated, with timestamped recordings.
Contextual research
Observing the work where it happens, including the spreadsheet, email or phone call outside your product.
Competitive research
The conventions your users already carry from other tools, and the cost of breaking them.
Journey mapping
The end-to-end path, showing where friction and drop-off actually concentrate.
Concept testing
Early ideas tested with target users before design or engineering commit.
Information architecture research
Testing how people group and find things, before navigation is locked in.
Heuristic evaluation
Expert review against usability principles, to focus a study or as a faster alternative to one.
Quantitative analysis, where available
Your analytics, funnels and survey data used to scope the study and interpret what we observe.
Research across the product lifecycle
Is this the right problem?
Interviews and concept tests to check that the problem is real and worth solving before anything is built.
Does the core flow work?
Prototype testing of the one flow the product depends on, while changes cost a design revision rather than a rebuild.
Why aren't people adopting?
Research on activation and feature discovery, paired with your analytics.
What is actually broken?
Evidence of where users struggle, so the redesign changes what matters and keeps what works.
Did it work?
Usability testing and metric review against the goals agreed at the start.
Research deliverables
Prioritised findings
Ranked by decision impact, each stated as a specific recommendation with the evidence attached.
Session recordings
Timestamped, so your team can watch the relevant moments instead of taking our word for it.
Journey maps
The end-to-end experience, including the parts outside your product.
Competitive and category analysis
What users expect from comparable tools, and where your product departs from it.
Working session
We present, your team pushes back, and together we agree what actually changes.
How research changes product decisions
Research earns its cost when it changes what gets built. At Adda247, research into onboarding and test-taking behaviour across several product modules focused the design work on where learners stalled, not on redesigning what merely looked dated.
We frame every study around a decision before recruiting anyone. If we cannot name the decision the research must inform, we will tell you the research is not worth running. Findings arrive ranked by what they should change, because a themed summary that leaves interpretation to you rarely changes behaviour.
SaaS and enterprise UX research
SaaS UX research
Fast, close to the product, tied to adoption metrics.
- Recruit from your own customers, which is faster and more representative
- Focus on activation, feature discovery and churn signals
- Studies sized to fit a release cycle
Enterprise UX research
Harder to recruit, higher stakes, more stakeholders.
- Specialist and internal users with complex workflows
- Contextual research in the real working environment
- Findings packaged for several stakeholder groups and procurement
How a study runs
Two to four weeks, depending on how hard your audience is to recruit.
Frame the decision (days 1 to 3)
We define what decision the research must inform, or tell you it is not worth running.
Recruit and prepare (days 3 to 7)
Participant recruitment against a defined screener, with a discussion guide and test protocol.
Run the study (week 2)
Interviews or usability sessions, recorded and timestamped, with interim findings shared as they emerge.
Synthesise and present (weeks 3 to 4)
Analysis, prioritised findings and a working session where the team decides what changes.
What does UX research cost?
Standalone studies are fixed-scope and fixed-price. When research is the first phase of a design engagement, it is included in that scope.
What moves the price: the number and type of participants; how hard they are to recruit (your own users are faster and cheaper than specialist or non-customer audiences); the methods involved; whether sessions are moderated; and how many decision areas the study has to cover.
UX research FAQs
What is UX research consulting?
UX research consulting means bringing in specialists to plan, run and synthesise research with your users, so that a product decision rests on evidence. Our studies are framed around a single decision and delivered as ranked recommendations.
How many users do you need to interview?
For usability testing, five to eight participants per distinct user type surfaces the large majority of usability problems. For generative research about a market or behaviour, eight to twelve is more typical. Two well-defined small studies beat one large unfocused one.
Can you recruit participants, or do we provide them?
Either. Recruiting from your own user base is faster, cheaper and usually more representative, so we prefer it. For non-customers or a new segment we recruit against an agreed screener, which adds time and cost.
How is UX research different from a UX audit?
An audit is expert evaluation: we assess your product against usability principles and observed data, quickly. Research is empirical: we observe actual users. The audit tells you what is likely wrong; research tells you what is actually happening and why. If budget allows only one, start with the UX audit.
What do we get at the end?
Prioritised findings ranked by decision impact, each with evidence attached and stated as a recommendation, plus timestamped session recordings and a working session to agree what changes.
Do you do quantitative research too?
We work with your quantitative data rather than generating it. Analytics, funnel analysis and survey data feed into how we scope and interpret a study; our contribution is the qualitative half that explains why the numbers look the way they do.
Can you run research on a product that hasn't launched?
Yes, and that is often when it is most valuable. We test prototypes or concepts with people matching your target profile, when acting on a finding costs a design revision rather than an engineering rebuild.
What decision are you stuck on?
Tell us the decision. In 30 minutes we'll tell you what research would actually resolve it, and whether you need research at all, because sometimes you don't.