A few years ago, I was working on a CRM (client relationship management system) government staff used to track outreach for a public program in Canada that a lot of people relied on to get their work done. Adoption was lower than it should have been, and the assumption going in was reasonable enough: people didn’t fully understand how to use it. The fix seemed obvious — a new feature here, some training there.
My manager at the time kept telling me not to build on assumptions. I heard it, nodded, moved on. It’s the kind of advice that sounds true before you’ve actually paid for ignoring it.
Once my team — a senior researcher and myself, the junior on the project — sat down with the staff who used the system every day, and asked them to walk us through their actual workflow, the story changed completely. It wasn’t that people didn’t know how to use it. It was that the tool had never really been built around how they worked in the first place — so they’d quietly built their own workarounds instead: spreadsheets on the side, steps done out of order, whole features nobody touched because they didn’t map to anything in a real workflow. No amount of training was going to fix that, because training assumes the tool is right and the person is the problem. It wasn’t.
I was wrong about almost everything I’d assumed going in. I think about that project often, because it’s the clearest example I have of something I now believe applies far beyond research teams: you don’t need a research title to get this right, but you do need the discipline to check your assumptions before you bake them into a product.
Many teams don’t have a dedicated researcher. Not because they don’t value research — headcount is finite, and “researcher” is rarely the first hire on a lean product team. So research either doesn’t happen, or it happens in a way that quietly repeats the mistake I made: confident, well-intentioned, and built on an assumption nobody thought to check.
Research Is a Practice, Not a Job Title — But Rigor Isn’t Optional
Here’s the reframe, with an important caveat. A designer, a PM, a founder, an engineer can absolutely learn to do research that holds up — but only with real rigor, and with the humility to know where the limits are. One limit in particular: you generally shouldn’t be the one researching your own design. Being close to something you built makes it hard to see clearly, and criticism of your own work lands differently than criticism of someone else’s, even when you’re genuinely trying to stay objective. If you can bring in a trained researcher — or even just get coaching from one — that’s always the better path. What follows is for the very real situation many teams are actually in: no researcher, no budget for one right now, a decision that has to get made anyway. This is how to do that as well as it can possibly be done. It is not an argument against hiring a researcher when you can.
I’ve spent the last six years doing UX research inside government agencies and with independent clients, and the teams that got the most value from research were rarely the ones with the biggest research team. They were the ones where almost everyone treated research as a habit, irrespective of who actually held the “Researcher” title.
The Mistakes That Actually Sink Non-Researchers
It’s not that people without research training ask bad questions. It’s a handful of specific, avoidable habits that quietly undermine otherwise good intentions.
Not building trust before asking. Diving straight into pointed questions without first creating a safe, low-pressure space makes people perform for you instead of being honest with you. A few minutes spent putting someone at ease — explaining there are no wrong answers, that you’re testing the product and not them — changes the quality of everything that follows.
Leading questions. “Don’t you think this flow feels smoother?” isn’t a research question — it’s a request for agreement. The person answering will usually give you what you’re fishing for, and you’ll walk away with false confidence instead of a real signal.
Treating five conversations as “enough data.” Five conversations can absolutely be enough — for generating hypotheses, spotting glaring usability issues, or getting directional signal. They are not enough to declare a feature validated or a redesign “confirmed by users.” The failure isn’t talking to five people. It’s not being honest about what five people can and can’t tell you.
Jumping straight to solutions. This is exactly where my own project nearly went wrong. Someone struggles with a system, and the instinct is immediate: it must need a new feature, or better training. Maybe. But that instinct skips the step where you actually understand why they struggled. Fixing the wrong cause with the right-sounding solution is one of the most common and least visible ways research effort gets wasted — and it rarely announces itself as a mistake, because the fix always sounds reasonable in the room.
Confusing what people say with what they do. People are unreliable narrators of their own behaviour — not because they’re lying, but because self-reported intent and actual behaviour diverge more often than most teams expect. “I’d definitely use that” in an interview and actually using it in production are two different data points, and conflating them is how teams end up building features nobody adopts.
Reviewing your own work. It’s one of the hardest mistakes to see from the inside: when you’re too close to something you built, it’s genuinely difficult to look at it clearly, and even harder to hear criticism of it the way you’d hear criticism of someone else’s work. This is exactly why a designer shouldn’t be the sole judge of research on their own design. At minimum, bring in a second set of eyes — a colleague, or ideally someone trained in research — before treating your own read of your own work as the final word.
What “Good Enough” Research Actually Looks Like Without a Dedicated Researcher
You don’t need a lab, a research repository, or six weeks of runway to get something real. What you need is a smaller set of disciplines, applied consistently.
Write down your assumptions before you talk to anyone. This is the single highest-leverage habit on this list, and it’s the one my manager was trying to drill into me before I’d learned the lesson the hard way. Before a conversation or a test, write down what you expect to hear or see — and why. In that same government project, if I’d written mine down in advance — “staff are struggling because the system is confusing, and better training will fix it” — the gap between that assumption and what we actually found would have been obvious immediately, instead of taking weeks to surface. Writing the assumption down turns research from a fishing expedition into an actual test, and makes it much harder to unconsciously steer the conversation toward confirming what you already believed.
Match the research method to the actual question, not to what’s fastest. Trying to validate whether a concept solves a real problem? Talk to people. Trying to see whether people can complete a task without getting stuck? Watch them attempt it, don’t ask them to imagine it. Trying to understand behaviour that unfolds over days, not minutes? A single session won’t show you that, no matter how good your questions are. A surprising amount of “research doesn’t work here” comes down to a method mismatch, not a research failure.
Separate observation from interpretation — and do it in that order. Write down what happened before you write down what it means. “The user paused for eight seconds before clicking checkout” is an observation. “The user was confused by the pricing” is an interpretation, and it might be wrong. Teams without research training tend to collapse these two steps into one, and the interpretation quietly becomes the “finding” without ever being checked against alternative explanations.
Look for the pattern, not the anecdote. One person struggling with something is an observation. Three separate people struggling with the same thing, independently, in the same way, is a pattern — and patterns are what should drive decisions, not the single most memorable quote from your notes.
The Real Cost Isn’t Research. It’s Skipping It.
“We don’t have time for research” almost always means “we don’t have time to reduce risk before we build.” That trade doesn’t disappear — it just moves downstream, to rework, to features nobody uses, to the slow accumulation of small frictions nobody prioritized because nobody was watching for them. If we’d redesigned that government system’s interface without stopping to look first, we’d have delivered exactly what was asked for. It would have looked cleaner. It would have changed very little. If you can hire or consult a trained researcher, do that first — it’s still the better option, for all the reasons above. But when that’s genuinely not on the table, the bar for doing something useful isn’t a research repository or a stats background. It’s curiosity, real rigor, and the discipline to separate what you observed from what you assumed it meant — plus the humility to get outside eyes on your own work. That habit is buildable. It’s just not a substitute for the real thing when the real thing i
