User research with no time and no budget: a practical guide

Almost every team I've worked with has said some version of this: "We'd love to do research, but we don't have the time or the budget." I understand. Deadlines are real, and a six-week study with a recruitment agency is a hard sell for a startup.

But skipping research doesn't save time. It moves the cost to later, when you discover after launch that people don't understand the feature you spent three months building. Small, scrappy research is almost always better than none. Here's how I do it.

Start with a question, not a method

Research goes wrong when it starts with "let's do some interviews". Interviews about what? Start by writing down the decision you need to make and what you'd need to believe to make it.

• "Should we build bulk upload or improve single upload first?"
• "Why do people sign up but never add their first project?"
• "Do finance teams or sustainability teams own this report?"

A sharp question tells you who to talk to, what to ask and when you've learned enough. A vague one leads to hours of nice conversations that change nothing.

Method 1: Mine what you already have

Before talking to a single new person, look at what your company already knows. Support tickets, sales call notes, app store reviews, chat logs and churn surveys are full of research nobody has read properly.

Spend an hour reading the last fifty support tickets. Tag each one with the problem behind it. Patterns appear quickly, and they come with the users' own words, which is gold for writing labels and messages later.

Method 2: Five short conversations

You don't need twenty interviews to spot a pattern. Five to eight conversations of thirty minutes each will surface most of the big themes for a focused question. Book them back to back over two days and you'll have answers by the end of the week.

The trick is to ask about the past, not the future. People are poor at predicting what they'll do, and excellent at describing what they did.

• "Tell me about the last time you had to do this."
• "What was the hardest part?"
• "What did you try to make it easier?"
• "What happened next?"

Ask what people did, not what they'd do. Behaviour is honest. Opinions are polite.

Method 3: Quick usability tests

If you have a prototype, even a rough one, test it. Give someone a realistic task, like "add a new supplier and invite your colleague", then stay quiet and watch. Where they pause, misclick or sigh is where your design needs work.

Jakob Nielsen's well-known advice still holds: a handful of users will reveal most of the obvious problems. Test with five, fix what you find, then test again with five more. Two small rounds beat one big one, because the second round checks whether your fixes worked.

Remote tests work fine. A video call, a shared prototype link and permission to record is all you need. Ask people to think out loud and resist the urge to help.

Method 4: Let the numbers point, then ask why

Analytics tell you what is happening. They rarely tell you why. Use them to choose where to look. A funnel that drops sharply on step three of onboarding is a clear signal. Watch a few session recordings of people dropping there, then talk to two or three of them.

Numbers and conversations work best together. The data shows you where the fire is. The people tell you what's burning.

Finding people fast

Recruiting feels like the hardest part, but it doesn't have to be. Some quick sources I've used:

• Existing customers. A short, friendly email from the founder gets surprising response rates.
• Your sales and support teams. They know who's chatty, who's frustrated and who's a power user.
• LinkedIn and community groups where your users spend time.
• Friends of friends who match the profile. Not your own friends, though. They'll be too kind.

A small thank-you helps: a gift card, early access or simply a promise to share what you learned. Most people enjoy being asked for their opinion more than we expect.

Making sense of it in an afternoon

Don't let notes sit in a folder for weeks. Synthesise while it's fresh. Write one observation per sticky note, physical or digital, then group them. Look for things you heard from three or more people. Those are your patterns.

Then rank them simply: how often did it come up, and how badly does it hurt? Frequent and painful goes to the top. Rare and mildly annoying goes to the bottom, no matter how passionately one person described it.

Share it so it changes something

Research that nobody reads didn't happen. Keep the output short: one page with the question, what you learned, what you recommend and a few direct quotes. If you recorded sessions, a two-minute clip of a real user struggling will change minds faster than any slide.

A one-week research plan

If you want a template, here's a plan I've used many times. It fits around normal work and produces a clear answer by Friday.

• Monday: write the question and the decision it supports. Read support tickets and analytics for an hour. Send recruitment messages.
• Tuesday: write a short discussion guide and a task or two for testing. Do a practice run with a colleague.
• Wednesday: three or four sessions, thirty minutes each, with gaps in between to write notes.
• Thursday: two or three more sessions in the morning. Synthesise in the afternoon.
• Friday: write the one-page summary, cut a few short clips and share them with the team.

It's not exhaustive, and it doesn't need to be. It's enough to move from opinion to evidence on one important question, which is what most teams are missing.

Writing a simple discussion guide

A guide keeps sessions consistent without turning them into a questionnaire. Mine usually fits on one page:

• A warm-up: who they are, what their role involves, what a normal week looks like.
• The core: three to five open questions about recent experiences related to your question.
• A task, if you're testing something: one realistic goal, described without hinting at the answer.
• A wrap-up: "Is there anything I should have asked but didn't?" This question often uncovers the best insight.

Treat the guide as a map, not a script. If someone says something surprising, follow it. The best findings are often the ones you didn't plan to look for.

Mistakes to avoid

• Leading questions. "Wouldn't it be great if…" will always get a yes.
• Pitching instead of listening. If you're talking more than a third of the time, you're selling.
• Treating one loud voice as the market.
• Researching once and calling it done. Small, regular research beats one big study a year.

Small and often wins

The teams that understand their users best aren't the ones with the biggest research budgets. They're the ones that talk to a user every week, read support tickets every month and test every important flow before it ships.

Start this week. Pick one question, talk to five people and see what changes. I promise you'll learn something that saves you more time than it took.