July 8, 2026
“We don’t have budget for research, let’s just build it” is a sentence I’ve heard from more than one client, right before a launch that needed an expensive redesign six months later.
Research is cheaper than rework. A week of talking to five real users costs far less than rebuilding a checkout flow after launch because nobody could find the buy button.
You don’t need a big budget. Five short user interviews or a handful of unmoderated usability tests catch most of the obvious problems. It doesn’t need to be a six-figure research program.
Assumptions are not research. “I think users will…” is a hypothesis, not a finding. The gap between what a founder assumes and what users actually do is usually bigger than expected.
Skipping research doesn’t save money, it just moves the cost later, adds interest, and disguises it as a “redesign.”
Five is usually enough. Nielsen Norman Group’s well-known research found that testing with five users uncovers roughly 85% of usability problems, documented in their piece on why you only need to test with 5 users. The marginal value of a sixth or seventh tester on the same flow drops off fast, which means “we don’t have time” rarely holds up as an excuse.
Watch, don’t ask. The most useful research sessions I run involve handing someone a task, find and book an appointment, and staying quiet while they try. What people say they’d do and what they actually do under observation are frequently two different things.
Test the riskiest screen first. Checkout, signup, and the primary conversion action deserve research budget before a secondary settings page does. Prioritizing by business risk, not build order, gets the most value out of a small research budget.
Unmoderated tools lower the barrier further. Services that let you send a prototype to real testers and record their screen and voice mean research doesn’t require scheduling live sessions at all, removing the last excuse for skipping it entirely.
Research isn’t a phase you either have budget for or don’t, it scales down to fit almost any project size. Teams that skip it aren’t saving money, they’re financing next year’s redesign with this year’s launch budget. For a related take on how process order affects cost, see From Wireframe to Launch: My Web Design Process.
A client launched an online ordering flow that looked polished and had been reviewed internally by a dozen people on the team. Within a month, cart abandonment sat above 70%. A single afternoon of unmoderated testing with five real customers found the cause immediately: the delivery address field appeared before customers could see a price estimate, so people assumed the checkout was longer than it actually was and left. Moving one field would have cost nothing to test before launch, and cost a full redesign sprint to fix after.
The team involved in the original review wasn’t incompetent, they were simply too close to the product to see it fresh. That’s the actual argument for research: not that your team is bad at their jobs, but that nobody can reliably predict a stranger’s first reaction to something they’ve stared at for months.
Research doesn’t need to be formal to be valuable. Asking a friend outside the industry to complete a task while you watch silently, taking notes instead of jumping in to help, catches a surprising share of the same problems a paid research firm would find. The discipline is in staying quiet and watching, not in the budget behind it.
The biggest shift for teams I have worked with is not adding a big research phase, it is treating small research moments as a continuous habit woven into every sprint rather than a special event that only happens before a major launch. A five-minute unmoderated test clip watched during a Monday standup, one clip a week, surfaces more real problems over a quarter than a single big research sprint run once a year, simply because it happens often enough to catch issues while they are still cheap to fix.
The other habit worth building is separating research findings from research opinions in how they get shared internally. “Three out of five users could not find the settings icon” is a finding. “I think the icon should be bigger” is an opinion, even if it came from the same session. Teams that report findings clearly, without immediately jumping to a prescribed fix, end up with better solutions, because the room gets to brainstorm the fix together instead of anchoring on the first idea mentioned.
Research does not need a dedicated researcher on staff to be worthwhile. It needs a standing habit of watching real people use the product, on a small enough scale that it never feels optional, and a discipline around separating what was observed from what should be done about it.
The teams that keep this habit alive longest are the ones who make watching a clip a shared, casual ritual rather than a formal report someone has to prepare. The moment it starts feeling like homework, it stops happening consistently, and a research habit that only runs sporadically loses most of its value compared to one that runs quietly every single week regardless of how busy the sprint is.
A single weekly clip, watched together and discussed for five minutes, has changed more roadmaps in my experience than any quarterly research report ever did.
None of this requires a research background or a big budget. It requires deciding, deliberately, that watching real people struggle with something you built is more valuable than assuming you already know why they would love it. That single decision, repeated weekly, is the entire practice.
Keep it that simple and it will stick far longer than any elaborate research program would.
And if a team ever finds itself debating whether to run one more test or ship the feature as-is, the test almost always wins in hindsight, because the cost of asking is small and the cost of guessing wrong is not.