Good research is not expensive — vague research is. You do not need a lab, a recruiting panel, or a six-week study to learn why users hesitate. These five lightweight methods deliver most of the insight at a fraction of the cost, provided you use each one for what it is actually good at.
Mine your support tickets first
The cheapest research is already sitting in your inbox. Support tickets, chat logs, and refund requests are a record of the exact moments your product confused someone enough that they stopped and asked for help. Export the last three months, group messages by theme rather than by feature, and count the themes. The top three clusters are a usability backlog written by your own customers, in their own words.
When it fits: any product with real users and a support channel. What to skip: automated sentiment dashboards. At this scale you will learn more by reading a hundred messages yourself than by graphing ten thousand — the phrasing people use is half the finding.
Usability tests with five users
Watching five people attempt real tasks with your product surfaces most of the problems worth fixing — by the fourth session you will see the same stumbles repeating. Recruit people who resemble your customers, give them tasks rather than tours (“find and download your latest invoice”, not “here is the invoice page”), and stay silent while they work. The urge to help is strong; resist it, because nobody will be sitting beside your real users.
When it fits: before you commit to building or rebuilding a flow. What to skip: waiting for a polished prototype. A clickable sketch tested this week beats a pixel-perfect build tested next month, because the expensive mistakes are structural, not visual.
First-click tests settle navigation arguments
Where would you click first to change your billing details? A first-click test puts that question to twenty or thirty people against a static screenshot and records where they click. It is fast, remote, and brutally clear: if most first clicks land in the wrong place, the task will fail no matter how good the destination page is, because users rarely recover from a wrong first step.
When it fits: label and menu debates that otherwise run on opinion and seniority. What to skip: testing every screen. Test the entry points to your most valuable journeys — sign-up, purchase, account recovery — and leave the rest alone.
Session recordings, reviewed with discipline
Session-recording tools show you real visitors moving through the real product — and the trap is voyeurism: hours of scrubbed footage with nothing to show for it. Review recordings with a question already in hand, such as “why do people abandon step two of checkout?”. Sample a couple of dozen sessions and note only the behaviour that answers it: rage clicks, back-and-forth loops, form fields typed and retyped.
When it fits: diagnosing a known drop-off your analytics can see but cannot explain. What to skip: watching recordings to “see what turns up”. And treat privacy as part of the method — mask personal data in the tool and disclose the tooling in your privacy policy.
Map the assumptions in the room
Some of the most useful research never involves a user. Gather the people shaping the product and write down every assumption the current plan depends on — “customers compare us on price”, “admins set up the account, not end users”, “people will import their old data”. Then sort them on two axes: how much damage each would cause if wrong, and how little evidence you actually hold. The dangerous-and-unproven corner of that map is your research plan for the quarter.
When it fits: at the start of anything expensive. What to skip: debating assumptions in the abstract. The map exists to route each risky assumption to one of the four methods above, not to win the argument in the meeting.
Turn findings into decisions, not decks
Research that ends in a slide deck changes nothing. End every study with a one-page decision memo: what we asked, what we saw, what we will change, and what we deliberately will not. Give each change an owner and a date, and revisit the memo when the change ships to see whether the problem actually went away.
One discipline keeps the whole practice honest: never run a study without naming, in advance, the decision it will inform. If no decision would change either way, save the money — that is not research, it is reassurance.
None of these methods requires a research team. They require a habit: pick the decision in front of you, choose the lightest method that answers it, and let the evidence do the arguing. Five users, a stack of tickets, and a mapped set of assumptions will carry a small team remarkably far.
If you would like an experienced pair of eyes on a flow that is not converting, our UX and product design work is built on exactly these methods — or tell us what you are seeing and we will suggest where to start.