The most expensive sentence in product development is "our users will love this." Teams spend six months building on that assumption, launch, and then discover the workflow makes no sense to the people who have to use it every day. The fix is not a bigger budget. It is talking to a handful of real users before and during the build, with methods that cost days, not months.
We run research on every engagement, including MVPs with tight budgets. This post covers exactly what we do when money is limited, what each method costs, and where the shortcuts stop being worth it.
Why teams skip research, and why they regret it
The usual objections are time and money. A formal research programme with recruited panels and a moderated lab can run R150,000 to R300,000 and take eight weeks. For a startup racing to launch, that feels impossible, so teams skip it entirely and treat launch as the first test.
That trade is worse than it looks. On a recent fintech project we tested a loan application flow with six users before development started. Four of the six stalled on the same document upload step. Fixing it in Figma took two days. Fixing it after launch would have meant reworking the upload service, the validation layer, and the mobile screens: roughly three weeks of engineering. Research did not slow the project down. It bought back time.
5
users find most usability problems in a flow
2 days
to run a full round of remote tests
10x
cheaper to fix a flow in design than in code
What five users can and cannot tell you
Five moderated sessions on a single flow will surface the majority of serious usability problems in that flow. That number holds up in our project data again and again: by the fourth session you are mostly hearing repeats. Five users will tell you where people get stuck, what labels confuse them, and which steps they do not trust.
What five users cannot tell you is which of two strategies will win in the market, how much people will pay, or how a feature performs across thousands of sessions. Those are questions for analytics, pricing tests, and larger surveys. Use small samples for behaviour, large samples for numbers. Mixing those up is how teams end up "validating" a business model with three friendly interviews.
The R15,000 research kit
Here is the baseline kit we run on budget-constrained projects. All of it fits inside two weeks and costs less than a single sprint of rework.
- Five customer interviews, 45 minutes each. Recruit from the client's own customer list or waiting list. Incentive: a R350 voucher per person. Total cost: under R2,000 plus a day of facilitation.
- A clickable prototype test. Build the core flow in Figma, then watch five people attempt three tasks over a video call. No lab needed. One day to prepare, one day to run.
- A five-question intercept survey on the existing site or app to quantify the top complaint you heard in interviews.
- One afternoon of support-ticket mining. Your support inbox is a free research archive. Tag 100 recent tickets by theme and count them.
- A findings workshop. Two hours with the whole team to turn observations into ranked product decisions, not a report that nobody reads.
Guerrilla methods that actually hold up
Some cheap methods produce evidence you can act on. Others produce noise with a veneer of rigour. The reliable ones share a trait: you watch behaviour instead of collecting opinions.
Task-based prototype tests hold up well. So does session-recording review: an hour watching real sessions in a tool like a heatmap recorder will show you rage clicks and abandoned forms that no interview will surface. First-click tests are quick and surprisingly predictive, because users who start a task on the wrong element usually fail the whole task.
What does not hold up: asking people whether they would use a feature, showing a design and asking "do you like it," and surveys written after the team has already decided. People are polite. They will tell you yes and then never log in. Design the study so the user has to do something, and count what they do.
Turning findings into decisions
Research fails at the last step more than the first. A 40-page report lands in a shared drive and the roadmap does not move. We keep outputs deliberately small: a one-page findings summary, a ranked list of problems with severity and effort estimates, and a decision log that records what the team chose to do about each one.
- 1Write each finding as an observed behaviour: "4 of 6 users could not find the statement download."
- 2Score severity: does it block a core task, slow it down, or merely annoy?
- 3Estimate the fix with an engineer in the room, not after the fact.
- 4Decide in the same meeting: fix now, schedule, or consciously accept.
- 5Re-test the fixed flow with three users before it ships.
When to stop being cheap
The lean kit covers usability and comprehension. Spend more when the risk is bigger than a confusing screen: entering a market you do not know, redesigning a flow that carries most of your revenue, or building for a group your team has no contact with, such as field workers or patients. In those cases proper recruitment, diary studies, and larger samples pay for themselves.
Research is a habit, not a phase. We fold it into every design engagement, from the first discovery workshop to post-launch session reviews. If you want help setting up a lean research practice inside your team, that is exactly what our experience design service does.