How to Do User Research When You Have No Time or Budget

The ideal research setup, a dedicated researcher, a panel of recruited participants, a proper testing environment, weeks of synthesis time, exists at a small number of companies. Most designers work with a fraction of that.

The response to no time or budget should not be no research. It should be lighter research, done faster. Here's how.

Challenge what "no budget" actually means

Before skipping research entirely, get specific about what's actually unavailable.

No money for a research tool doesn't mean no ability to talk to users. No dedicated researcher doesn't mean no research. No time for a full study doesn't mean no time for five short conversations.

"We don't have budget for research" usually means "we don't have a formal research process." That's a real constraint, but it's not the same as not being able to learn anything. Push back on the framing and find the smallest research activity that would give you the most useful signal.

Start with what you already have

Before talking to a single person, exhaust what's already available.

Support tickets tell you what's actually confusing or broken. App store reviews tell you what users love and what frustrates them. NPS comments give you language users use to describe their own experience. Analytics data tells you where people drop off. Existing research from previous projects might be directly relevant.

Spending two hours in support tickets before designing anything often reveals more about user pain points than a week of interviews would. The data already exists. It just needs to be read.

Talk to five people, not fifty

The most common thing that stops designers from doing research isn't genuinely not having time. It's thinking that a smaller study isn't worth doing.

Five user conversations will surface the big, obvious usability problems and the most common misunderstandings. That's usually what you most need to know before a design decision. You don't need statistical significance for qualitative research. You need enough signal to make a better-informed decision than you'd make without it.

One day. Five 30-minute calls. That's real research, even if it doesn't look like it in a slide deck.

Use guerrilla methods

When you can't recruit from a research panel, recruit informally. Ask colleagues in other departments to give you fifteen minutes. Post in a Slack channel asking for someone who uses your product to test something quickly. Walk up to someone in a coffee shop. Ask a customer success team member if they'll let you join a call for one question.

None of these produce clean, representative samples. All of them produce real human reactions to real design decisions, which is vastly better than nothing.

Test the riskiest assumptions first

With limited time and access, you can't test everything. So decide what you most need to know.

The most useful research tests the assumption that, if wrong, would most significantly change the design. Not the thing you're most confident about. The thing where being wrong would cost you the most.

Write your assumptions down before you start. Rank them by risk. Test the top one or two. That's a more effective use of limited research time than a general usability test that touches everything shallowly.

Make research a habit, not a project

The biggest efficiency gain in research is making it continuous rather than running it in formal bursts before major decisions.

Designers who talk to users or customers every two weeks, even informally, even briefly, develop a running understanding of what's confusing, what's working, and what people actually want that's far more valuable than a quarterly research project.

This requires almost no formal budget. It requires a recurring calendar slot and the habit of treating user conversations as part of normal work rather than a special activity that needs to be scheduled and approved.

Document what you learn, even informally

A two-paragraph summary of what you heard from five conversations, shared in Slack or a Notion doc, does more for your team's understanding of users than a finding that only lives in your head.

Making lightweight research visible also builds organisational muscle. Other people see you doing it. They start asking about what you're finding. Over time, informal research becomes part of how the team works rather than something that depends on one person's initiative.