A lightweight UX research process for startups

Startups skip research because they picture months of studies, recruited panels, and a report nobody reads. The useful version is much smaller and fits inside a normal build week. Done right it is the cheapest insurance available against the most expensive mistake a young product can make, which is building the wrong thing well. This covers the core loop lean enough to run continuously, why five users is usually enough, how to interview so people tell you the truth, how to make sense of what you hear without a research team, and how to research at all when you do not yet have users to talk to.

Pick the single riskiest assumption you are about to build on, the thing that, if wrong, wastes the most work. Talk to five of the right people. Watch them try to use the thing, or their current workaround for the problem. Write down what surprised you. That is the entire loop, and it exposes most of the serious problems, because a long-standing finding in usability research is that testing with around five users uncovers the large majority of usability issues in a given flow, after which each additional user mostly repeats what you already saw. You are hunting patterns, not statistics. Three people hitting the same wall is a finding you can act on. You do not need a hundred responses to believe it, and waiting for a hundred is usually just an excuse to keep building without looking.

The most important discipline in lightweight research is to trust behavior over opinion, because what people say they want is unreliable and what they actually do is not. People are poor predictors of their own future behavior and naturally agreeable when asked, so a question like "would you use a feature that does this" reliably produces a polite yes that means nothing. Two habits fix most of this. First, watch people do the real task instead of asking them to imagine it, since watching removes the guesswork on both sides. Second, when you must ask rather than observe, anchor the question to a specific real event: "tell me about the last time you had to reconcile that report," not "how do you usually feel about reconciliation." The last real time actually happened, so the answer is memory rather than fantasy. Stated preference is where research quietly goes to lie to you, and specific past behavior is the antidote.

Synthesis sounds like it needs a specialist, but the lightweight version is something any team can do in an hour. After a few sessions, write each notable observation on its own line, a real quote or a thing you watched someone struggle with, and group the lines that are about the same underlying problem. The groups that keep filling up are your themes, and a theme that three of five people hit is worth acting on. Resist the urge to average opinions into a bland summary; the value is in the specific, repeated friction, not in a consensus that smooths it away. Then, for each strong theme, name the decision it should change this cycle. If a theme does not change a decision, it is interesting rather than useful, and you can let it go.

Lean does not mean one tool for everything. When you have users, a five-person usability test on a prototype answers "can they actually use this," and a first-click test answers "do my labels lead people to the right place." When you cannot talk to users yet, which is common very early, you still have honest options. Analyze how people solve the problem today, including the spreadsheets and workarounds they have cobbled together, because those reveal the real requirements. Study competitors and, more usefully, their public complaints and support forums. Run a fake-door test, where you put the feature’s entry point in front of people and measure whether anyone tries it, to gauge demand before building. Or run a concierge test, where you deliver the outcome manually behind the scenes, to learn what people actually need before you automate it. The bar is never a perfect study. It is one honest signal from reality before you commit weeks of build to a guess.

Lean research is a habit, not a project. One risk, five people, real observation, honest synthesis, and a decision changed this cycle. Run that loop continuously and you make evidence-based calls at startup speed, without a research team and without the months you were dreading. What you learn feeds straight into an information architecture that matches the user’s mental model and an MVP scoped to the one claim you need to prove. If you want a research habit set up inside your team, it can be built with you.