Write impactful user research insights
Empower and encourage your team to make the best decisions possible
Maze’s Future of User Research Report 2026 just dropped and there’s a stat in it that made me stop mid-scroll. Research importance to business strategy nearly tripled in one year. Not doubled. Tripled. 41% of survey participants reported that research now informs both product and broader strategic business decisions. We’ve been saying research needs a seat at the table for years, and now that we’re pulling it up, the pressure is on to keep it there. This report covers where AI actually fits into all of this (not to replace you, but to change what skills you need to be good at).
User research is a support system. With that support, we help our teams:
Mitigate risky decisions
Highlight the most important pain points and unmet needs
Narrow the scope of possible solutions for a problem or unmet need
Make more user-centric decisions
Generate empathy and curiosity toward users
If you think about your user research as a product, those are the goals you try to achieve with your research studies. You are attempting to help teams make less risky, more user-centric decisions and also alleviate the pain point of trying to create meaningful products without a user’s perspective.
Our research is meant to boost our teams, empower them, and enable them to make the best decisions they can, given the information in front of them. This is the crux of user research and, often, one of the most important parts of our job.
When I was earlier in my career, I struggled so much with writing insights. I spent more hours Googling what insights were than writing them (and trust me, I spent many, many hours writing insights). They were an enigma, something that was meant to be magical, motivating, realistic, relevant, and concise.
It seemed nothing I wrote could come close to what everyone called an “actionable insight” (I hate the word actionable, by the way, because it is just such a vague word I tripped over for years). Yet, I also couldn’t find any concrete examples of insights seeing as most of them are kept locked away and confidential. The only real examples I found were ones I didn’t want to replicate. And, while it’s helpful to know what not to do, it doesn’t fully guide you in best practices.
Similar to my first personas and journey maps, my insights fell flat. They didn’t inspire great action and help teams make better decisions. They kind of just relayed the facts of the situation with subjective, vague language.
And, repeatedly, I was disappointed in my work. I felt like I wasn’t filling the full potential of my role and doing what user researchers are meant to. After some time, I decided to dive deeper into researching user research insights and create something that felt good for me, and that helped my teams in all the ways I strived to.
What is a user research insight?
Because it’s more interesting and fun, let’s start with defining all the things that a user research insight isn’t. There are a lot of terms floating out there that seem to get lumped together or used interchangeably with the word insight. Let’s take a closer look at these words and what they mean, independent of the word “insight.”
An observation. An observation, on its own, is not an insight because it cannot tell us why a person is acting in that way. It is simply something you observed happen without additional context surrounding it.
Quantitative data trends. Data trends tell you a lot about what actions users are taking on a product and can also highlight important trends in behaviors, as well as metrics. However, quantitative data doesn’t help explain why something is happening.
A fact. When we simply state a fact, such as “users have a lot to juggle at their jobs” or “participant one has poor eyesight,” we aren’t doing any justice to our projects. Facts are often well-known and lack a high degree of context, and that context is hugely important to insights.
A bug. Something wrong with the product isn’t an insight, but rather a bug that needs to be fixed. A bug is very product-centric, which is different from insights.
A finding. If you have information that will solve something today but won’t have a significant impact in the future, that is most likely a finding, not an insight. A finding typically doesn’t have a big consequence (we will get to define that word later) and is more on the shallow side. You typically have a lot of findings in evaluative research, such as usability tests.
A preference or wish. When a participant says, “I would love this feature...” you can’t use this as an insight. Dig deeper into why they want the particular feature to understand the outcome they desire. This outcome is the underlying motivation and is much more valuable (and closer to an insight) than a feature wish.
An opinion. Opinions are trickier than the above. When a participant expresses their opinion on something, that isn’t necessarily an insight. If a participant says, “Apple products are much better than Microsoft products,” that doesn’t really tell us much, does it? Similar to preferences and wishes, we need to dig deeper to expose the root of this opinion for it to get into the realm of an insight.
To demonstrate this a bit more clearly, let’s take a look at some of the insights I’ve written in the past that are less than ideal and break them down into these categories. This was when I was working at a hospitality b2b company, and we were also exploring residential properties as potential customers. Here is a screenshot from a report I wrote way back when:
Yes, I titled these as “insights.” Feel free to laugh — they make me laugh too. Or, if these look a lot like your insights, know that you aren’t alone! Writing insights is super hard work, and it takes a lot of practice. So, let’s rip my insights apart.
In the rest of the article, I break down what an insight is (and isn’t), using my own painfully bad “insights” from an old report as examples, then show the exact model I use to write insights that actually help teams make better decisions. Paid subscribers get:
A clear definition of what a user research insight is (and what it’s for)
A blunt breakdown of what an insight is not (observation, trend, fact, bug, finding, preference, opinion)
Real examples of “bad insights” and why they fail your team
The components that make an insight land: key learning → why → consequence
A simple way to spot when you actually have an insight (four signals to look for in your data)
The prework that makes insight-writing easier: quick stakeholder interviews + what to ask
A lightweight satisfaction survey you can send after projects, with sample questions
Two fully worked insight examples from generative travel research (package deal anxiety; price volatility distrust)
A finding vs. insight comparison (with a rewritten version that shows how consequence changes everything)
Exclusively for paid subscribers
