A few years ago, a founder I was working with told me his team had "done research." When I asked what they had learned, he showed me a deck full of survey charts. Nobody had watched a real customer try to finish a task. Nobody knew why so many people quit during setup. The team was guessing, and the survey made the guess look like evidence.
That gap is what UX research services are meant to close. If you have wondered what a research team actually does all week, or whether you can skip research and go straight to design, this post walks through the work from start to finish. I'll cover the methods, the deliverables, the timeline, the price range, and the situations where the investment pays off. I'll also be straight about when you probably don't need a full programme.
What UX research services actually cover
UX research is the study of what people need, how they behave, and where a product gets in their way. It has two modes. Generative research asks what to build and for whom. Evaluative research asks whether a design works for the people it's meant for.
A complete programme usually includes both. A team that only tests designs can polish a feature nobody wanted. A team that only interviews users can spend months learning without ever checking whether the next screen makes sense. The value comes from running the two modes in sequence, so each round of findings shapes the next.
Our own UX research services package six deliverables: a research plan, user interviews, a contextual inquiry, a card sort and tree test, personas and journey maps, and a Jobs to be Done opportunity map. The names alone don't tell you much, so I'll explain what each one looks like in practice.
The research plan is a single document that states the questions, the user groups, the number of participants, and the methods. It sounds bureaucratic, but it's the piece that stops a project from drifting. When a stakeholder asks mid-project why you're talking to freelance designers when the product serves small clinics, the plan answers that question before anyone argues about it.
The methods behind the work
Most of the fieldwork falls into a few methods. Each answers a different question, and picking the wrong one wastes weeks.
User interviews are the workhorse. A researcher sits with a participant for about an hour and asks about their goals, their routines, and the workarounds they've built. We usually run 10 to 15 interviews per user group, because patterns start to repeat after that and new interviews add less. The surprising findings often come from a single participant describing a spreadsheet they keep on the side, or a sticky note on a monitor. Those details are hard to predict from a survey.
Contextual inquiry goes a step further. Instead of asking people to describe their work, the researcher watches them do it, in the place where it happens. For a hospital scheduler, that means standing beside the desk. For a warehouse supervisor, it means walking the floor during a shift. We usually observe four to six users this way. The method is slower and more expensive than an interview, but people forget steps when they describe a process and don't forget them when they perform it. If you want a deeper walkthrough, the Nielsen Norman Group's overview of contextual inquiry explains the technique well.
Ethnographic research is the broadest of these. It studies a community or a culture over an extended period, often weeks or months, to understand the norms that shape behaviour. I use the term carefully, because many teams say "ethnographic" when they mean a few site visits. A true ethnographic study is rare in product work. More often, a project borrows its habits: long observation, field notes, and attention to what people do when no one is asking them questions.
Card sorting tests how people group and label information. You give participants a set of topics, such as "invoices," "tax forms," and "payment reminders," and ask them to sort the cards into groups that make sense to them. The results show which menu labels users expect. A tree test then checks whether people can find items in a proposed structure. Together they show whether your navigation matches how people think, which matters more than most teams expect. Our programmes usually include 30 to 50 participants for this step, because the patterns need volume to become reliable.
Concept tests show early sketches or prototypes to users and ask what they expect a screen to do. They catch misunderstandings before engineers build anything.
A good UX research company will explain why it picks each method for your project and what it would skip. If an agency proposes the same six methods for every client, that's a sign the plan was written before the questions were understood.
How a project runs week by week
A typical programme takes 4 to 8 weeks, or roughly 20 to 40 working days. The timing depends mostly on recruitment, because finding the right participants is often the slowest step. Here's how the work usually unfolds.
The first week is framing. We agree the research questions, the user groups, and what a successful outcome looks like. Stakeholders sometimes arrive with a solution already chosen, such as "we need a mobile app." Framing is where we ask what problem the app is supposed to solve, and whether the people who would use it have said so.
Recruitment runs in parallel or just after framing, usually taking 3 to 6 days. We screen participants through a panel or from the client's own customer list. Screening matters more than most people think. A participant who uses the product once a year gives very different feedback from one who depends on it daily, and mixing the two muddies the findings.
Generative fieldwork comes next, often over 7 to 15 days. This is when the interviews and contextual inquiry sessions happen. Every session is recorded, with consent, so the team can return to exact phrases later.
Evaluative studies follow, typically 4 to 8 days. Card sorts, tree tests, and concept tests check the early structure and designs against what we heard in fieldwork.
The final stage is synthesis and readout, usually 4 to 7 days. We tag findings, cluster them into themes, and build personas, journey maps, and the opportunity map. The programme ends with a 90-minute readout where the team can ask questions and challenge the conclusions. I think that session matters most, because a research report that nobody discusses tends to sit in a shared folder and get ignored.
What it costs and why quotes differ
Our UX research services run between $25,000 and $60,000. That range is wide, and I'd rather explain it than pretend the number is fixed.
Four factors move the price. The first is the number of user groups. Two groups mean two sets of recruitment, two sets of interviews, and two sets of personas. The second is the number of participants, since each interview has scheduling, facilitation, and analysis costs. The third is the number of methods. A project with interviews only costs less than one with interviews, contextual inquiry, card sorting, and tree testing. The fourth is recruitment difficulty. Finding hospital clinicians or enterprise procurement managers takes far more effort than finding consumers, and that effort shows up in the price.
A programme with one user group, around 10 interviews, and one card sort sits near the bottom of the range. A programme with three user groups, around 20 interviews, on-site contextual inquiry, and hard-to-recruit participants sits near the top. Neither is wrong. The question is whether the scope matches the decision the research needs to support.
When you compare quotes from different UX research agencies, normalize them first. Ask each provider how many user groups, participants, and methods they've assumed. A quote that looks cheap may simply have fewer interviews. I wrote more about this in our post on choosing a UX research agency, which includes a checklist for comparing proposals on the same terms.
When your product needs UX research services
Not every project needs a full programme. Some need only a quick round of usability testing, and some need a UX audit instead. But five situations usually justify a deeper look.
The first is a new product. If your team hasn't spoken with target users, you're building on assumptions. Even a small round of 8 to 10 interviews often changes the first version of the product enough to save months of engineering.
The second is a move into a new market. A product that works for American small businesses may fail for British ones because the invoicing rules and the vocabulary both differ. New user groups usually follow different workflows, so the old personas stop being useful.
The third is low adoption with no clear reason. Analytics can show that people stopped using a feature. They can't show why. Interviews and observation fill that gap.
The fourth is a redesign with no evidence behind it. Teams often redesign navigation because it looks dated, not because anyone tested whether it works. A card sort and tree test before the redesign is cheap insurance.
The fifth is internal disagreement. When product, sales, and design each have a different idea of the customer, shared personas and journey maps end the argument by giving everyone the same reference point.
If none of these fits, a UX audit may be the better first step. An audit reviews what exists, while research asks what people need. Teams that are unsure which they need often start with the audit, then decide whether the deeper study is worth it.
The deliverables you should expect
The most useful outputs from a programme are the ones your team can use on Monday morning. Personas are a good example. A persona is a composite profile built from interview data, and it should describe goals, frustrations, and the context in which someone uses the product. The Nielsen Norman Group's article on personas makes a good case for keeping them grounded in real data rather than invented backstories with stock photos.
Journey maps show the steps a person takes to reach a goal, along with what they think and feel at each step. A useful journey map has specific moments, such as the point where a new user can't find the import button, rather than vague stages like "awareness" and "consideration." We build one journey map per persona, usually covering the stages most relevant to the business question.
The Jobs to be Done opportunity map ranks user jobs by importance and by how well current products satisfy them. A job might be "reconcile invoices at month-end," rated highly important and poorly served. Teams often find that the feature they've spent the most time on serves a job that users rate low, which is a useful thing to learn before the next sprint.
Every programme should also leave behind a searchable repository. We tag findings in a research tool so that the next project can build on this one. That repository is often the part clients value most a year later, when a new feature request arrives and someone asks what users already said about that problem.
Getting value from research after the readout
Research only helps if the findings change something. The teams that get the most value do three things. They assign an owner for each recommendation, they connect the findings to a roadmap decision with a date, and they schedule a short follow-up test once the change ships. Without that loop, a readout becomes a presentation, and the team goes back to its old habits.
I've also noticed that the best outcomes come from involving engineers early. When the people building the product sit in on a few interviews, they understand the reasons behind the findings, and they push back less when the scope changes. That's one reason our researchers stay on through the design phase. The alternative, handing over a report and leaving, often means the findings get diluted by the time they reach production.
If you're weighing whether to start, the honest question is what decision you're trying to make and what you'd do differently with better evidence. If the answer is clear, research is usually worth the cost. If the answer is "we just want to look thorough," spend the money on building something and testing it instead.
If you want a senior team to plan and run this kind of work for your product, start with our UX research services. We reply to project requests within one business day, and we sign an NDA before the first technical conversation if you prefer.
Frequently asked questions
What is the difference between UX research services and usability testing?
UX research services cover the whole question of what to build, using interviews, observation, and card sorting, along with testing. Usability testing checks whether a specific design works, using tasks given to participants. Usability testing is one method inside a full programme, but it doesn't replace the earlier work of understanding users' goals.
How long does a UX research project take?
A typical programme takes 4 to 8 weeks, or about 20 to 40 working days. Recruitment is often the slowest step, so projects that need hard-to-find participants can run longer. Smaller projects with one user group and a few interviews can finish in a shorter window.
How much do UX research services cost?
Our programmes run from $25,000 to $60,000. The price depends on the number of user groups, participants, methods, and how difficult the participants are to recruit. A simpler project with one user group sits near the lower end, while multiple groups with on-site observation sit near the top.
How many participants does a UX research study need?
For user interviews, 10 to 15 participants per user group usually reveals the main patterns. For card sorting, 30 to 50 participants gives more reliable results. For usability testing rounds, Jakob Nielsen's well-known finding is that five participants uncover most of the problems in a single round, which is why teams often run several small rounds rather than one large one.
Can UX research be done remotely?
Yes, for most methods. Interviews, card sorts, and concept tests run well over video calls and online research tools. Contextual inquiry usually needs an in-person visit, because the value comes from seeing the real work environment. A good provider will tell you which parts of the study can be done remotely and which need travel.
What is the difference between a UX research company and a freelancer?
A UX research company usually brings a team with complementary skills, such as a lead researcher, a recruiter, and a synthesis specialist. Freelancers can be excellent, but a single person may struggle with recruitment, multiple user groups, and a tight timeline at the same time. The right choice depends on the project's size and how much continuity you need.
What deliverables should I expect from UX research services?
Expect a research plan, the raw synthesis of interviews, personas, journey maps, and a prioritized opportunity map. You should also receive a readout session where the team can discuss the findings. Ask whether the recordings and tagged notes are included, since they're useful for future projects.
Do I need UX research if I already have analytics?
Analytics tells you what people do, and it's very good at finding where they drop off. It doesn't tell you why they do it or what they expected to happen. Research fills that gap. Most teams benefit from both, using analytics to spot the problem and interviews or observation to understand it.
Is UX research worth it for a startup?
It can be, especially before the first version of the product is built. Eight to ten interviews can show which problem is worth solving and which assumptions are wrong. Early-stage teams often choose a smaller scope than a full programme, then expand the research as the product and budget grow.
What is the difference between a UX audit and UX research?
A UX audit reviews an existing product against usability principles and accessibility standards, then ranks the fixes. UX research studies the people who use the product, or might use it, to understand their needs. An audit answers what's broken today, while research answers what people need tomorrow. Many teams run an audit first and research afterward when the problems are less clear.
