UX research: finding out what users need without a big budget

Research starts with a question the team cannot answer on its own, not with a method: “why do people drop the booking at step two?”, “how do customers choose a stylist today?”, “will people find the pay button in the new layout?”. Without a clear question, any study turns into a pleasant chat with no conclusions. Nielsen Norman Group warns that an overly broad goal such as “learn more about our users” produces findings nobody can act on.

NN/g lays research methods out along three axes. The first is attitudinal versus behavioural: what people say (surveys, interviews) versus what they do (tests, analytics, A/B tests). The second is qualitative versus quantitative: qualitative methods answer “why” and “how to fix it”, quantitative ones answer “how many” and “how much”. The third is context: whether people use the product naturally, follow a script or don’t use it at all.

It helps to tie methods to the product stage. Early on, when it’s unclear what to build, interviews and field studies help. Once there is a layout or prototype, usability tests. After launch, analytics and A/B tests that compare versions on real traffic. NN/g notes that almost every project benefits from several methods: analytics points to where the problem is, a test explains why.

An interview is a research study, not a sales pitch or a friendly chat. It collects opinions and stories: the person doesn’t try anything, they recall how they acted. That’s why the best questions are about specific past events (“tell me how you booked last time”) rather than general habits — let alone the future.

A usability test shows behaviour: a facilitator gives a participant a realistic task and watches them complete it, while the participant thinks aloud. You can test almost anything — from a paper sketch and a clickable prototype to a competitor’s live website.

The logic is simple: each additional participant mostly repeats problems you have already seen, so new findings shrink. It pays to find the main issues, fix them and test again — fixes may not work or may uncover the next layer of problems. Exceptions: if the product has several distinct user groups (say, customers and administrators), recruit three or four from each; for quantitative metrics such as task success rate five is too few — NN/g suggests around twenty.

If the site or app is already live, some answers are sitting in the data. Analytics shows what and how many: at which form step people leave, what they type into site search, which source caused a traffic drop. But it doesn’t explain the cause. NN/g gives the example: analytics shows where people abandon a form, but only a test reveals why — for instance, they don’t want to hand over their phone number.

• The key flow funnel: service page → form → submit → “thank you”
• Events: button clicks, validation errors, forms opened and closed
• Site search: the words people use for things the site names differently
• Click maps: where people click and what they mistake for a link
• Session recordings: how one specific person moved through the page

Analytics and testing work well as a pair. The numbers point to the place (“most people leave at the time-slot step”), a five-person test explains the cause, and after the fix the same analytics shows whether it helped. In our experience, this is the cheapest loop for small projects: there’s already enough data, and five sessions fit into a handful of meetings.

Raw notes won’t help the team. Put each observation on its own card, group similar ones (a technique known as affinity diagramming) and pull out recurring themes. A problem that came up for three participants out of five matters more than one person’s vivid quote.

A leading question contains the expected answer in its wording. Participants want to be polite and agree — and the team gets confirmation of its idea that isn’t really there. Self-reported data is shaky to begin with: people misremember details, rationalise their actions and say what they think you want to hear.

• Asking about the future: “Would you use…” shows the idea sounds appealing, not that anyone will use it
• Testing on colleagues and friends who know the product or don’t want to upset you
• Prompting during a test and explaining “how it’s meant to work” — after that the session tests nothing
• Asking for opinions on the design before the person has used it
• Running one big study instead of several small iterations
• Collecting data without deciding what you’ll do with it