Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

If you’ve ever sat in a strategy meeting and watched the PM, the head of product, and the leadership team trade views on where the company should be in three years, and waited politely for someone to turn to you and ask the “user perspective” question, you’re not alone.

You probably know more about your users than anyone else in that room. You know the gaps in the product, the workarounds people have been building, the unmet needs that have been showing up in interviews for the last four quarters and that nobody has acted on yet. But none of that translates into “where should we be in 2030,” and I don’t think it’s because you don’t know enough. I think it’s because you’ve been pinned to a completely different kind of question for so long that the strategic muscle has gone unexercised.

The roadmap is loaded, the stakeholders need a usability test by Friday, the PM wants to know if the new flow tested cleanly, and there’s another tactical question on your desk before this one is finished. That’s been the whole job, every quarter, for years. The “be more strategic” feedback keeps showing up in performance reviews, the strategy offsite invitation keeps going to product, and you keep getting looped in only when something has already broken.

I think the frustrating part is that we, as user researchers, are the most under-utilised strategic foresight resource in any company. We already do half the futurecasting job by training and instinct, but we just have only ever been allowed to point those skills at next quarter.

Why user researchers were trained for this work

I want to make a case I haven’t seen anyone make clearly enough yet, which is that user research methodology is, structurally, the foundation of futurecasting. We don’t think of it that way because nobody has framed it that way for us, but once you see it, the whole career path opens up.

Here’s what I mean.

We study the past to understand the future

Every method in our toolkit is retrospective. Interviews ask people about past experiences and past behaviors. Diary studies capture recent past behavior. Behavioral analytics is, by definition, a record of what already happened. Journey maps reconstruct past sequences. Usability tests reveal how users have learned to interact with patterns over time. We are trained from day one to extrapolate forward from observed past behavior, which is exactly what futurecasting requires at its core.

When I conduct a generative interview about how someone manages their finances, I’m not really asking about today, I’m building a model of how their behavior has evolved over the last 5-10 years and using that trajectory to predict what they’ll need next. That’s futurecasting, just at the individual user level. The strategic version simply scales it up to the population, the segment, the industry.

We already make defensible calls under uncertainty

Every research recommendation we make is a forecast. “Users will struggle with this flow” is a forecast. “This concept will resonate with mid-market buyers” is a forecast. “The drop-off here will increase if we don’t address X” is a forecast. We just don’t call them forecasts, we call them findings, and futurecasting is the same skill applied to longer time horizons.

We are signal-trained

Researchers spot weak signals in qualitative data for a living. The unprompted aside in interview number seven that becomes the seed of an insight three weeks later, the comment three different participants make in slightly different ways, or the friction users describe but cannot quite name. We are pattern-matchers by craft, which is the single most valuable skill in foresight work.

We have direct access to the most valuable signal source in any futurecasting model

Qualitative user truth, gathered first-hand, is something no industry analyst report can replicate. Most foresight practitioners get qualitative input through commissioned panels and second-hand transcripts. We have it as our day job, which is a structural advantage we have never used at strategic scale.

The reason we haven’t been doing this work is not that we can’t, it’s that we’ve been too busy.

What AI actually changes for researchers

I want to be careful here because I think synthesis is one of the worst use cases for AI. Synthesis is interpretation, and interpretation is the job. The moment we hand interpretation over to a tool, we lose our edge.

What AI actually changes is three different things.

The from-scratch tax goes down

Every research project used to start from a blank page. New discussion guide, new screener, new analysis structure, new readout template, new stakeholder briefing format. With AI, you build the scaffolding once, save it as a reusable skill or prompt, and never start from scratch again. That gets you 2-4 hours back per project, which compounds into days you didn’t have before.

Smarter democratization eases the bottleneck

Custom agents and trained skills mean a PM can run a first-pass usability review or a screener draft without me, which gets me out of the queue and into the strategic seat. I’m not training stakeholders less, I’m training them better, with agents that hold the rigour I’d want them to hold even when I’m not in the room.

AI brings together radically more signal types than one researcher could process by hand

This is the actual unlock for futurecasting, and it’s the one nobody is talking about enough. Doing the work futurecasting requires (interviews plus behavioral analytics plus market trend reports plus competitor product moves plus regulatory shifts plus macroeconomic indicators plus public conversation in customer communities plus adjacent-industry signals) has been functionally impossible at the individual researcher level. AI changes that, because it can hold many signal types in working memory at once, surface cross-source patterns, and let you read the clusters and form your own interpretation.

To be clear, AI is the cross-signal-bringing tool, not the meaning-making tool. We still do the interpretation, the calls, the recommendations.

What futurecasting actually is

Futurecasting is a discipline that generates actionable strategic data for organisations by extrapolating from past and current large-scale trends in a given industry or operating sector. The output isn’t a prediction, it’s a set of plausible scenarios, each with named landmarks the organisation can watch for to determine which scenario is becoming the actual future. The point is to help the organisation prepare for, weather, or thrive through the futures it’s most likely to face.

Three things separate futurecasting from “trend-watching” or “predicting the future.”

Rigor. Futurecasting builds models with structured inputs across past, present, and projected signals. Trend-watching is reading newsletters and forwarding interesting articles. The difference is the same as between a research plan and “let me just chat with some users.”

Scenarios, not predictions. Futurecasting generates multiple plausible futures rather than one bet, because single-point predictions at strategic horizons are reliably wrong. The UXR analogue is the difference between a hypothesis you test and a guess you defend.

Revisitability. Futurecasting models are living documents you revisit quarterly, marking landmarks and updating scenario probabilities as events unfold. Trend reports are dead the moment they ship. The UXR analogue is the difference between a journey map you maintain and a journey map that lives forgotten on a Confluence page.

The reason user researchers are particularly well-positioned for this work is that each of the four points I made in the previous section maps to a specific stage of the futurecasting method. Past-behavior training maps to model-building. Defensible calls under uncertainty map to scenario generation. Signal-spotting maps to the quarterly revisit. Direct access to qualitative user truth runs through every stage.

A short example of what this could look like. A B2B SaaS researcher I worked with noticed across six months of interviews that buyers kept asking variants of the same question, “How do I know your AI features are actually saving us time?” That single weak signal, layered against support ticket data showing rising requests for ROI dashboards and a Gartner trend report on outcome-based pricing, became a futurecasting topic about how mid-market buyer trust in AI-generated work would shift between 2026 and 2029. The model produced three scenarios, the leadership team picked one as the North Star, and the product roadmap shifted from feature-led to outcomes-led six months ahead of any competitor in the space. That’s what this method produces when it’s done well.

If “be more strategic” has been the feedback you keep getting in performance reviews, and you’ve never had a clear path to actually do it, this is the path.

Below, I walk you through the full 5-stage futurecasting method I use as a researcher, with the templates, prompts, and worked examples you can copy this week:

• The futurecasting topic-selection framework (the 5 questions I ask before I commit to a topic, plus the worksheet I use to test whether my topic is actually viable)

• The 3-layer model template (past, present, projected, with the exact 8 signal categories I include and the spreadsheet structure I use to organise them)

• A step-by-step scenario generation process for your specific industry, with worked examples across B2B SaaS, healthcare, consumer fintech, and internal productivity tools

• The North Star workshop format (the 90-minute agenda, the slides, and the “likely vs desirable” voting move that surfaces the strategic disagreement nobody usually names)

• The landmark log template I use to revisit models quarterly and track which scenario is becoming the actual future

• 12 Bad/Better rewrites you can copy across topic, model, scenario, workshop, and revisit stages

• The minimum viable futurecasting practice (how to start with two hours next week)

If you’ve been waiting for a method that turns “more strategic” from a vague performance review note into a real practice, this gives you one.

Exclusively for paid subscribers

Read more

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

I have been thinking a lot lately about the part of research that I find genuinely the hardest, which is not the research itself but the translation work that happens after, where we take what we learned and try to turn it into something a designer can prototype, an exec can act on, or a product team can build into their next sprint. Most of us know what good research looks like, and I think most of us could write a clear interview guide in our sleep at this point, but the harder skill is being the connective tissue between what we found and what the team does about it, and that is the part of the work I keep wanting to get sharper at.

This video is a walkthrough of three workflows in Askable that I have been using to make that translation faster and more directly tied to the metrics stakeholders care about.

What I cover:

1. Designer briefs that turn findings into something a designer can actually prototype. I walk through the prompt I use to generate a designer brief that includes the top three to five most impactful unmet needs, the core user problem, specific behavioural improvements I am hoping to see, and the open questions a prototype could test, all tied back to business and team metrics. What I love about this workflow is that Askable has buttons that push the brief directly into Figma Make, Lovable, or Replit with the evidence cited inline, so designers stop sitting in the in-between state of “what do I do with this?” and can start exploring concrete concepts they can test. I find that this part of the workflow has been one of the bigger bottlenecks in my own practice for years, and being able to remove it has changed how quickly research turns into something tangible.

2. Executive summaries that respect how little time execs actually have. I have lost count of the number of times I have sat down with an exec, prepared what I thought was a tight presentation, and watched them check out by slide three, so the prompt I walk through here is built around getting to the point quickly, with three insights, each one including the problem, the business impact, the supporting evidence, the next steps, and why it is prioritised, tied back to metrics the company cares about. When I do not know the specific metrics a team is tracking, I default to the pirate framework, acquisition, activation, retention, referral, and revenue, since I find that those tend to work as a reliable shared language across almost every product team I have worked with. I also walk through how to layer in industry benchmarks without fabricating numbers, which matters a lot when you are presenting to stakeholders who will go and check your sources.

3. Customised reports for different stakeholders without writing the report ten times. One report has never really served everyone, and I think most of us know that, but most of us also do not have the time to write a tailored version for each team in the company. The workflow I walk through here lets you drill a single research study into different views for different audiences, so the loyalty team gets the loyalty cut, the IA team gets the IA cut, and execs get the strategic overview, all without starting from scratch each time. This part of research has historically been a capacity problem for me and for almost every researcher I know, and being able to address that with a workflow rather than with overtime is something I have genuinely appreciated.

4. The link between prototype opportunities and real metrics is what makes research stick. One of the things I appreciate most about this workflow is that every prototype opportunity is scored on complexity and evidence strength, and tied to specific business outcomes through the pirate framework. The reason that matters is that the hardest sentence for any researcher to earn the right to say is “my research directly moved these metrics,” and when the opportunities in your report are already mapped to the metrics your team is tracking, that sentence stops being aspirational and starts being something you can say honestly in a stakeholder meeting. I think a lot about how to make research feel less disconnected from the business, and this part of the workflow has been quietly useful for me on that front.

5. AI is the glue, not the replacement. The thing I keep coming back to in my own work is that researchers are the connective tissue between evidence and decisions, and I do not believe AI is going to take that role from us. What I do think is happening is that AI is making the production work faster, the briefs, the summaries, the reports, the reformatting for different audiences, so we can spend more of our time on the translation, the storytelling, and the strategic framing that no model can really do on our behalf. Using Askable across these three workflows has reinforced that view for me rather than undermined it, and I am sharing it here because I think it is the most important thing for researchers to keep in mind when we are trying out new tools.

Watch the full walkthrough above, and give Askable a try

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

I sometimes feel bad for personas because they can get such a bad reputation. Well, to be fair, all research deliverables can fall into a bad reputation, from customer journey maps to reports to charts.

However, I will say this:

It 👏🏻 is 👏🏻 not 👏🏻 the 👏🏻 persona’s 👏🏻 fault 👏🏻

(I’m really loving this whole clapping at every word thing recently - what an age we live in that emojis bring emotion to text 😜).

Personas (and other deliverables) are often set up for failure due to many different reasons:

1. They aren’t created with the right information, so they aren’t actionable (I know, I hate that word too and I’ll explain it better later)

2. There are too many created at once, so no one knows which to use when

3. There isn’t enough deep research done to create them, resulting in shallow information

See? The problem doesn’t come inherently from the persona as a deliverable.

So, what is the problem?

I’ve created and seen many personas in my career, and the number one problem, the number one reason people hate them, is:

No one uses the persona after it’s created.

We do all this work for the persona to sit in a corner, sad, alone, and unused. It’s like someone who doesn’t get picked for the dodgeball team. And then we (and others) think:

“What a colossal waste of time!”

And, yes, if the persona goes unused, it is a huge waste of time and energy, not only for you as the researcher but for your team and also your participants. It can be hugely frustrating to create an deliverable that goes unused but, when one takes such a large effort, it’s even more disappointing.

With the personas I have seen, I’m not surprised product/tech people dislike them. So, let’s look at a few of my previous unideal personas* before I bring you through my process of building better personas.

*Please don’t get discouraged if your personas look like this. We all start somewhere and it’s about improvement!

Before we rip apart my previous work (kill your darlings), I just want to remind us what the point and goal of a persona is:

Personas are a tool to help our teams more deeply understand the context of our users so that the team can make better decisions on:

1. What types of features/products/services to focus on

2. What to improve in the current features/products/services

3. What to create next that aligns with users’ needs, pain points, and goals

Ultimately, personas are about alignment. They aren’t magical unicorns that will give us answers to all our questions. We still need to answer the questions, but personas give us data to better answer those questions in a more informed and user-centric way.

My first-ever personas

My first ever user research personas

Aw - good memories. I created these personas in 2014, and they were the first I had ever created (as you may be able to tell).

This was a personal project I did as a case study for applying to user research jobs. The project was about how to rehome animals from shelters better by connecting people who needed to rehome their pets directly with those who wanted to adopt pets. Great concept, in my humble opinion.

However, looking at these personas, and going back to what I mentioned above as the point of personas, you might see where they fall short.

Although I did put in a little story (which I actually like to do now too), there is such limited information in these personas. If I gave these to a team and asked them to make decisions based on them, I wouldn’t be surprised if they told me that they couldn’t do so. In fact, I’d be blown away if anyone said they could make more informed decisions about the topic with these personas.

So, what really doesn’t work about them?

The information in these personas is incredibly vague and shallow. Look at some of the frustrations and pain points for Regina:

• “In a time crunch”

• “Not finding helpful resources”

And now for Adam:

• “Application process very difficult and uninformed”

WHAT DO THESE MEAN?

Absolutely nothing. If I gave you this information and told you to make a product, you’d look at me like I’m Fluffy from Harry Potter (although I think Fluffy is cute). There is absolutely no context, no supporting information. Time crunch? Everyone’s in a time crunch. Helpful resources? Which ones? HOW IS THE APPLICATION PROCESS DIFFICULT?

Also, what do someone’s hobbies, job, and personalily attributes have to do with this topic? Regina is “stubborn” (lol). HOW DOES THAT HELP US MAKE DECISIONS? It doesn’t.

Ah, it hurts me a little bit to see this persona, but IT’S OKAY. We live and learn.

Personas like these exist, and it’s no wonder that people hate them. As a tool, this is completely useless. It’s like, instead of a hammer to hit a nail, I just gave you a stick I found from a tree. A broken stick that’s been run over. These personas aren’t making anyone’s life easier.

My second try

You might recognize this format from my first resume 😂 If you couldn’t already tell, I am not a designer by trade.

But, really, personas don’t have to be pretty. They need to be filled with actionable and contextual information that help your team make better decisions. The sad part is, this persona wasn’t a personal project, it was something I took MONTHS to work on at my first role as a user researcher.

This persona was based on a hospitality platform that hotel staff had to use.

So, let’s break down what isn’t working in this:

• Sliders. No. Just no sliders on anything. Sliders aren’t helpful and usually convey data that is useless or made up. We aren’t here to take a personality test and score on the Myers-Briggs, so why does it matter putting thinking/feeling or perceiving/judging? This gives us NO useful data on users and takes up a good chunk of the deliverable

• Again, all of the information is SO shallow and not at all contextualized for our teams:

  • What does it mean to keep a team functioning happily?

  • What kind of data do they need about staff?

  • What resources are pain points and why?

  • WHAT PRODUCT CRASHES/BUGS? THAT’S A USABILITY ISSUE, NOT A PERSONA!!!!!!!

• Why does it matter if they are on social media? AND WHAT DOES A PARTIAL BAR OF SOCIAL MEDIA EVEN MEAN?

Nothing in this persona screams deepening empathy or helping teams make better decisions. It’s just full of fluffy information.

Again, I have seen a lot of personas that look like this. They completely fail product teams because of the lack of actionable information.

Below, I walk you through the full process I use to build personas that teams actually use (and keep using):

• The reverse-engineered persona workflow (so you stop guessing what belongs in a persona)

• The two workshops that make personas useful (information-gathering + proto-personas)

• Segmentation that doesn’t collapse into demographics (how to pick segments that guide product decisions)

• The research + synthesis system for 20+ interviews (debriefs, mini-synthesis sessions, and what to prioritize)

• Activation that prevents “persona poster syndrome” (how to embed personas into planning, ideation, and decisions)

Exclusively for paid subscribers

Read more

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

Attempt one 💩

The first time I created a customer journey map, I had no idea what I was doing, as you can see below:

I was the first and only user researcher working at a hospitality platform. Not only was I the first and only UXR, but it was also my first and only (real) job as a user researcher. Before this role, I did ad-hoc projects for family/friends and volunteered at charities or organizations to improve my skills (and build case studies).

So when I was tasked with creating a customer journey map, I did the one thing I knew how to do: googled it.

Unfortunately, in that day and age, user research resources were few and far between. I couldn’t simply look at templates online because there weren’t any. I couldn’t read articles on Medium because it was only one year old at the time and not filled with user research content.

So I scrambled and did my best to create the dumpster fire “customer journey map” you see above. Needless to say, people were quite disappointed in the result, but they couldn’t one hundred percent pinpoint why because they weren’t even sure what a customer journey map was. And I definitely wasn’t at the point in my career where I had the ability to ask what people needed and start with the goals.

There sat my customer journey map. Sad, alone, and looking suspiciously like a task flow rather than a journey map. It was a mess, and I was bummed out that I didn’t provide my team with what they needed.

After that, people dropped the concept of a journey map, and we went on with our regularly scheduled usability testing and sending out surveys to a too-small sample size.

However, luckily, over time, I learned to distinguish between a task flow and a customer journey map and how to create one. And I’m going to walk you through the step-by-step process I took to create one of my favorite journey maps I’ve created thus far.

Why and when are customer journey maps important?

Sometimes we tend to rush to decisions to create a deliverable. Someone shouts that we “need” a customer journey map without thinking about why or what we need it for. This very conundrum has led me to create many deliverables that have taken a Herculean amount of effort and, subsequently, have barely been looked at. We want to avoid that situation!

So before diving into how to build a customer journey map, we should explore why and when they can be important.

Why are customer journey maps important?

Customer journey maps highlight what the customer experiences as they interact with a product or service. It is the end-to-end journey someone takes with your product.

Consider when you interact with a digital product or service. It typically takes you several steps to do the things you want to do with the product, or you might come in at different parts of the stage. Some journey maps even show us the decision-making process before someone uses a product or service.

Let’s take a quick example from real-life. About a year ago, my husband and I were planning our end-of-2022 and 2023 trips. As I looked at the (alarmingly large) number of trips we were planning to take (having global families is fun), I thought about the pets and how we would contend with getting someone in to look after them, especially during Christmas and the summer.

I researched the problem and discovered kennels and pet sitters charge enough money that we could have taken several extra trips on top of what we already planned with the money we’d spend on pet care. With this, I found an alternative solution on Trusted House Sitters - you pay a yearly fee, and people travel to your house and stay there for free on holiday while looking after your pets.

Once I found this solution, I filled out all the necessary information about our house, the pets, sitter responsibilities, amenities, a welcome guide, and I set the dates. I then vetted people for the dates we would be gone (ranging from people already living in Jersey but wanting a break from family, to a nomadic couple from France, to a retired couple from the US). I booked them in, and we were done!

If that company wanted to understand the full journey I’d gone through, they would have started by asking me about my entire process, from when I was aware of the problem to when I booked the pet sitters.

And why is this important information to know?

Customer journey maps are a clear visualization that shows the ups and downs someone goes through, the unmet needs not reconciled, the pain points they encounter, and the feelings they have when using your product. It is a clear answer to the ever-burning question of, “what do users think of us?” or “what are users doing on our product?”

Customer journey maps can highlight problem areas in our product and lead us into solution-land, resulting in us either improving what we currently have or innovating to become more advantageous against our competitors.

Not only that, but customer journeys can be wonderful tools to condense a lot of data into a visual that’s easy to present and act on.

When should we use them?

Instead of picking a customer journey map out of a deliverable hat, it’s important to understand that what we want is aligned with what a customer journey map can give us. Usually, that discrepancy is why we are so disappointed with deliverables.

The goals I typically have for customer journey maps are:

• Deeply understand the customer’s end-to-end experience with our product and service

• Identify gaps in the current experience, particularly those that are painful for customers and where we don’t currently support them

• Uncover unmet needs that could lead to improvement or innovation

• Help teams recognize the importance of working cross-departmentally on solving problems by demonstrating the importance of creating a coherent and jointed holistic customer experience, from sales to customer support

• Foster empathy for the current experience across the organization

  ---

Below, I walk you through the full framework I used to turn a sad, dusty “journey map” into a decision tool teams actually used:

• The proto-journey workshop format (how I ran it across six departments without it turning into a blame-fest)

• The interview approach (how I mapped the end-to-end journey across multiple roles, not just the “user”)

• The synthesis workflow (how we combined front-of-house and back-of-house data into one map teams couldn’t ignore)

• The journey map build (what I captured per phase: who, goals, tasks, time, emotions, pain points, plus internal actions)

• The activation plan (the workshops that turned the map into roadmap changes, tighter handoffs, and fewer internal fire drills)

Paid subscribers get the full walkthrough, the workshop agenda, the interview guide, and the exact mapping template I used to build the final artifact.

Exclusively for paid subscribers

Read more

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

I am an avid planner - I always have been, even when I tried to fight it. Planning ahead assures me that things will have a certain outcome and that everyone will be on the same page with expectations if anyone else is involved.

When it comes down to it, for me, planning is about managing expectations.

I didn’t apply this to my professional life for a long time. When I transitioned into user research, I was completely self-taught. Yes, I did a UX Design course at General Assembly, which mainly taught me I can’t design, but other than that, I read books and did my best to piece together the profession.

In my first role as a user researcher, I had little concept of planning. My colleagues and I would talk about research that needed to be done, and I would go and do it. At the time, I didn’t have the capacity to question why we were doing specific projects, asking certain questions, or what the outcomes were supposed to be.

My main downfall, and the reason behind this, was perfectionism. I wanted to appear like I was good at my job and that I knew everything.

We have to survey our users to determine what about our app was unintuitive? Sure thing!

We have to do discovery research to verify our assumptions? Can do!

In fact, I tried:

I didn’t know how to structure a goal — trust me, searching for user research goals and examples of them ten years ago led to absolutely nothing. The Interwebs was not my friend back then.

I didn’t know what to question, let alone how to respond to my stakeholders when they had questions.

What did this lead to?

• Lack of clarity on what I was trying to research (either too broad or narrow in scope), which made it a nightmare to figure out appropriate methodologies and which questions to ask

• Mismatched expectations on what colleagues got as outcomes of the research project

• Inability to focus during the research because I was unsure about what topics I needed to cover or what I could skip

• Little alignment on why we were doing the research project and what would make it successful in the end

What this list leads to is one word: disappointment. I don’t know about you, but (to me) nothing is worse than disappointing my team. And I’ve also found with disappointment comes skepticism. If research isn’t bringing value, do we need to do it? What’s the point?

That’s the last thing I wanted. So, I vowed to do better and, over time, built a research plan that I now use as a starting point (yes, still, to this day!) for my research projects.

What is a user research plan?

A user research plan is a document that lists the different parts of the research project, including why the research is happening to the research outcomes. They give you and the team an amazing overview of the research project and remind people exactly what the project is about, which greatly helps with scope.

The best part of a research plan is aligning people into a shared understanding so that everyone’s expectations are properly set up. Expectations are key when it comes to user research.

If a stakeholder is expecting that they will get a journey map out of a research project and we come to them with a written report, it won’t be the best of times.

Or, if a stakeholder expects deep insights and we conduct a survey, there will be a huge mismatch in the outcome.

A research plan is a forcing function (in the best sense possible) to get everyone’s thoughts and expectations of a research project out on paper, giving you, the researcher, clarity on how to best navigate the project for the necessary outcomes.

Below, I walk you through the full system I use to stop “random acts of research” and start running studies with clean scope, aligned stakeholders, and outcomes people can actually use:

• The research plan framework that protects you from disappointment (how to set expectations, lock scope, and stop “wait, I thought we were getting a journey map” chaos)

• The “does this project suck?” test (how to spot un-answerable requests early, push back without drama, and avoid wasting weeks documenting nonsense)

• The intake document that replaces endless follow-up meetings (the exact prompts that force stakeholders to show their homework and give you what you need up front)

• My complete research plan template, section by section (background, stakeholders, assumptions, goals, success criteria, methods, recruitment, deliverables, timeline, scripts, resources)

• Two real examples you can copy (one generative plan, one evaluative plan, written the way stakeholders actually read)

Exclusively for paid subscribers

Read more

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

“But it gives us numbers.”

“No thanks.”

That’s the first thing I said when faced with the suggestion of conducting a quantitative usability test.

I was more than happy with my conversation-filled qualitative usability tests. Asking people about their immediate reactions, how they perceived the screens, and their general thoughts on what was confusing and missing. It was a routine I quickly felt comfortable in and enjoyed.

But there’s always a but, isn’t there?

It came when I was sitting with my team, and we were chatting about a flow that many of our users were having trouble with. I had triangulated some data from previous research where the topic had come up, customer support tickets, and also from account managers.

I told my team that we had enough to understand most of the pain points, especially the important ones, and make changes. I was at a point in my career and at the organization where I was privileged enough to be able to say no to user research requests.

Luckily (at the time, it felt unfortunate, but for my career, it was a good thing), my manager was sitting in the meeting. He’s one of the most fantastic managers I’ve ever had (Hi, John 👋🏻), and he asked me a smoldering question:

“How will we know if the changes we make improve the usability?”

Of course, John already knew the answer to his question, but he directed it to me. I knew what he was going for, but I was terrified of the answer.

All I wanted to do was make the changes and then ask the users if the changes we made were helpful — I was even willing to sift through the customer support tickets for the next few months to see if complaints decreased. Anything to stay away from the numbers.

But my team was beaming. This was exactly what they wanted: a clear and straightforward way to measure usability and progress. There was no backing out. It was finally time for me to conduct quantitative usability tests.

And I am so glad for that push because they have become an absolutely essential part of my user research toolkit and have also helped me become a well-rounded (and promoted!) user researcher.

What is quantitative usability testing?

Usability tests, on a whole, are about having participants attempt to do the most common and important tasks on a product/service. While you conduct the test, you, as a researcher, are looking to find problems the participant runs into during the test. You then take these problems to your team and, together, brainstorm and find ways to fix the usability issues — which are sometimes simple and other times complex.

With qualitative usability tests, you are talking to the participants and describing the different reactions, perceptions, or issues they encounter.

However, with a quantitative usability test, you can still describe the problem, but you measure:

• How many people encountered a problem

• How many people were able to complete the tasks

• The time it took them to complete tasks

• How many errors participants ran into

• What types of errors participants encountered

• Participants’ perceptions of usability

With quantitative usability testing, you can find out a lot of important information that can help you generate the impact of your research. For instance, when I was working at a travel company, we conducted a quantitative usability test on our checkout flow.

We found that people were taking a long time to fill out information that ultimately wasn’t that relevant and, thus, dropping off and abandoning the flow for a competitor that was easier to use.

Based on these results, we made some significant changes and retested the flow after the improvements were made. We reduced the time it took to fill out information by 50% (which was faster than people could do on the competitive product as well), and we reduced abandonment by 35%. This meant that we increased revenue by £75,000 annually.

Big impact.

When it comes to measuring usability, we can break that down into three major areas:

1. Effectiveness: Whether a user can accurately complete tasks and an overarching goal

2. Efficiency: How much effort and time it takes for the user to complete tasks and an overarching goal accurately

3. Satisfaction: How comfortable and satisfied a user is with completing the tasks and goal

Below, I walk you through:

• How exactly to run a quantitative usability test for your team (with examples from my work)

• The most important metrics for you to know

• How to write a quantitative usability tasks/scenarios that give just enough detail to your participants

• How to analyze the results for tangible benefit to your team

Exclusively for paid subscribers

Read more

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

For me, quantitative usability testing was always super straightforward. I put a high-fidelity design or live product in front of someone and asked them to do certain tasks, which I then measured through metrics like task success, time on task, and surveys like the Single Ease Questionnaire.

There was very little room for asking qualitative-based questions or for introducing bias. We were there to truly understand the effectiveness, efficiency, and satisfaction of what we put in front of the participants. Straightforward. Easy, dare I say. In fact, I could even set up an unmoderated test to get even more participants.

However, I felt uncomfortable when it came to qualitative usability testing. I never seemed to be able to strike the right balance and constantly felt like I was asking leading and biased questions. I hated the standard questions like:

• “What would you expect to see?”

• “What do you think of this?”

• “What would you change?”

• “Explore the interface and tell me what you would do.”

I hated those questions because they were so hypothetical and future-based. I felt like I was asking the participant to develop ideas and design the website or app. The data I got from those questions was skewed and unhelpful.

Very rarely, if ever, as a user, do I sit on a website and think, “What am I expecting to see?” I can’t remember the last time I went to a website or app to explore the interface. And, although sometimes I do have opinions on websites/apps, my opinions likely wouldn’t be helpful or actionable to teams trying to make changes.

“This is dumb” is not a very actionable quote.

Below, I walk you through the full approach to make qualitative usability testing stop producing fluffy, hypothetical feedback and start giving your team clear direction on what to fix, what’s missing, and what’s confusing:

• The “what qualitative usability testing really is” definition (why it’s not true usability testing, and where it sits between concept testing and quant usability testing)

• The goal checklist that tells you when this method fits (the exact types of decisions and uncertainty it’s built for)

• The TEDW-based question builder (how to replace “what do you think?” with prompts that pull real experiences, perceptions, and friction without leading)

• The session structure you can reuse (warm-up, overarching scenario, screen-by-screen flow, and wrap-up questions that don’t turn into opinions-only noise)

• The synthesis + activation workflow (deductive tags, affinity by screen, clustering patterns, and the built-in handoff into an ideation workshop so the work actually moves)

Exclusively for paid subscribers

Read more

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

I remember a time when stakeholders started to get excited about user research. It was an interesting switch for me — I went from constantly checking in to identify user research projects within teams to colleagues coming to me with research project ideas in hand.

It👏🏻was👏🏻awesome👏🏻

I felt like research was exploding. I felt like I finally had a say. I felt like I finally had power.

But “with great power comes great responsibility” (Source: Uncle Ben + others).

And I quickly realized that, with these research projects, as exciting as they were, I started to feel extremely overwhelmed by them. It wasn’t necessarily the amount of projects (that would come later) but rather the number of questions people had within each research project.

The first time I encountered this was at my job at a social media management company. One of my stakeholders had an idea in mind for a concept they wanted to test. We had heard several times within previous research that the analytics on our platform were not aligning with users’ expectations and needs. In fact, they fell short in several key areas.

Some of the key pain points highlighted from previous research included:

• We did not provide sufficient engagement analytics for our clients, inhibiting them from making data-driven decisions

• Many clients were asking for manual reports from account managers as our platform isn’t providing sufficient metrics/data that allows them to compare data

• Our current metrics had little context and weren’t very useful/reliable for our clients to make decisions

These were some pretty big flaws in our platform, rendering it an underutilized feature and, ultimately, creating more work for customers and our account managers.

So, with that in mind, my stakeholder came to me with a concept based on this previous research. I was thrilled. Not only had they listened to previous research, but they had used it as a jumping-off point for a concept! Hurrah!

And then I looked at the list of questions this stakeholder had that they wanted answered within the research project:

• Do people understand the concept?

• Do people like the concept?

• Do people perceive our recommendations as trustworthy?

• What types of comparison timelines do people prefer when it comes to analytics?

• What kind of engagement metrics are most important to see?

• How do people perceive the difference between engagement and interaction metrics?

• Can people use the concept?

• Would they like to use the concept to try it out?

• Are people annoyed when they have to open a new window to compare data?

• Is it clear how people navigate through the concept to get a monthly report?

😱😱😱😱😱😱😱

Not only were these a whole lotta questions, but they were also a lot of unideal-for-qualitative-user-research kinds of questions. There was no way we could answer so many questions in a 60-minute concept test, let alone get answers to the majority of these questions.

I went back to the stakeholder, terrified that I would disappoint them. I had just started the research ball rolling, and the last thing I wanted to do was say no to a research project or tell them that I couldn’t answer these types of questions.

Since I was still early on in my career, I had a tough time rewriting and narrowing down the scope of the questions. We went into the concept test with way too many yes/no and preference questions to answer.

This was one of the first projects that had landed on my desk from a stakeholder, and the results were a bit disappointing. Because the small sample sizes within qualitative user research aren’t ideal for answering yes/no questions (all the “do” and “are” questions), I didn’t have much impact.

Saying, “8 out of 12 people understood the concept,” was not powerful.

Similarly, saying “7 out of 12 people liked the concept” did not tell us anything. Many of the stares I got during my report said, “So what?” or “What now?”

I was gutted (my new British slang). That wasn’t the first or the last time I received a research project with a slew of questions that were either impossible to answer with user research or were way too broad in scope.

If you’ve ever been handed a 20-question laundry list and told “can you just test this,” the next part is your escape. Paid subscribers get the full system I use to:

• Turn “do/can/which/are” questions into interview questions that actually produce stories

• Separate what research can answer vs what needs A/B testing, analytics, or a survey

• Cut scope fast without disappointing the stakeholder

• Run a clean prioritization meeting that ends with a short, usable question set

• Use the upgraded spreadsheet (columns, definitions, scoring) to make decisions in real time

• Spot repeated questions across teams and turn them into strategic research themes

• Walk through the full example (your analytics concept test) with a finished sheet you can copy

Exclusively for paid subscribers

Read more

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

Concept testing can sometimes feel like a mystery. There were quite a few times in my career when teams put an idea in front of me and asked me to test it with users (well, to validate or ask for preference, which we don’t do, of course 😁). And for some time, I felt incredibly stuck when my teams made these requests.

The ideas weren’t solid enough to conduct a usability test.

They weren’t basic enough for me to conduct generative research.

These concepts were in the in-between (or the upside-down, if you will 😂).

Whenever a team came to me with these concepts, I cringed. I had no idea how to get them the information they needed without leading the participants and asking biased questions. I knew I shouldn’t be asking things like:

• “Do you like this idea?”

• “Would you use something like this?”

• “How would you make this better?”

• “Is this going in the right direction?”

But I wasn’t sure how else to engage with participants.

So, I tried to conduct usability tests on concepts. That ended as a major failure. The ideas were too early to test. Participants got lost and confused because there wasn’t a flow. And, to be honest, I had no idea what I was trying to test. My goals for those research projects were vague, and the findings were unhelpful.

We understood that people had a hard time navigating a loosely defined concept, but we still had no idea whether or not we were heading in the right direction. Each of those reports ended up disappointing not only my teams but also me.

It was by chance that I heard about the concept of concept testing (very meta, I know). At first, I wasn’t sold. How were we meant to evaluate concepts in an unbiased way? And how were we meant to investigate their reactions without relying too heavily on future-based data?

But, after some more disappointing results and failed usability tests on ideas, I finally decided to give concept testing a whirl. Admittedly, I wasn’t very skilled at conducting those tests, but with some practice and guidance, I finally understood the importance of concept testing. And, from there, I never looked back.

What is Concept Testing, Anyway?

Concept testing is one of those elusive methods that, I believe, we don’t discuss nearly enough, as it can be an extremely powerful tool to use early in the discovery process. Because it can be such an “in-between” method, we often skip it, going straight from generative research to usability testing.

However, concept testing definitely has its place in our process. The way I define it is:

Concept testing is a way to engage with participants to more deeply understand a specific problem and their current process through a stimuli (concept). Through concept testing, we gather feedback that allows us to gauge how aligned we are (or not) with participants’ mental models regarding an idea.

Within the scope of this definition, we are looking for immediate reactions and perceptions from our participants. We are looking to see how participants respond to the idea and where there are gaps or confusion about what we’ve put in front of them.

This is the crux of the definition and often where I can see concept testing go wrong (and where I’ve done it incorrectly before).

Where Concept Testing Goes Wrong

As I mentioned, it took me a good amount of practice to hone my concept testing skills. Because it is a less-discussed methodology, I struggled with finding the proper resources on how to conduct a concept test and what exactly I was looking for as an outcome.

Unfortunately, I see concept testing used a lot for things like:

• Product/idea validation

• Preference testing

• A/B testing

• Asking about future-based behavior

When I first started concept testing, I made these mistakes. I wanted the concept test to tell me whether or not participants liked the concept, if they would use it or not, and if I tested multiple concepts, which one they preferred.

The problem with all of the above is that concept testing is still a qualitative method. And with qualitative methods, we can’t answer these types of questions. Qualitative user research isn’t set up for success to answer “whether or not” or “if” or “preference” questions.

Qualitative research involves uncovering reactions, perceptions, feelings, and mental models. Concept testing should be no different.

When I first started conducting concept tests, I asked many of those questions, and the results were more disappointing than the usability tests I had attempted to run on the concepts.

What did it mean if people liked or disliked a concept? What did preference mean when it came to the concepts? How would we know people would actually use the product in the future? Not only that, but usually, during these tests, there can be social desirability bias present, where participants will tell you what you want to hear.

So, when I delivered my results, my teams weren’t always sure what actions to take. We knew that people liked the concept and which they preferred, but there was so little depth to the answers and so little action within the data that the teams ended up feeling just as stuck as before.

From there, I changed how I thought and approached concept tests, ensuring that I got my teams the data they needed without asking participants questions that could skew our decision-making.

If concept testing has ever made you freeze, this next part is the fix.

Paid subscribers get the full concept testing playbook:

• A quick “Should we even run a concept test?” decision checklist

• A goal-setting script to pull the real decision your team is trying to make

• A concept setup guide (what to show, how low-fi to go, what to avoid)

• A question bank built for concept testing (TEDW prompts + follow-up ladders)

• Run-of-show templates for 60 and 90 minutes (1 concept, 2 concepts, 3 concepts)

• Sample screener prompts to recruit people with the real problem, not hypothetical interest

• A synthesis workflow tailored to concept tests (deductive tags + clustering pattern map)

• An ideation workshop plan that turns findings into prototype-ready directions

Exclusively for paid subscribers

Read more

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

You know that sound a meeting makes when the energy drains out of it? The soft click-click of someone scrolling Slack, the PM’s throat clear, the faint shuffle of papers that don’t need to be shuffled.

You just said something important, something that took weeks of work, coordination, and probably a few late nights with messy transcripts, and nobody’s reacting.

You can feel the temperature drop.

That’s the moment every researcher dreads.

You’ve just presented evidence that contradicts what the team wanted to believe. Maybe users didn’t understand the new feature. Maybe adoption is lower than the optimistic model promised. Maybe your usability test showed people getting lost halfway through a flow that was “definitely ready.”

Whatever the reason, your research just stepped on someone’s dream, and you’re the messenger standing in front of the firing squad.

The illusion of “positive” research

Most companies say they love research.

Until it tells them something they don’t like.

Everyone loves a good insight when it validates their roadmap. That’s not research; that’s confirmation theater.

What most teams secretly mean when they say “show us insights” is “show us good news.”

So when you bring something uncomfortable, the energy shifts. You can see the signs:

• The head tilt.

• The “That’s interesting” in a tone that means “We’re not doing that.”

• The immediate pivot to “Well maybe users will behave differently when it’s live.”

That’s the moment where a lot of researchers lose the room—not because they’re wrong, but because they’re unprepared for the emotional weight of truth.

It’s not the data they’re reacting to. It’s the threat.

When your findings contradict someone’s plan, you’re not just challenging the design. You’re threatening someone’s credibility, political capital, and sometimes their bonus.

If you’ve ever watched a PM’s smile tighten after a slide that says “5 of 6 users couldn’t complete checkout,” you’ve seen this firsthand.

They’re not mad at you. They’re scared.

Your data just put their name next to a potential failure.

And when people feel cornered, they fight—just in polite, meeting-friendly ways.

You’ll hear phrases like:

• “That’s just early data.”

• “We only tested with ten people.”

• “We’ll validate that with analytics later.”

It’s self-preservation disguised as feedback.

Understanding that changes how you approach these moments. You’re not fighting against ignorance. You’re navigating power, ego, and loss of control.

Your job isn’t to be liked. It’s to be useful.

When I first started, I thought being right was enough. I’d show up to meetings with a rock-solid report, all the evidence clearly laid out, convinced that logic would win.

It didn’t.

I learned the hard way that truth doesn’t sell itself.

If people feel attacked, they won’t hear a word you say.

What works is reframing your job.

You’re not delivering bad news. You’re mitigating risk.

You’re not saying, “This failed.”

You’re saying, “Here’s what’s blocking the outcome you want.”

It seems like a small shift, but it changes everything.

Instead of “Users hated the dashboard redesign,” say:

“Most users struggled to find the metrics that matter to them. That’s creating friction before value, which is likely reducing adoption.”

Same insight. Different emotional payload.

One sounds like criticism. The other sounds like help.

What’s really happening in the room

When the room turns cold, you’re standing in the middle of three emotional currents:

1. Self-preservation: Someone’s work, vision, or promotion feels at risk.

2. Loss of control: People hate uncertainty, and negative data threatens their illusion of control.

3. Fear of consequence: “If we admit this is broken, we’ll have to change direction. That costs time, money, credibility.”

Once you realize that’s what’s driving their reaction, you can stop taking it personally.

They’re not ignoring you. They’re protecting themselves.

Your goal isn’t to out-argue them. It’s to lower the threat level.

The reframe that keeps you grounded

When you’re facing that silent room, remember this:

Negative results aren’t failures. They’re truths that save money before launch.

They’re the reason you don’t have to explain to the CEO why sign-ups dropped 40% after launch. They’re the reason engineering doesn’t waste a sprint fixing something that never should’ve shipped.

You’re not the problem. You’re the one keeping problems small.

If you can carry that energy into your presentation, you’ll hold your authority without losing your humanity.

Try this mental reset before every “difficult” readout

Before your next meeting, write this sentence at the top of your notes:

“My job isn’t to make people comfortable. My job is to make the product smarter.”

Then ask yourself three questions:

1. What outcome are they chasing?

2. What’s blocking that outcome according to the data?

3. How can I frame this so it feels like progress toward that outcome, not a detour?

Why they don’t want to hear it

Negative results don’t make people angry because of the data. They make people angry because of what the data means. When your findings point to something broken, the people in the room don’t see insights. They see risk; risk to their plans, their competence, their credibility. And unless you understand the flavor of that fear, you’ll waste your energy arguing facts to feelings.

The trick is to stop assuming everyone resists for the same reason. They don’t.

Every stakeholder has their own brand of self-protection, their own internal monologue that starts the second you say, “Users couldn’t find the button.”

The four resistance types

These are the four personalities you meet every time you deliver uncomfortable research. Once you can spot them, you can stop reacting emotionally and start steering the conversation.

1. The Builder: “They just used it wrong.”

You’ll know you’ve met a Builder when they respond to feedback like it’s a personal attack.

You say, “Users struggled to complete checkout.”

They hear, “You’re bad at your job.”

Builders are deeply invested in their craft, often designers or PMs who’ve spent weeks nurturing an idea. Their self-worth is tied to the thing you’re dissecting. When you poke holes in it, it’s like you’re poking holes in them. What to do instead of arguing:

• Validate the effort. “You’ve clearly put a lot of thought into this flow, people picked up on the intent right away. The challenge came in step three where they weren’t sure what to do next.”

• Shift the focus to alignment. “Let’s look at what’s getting in the way of people seeing that great design work.”

• Offer a next step that keeps them in control. “How would you want to tweak this before we test again?”

Once they feel seen, they’ll relax. You’re not trying to prove them wrong, but helping their idea succeed.

2. The Politician: “We can’t show this to leadership.”

These are your optics-driven stakeholders, often department heads or executives who think two steps ahead to what this deck will mean upstairs. Their resistance isn’t about the insight itself. It’s about perception. They’re terrified of looking unprepared, out of control, or like they backed a bad initiative.

You can spot a Politician by the way they redirect. “We don’t need to share that level of detail.” Or, “Let’s frame this as learning, not failure.”

They’re managing spin. Your job is to give them something they can say. How to handle them:

• Reframe the finding as foresight. “This gives us an early heads-up before leadership sees it post-launch.”

• Use language they can repeat. “We identified an opportunity to improve conversion before rollout.” (They’ll quote that sentence word for word.)

• Give them talking points. Literally write out a one-line version of each key takeaway they can use in exec meetings. It makes you an ally instead of a liability.

When you make the Politician look prepared, they’ll protect your credibility in return.

3. The Optimist: “Users just don’t get it yet.”

This one’s easy to spot. The Optimist loves the vision too much to believe it might be flawed. They’ll wave away usability issues with “Once we polish it” or “Once people get used to it.” In their mind, users just need to catch up.

Optimists usually sit in product or leadership roles where their job is to dream big. You don’t want to kill that, you want to tether it to reality without crushing their excitement. How to handle them:

• Anchor to their goal. “You want adoption. This friction is what’s standing in the way of that adoption.”

• Quantify the cost of waiting. “For every week we hold this issue, we lose X potential conversions.”

• Turn it into an experiment. “Let’s prove your hunch. If users ‘get it’ after the polish, we’ll see it immediately in the next round.”

Optimists calm down when you make it safe to test their belief instead of kill it.

4. The Scapegoater: “Those weren’t real users.”

Ah yes, the all-time favorite.

Whenever a result feels uncomfortable, the Scapegoater questions the validity of the research itself. They’ll nitpick methodology, participant count, or recruiting criteria. “Were those our real customers?” “Ten people isn’t statistically significant.” “That’s just one data point.”

They’re not questioning your methods. They’re trying to protect their narrative. How to handle them:

• Ground in replication. “That’s a fair question. We can test again with a different segment to see if it holds.”

• Call out the pattern, not the number. “We saw six people fail in the same spot independently. That’s the signal we’re surfacing.”

• Offer escalation, not defense. “Happy to rerun it if we’re unsure — that’s cheaper than launching and learning it at scale.”

You don’t have to win the argument. You just need to redirect the conversation toward learning. That’s your home turf.

How to use these archetypes

Before your next big readout, sit down and fill out a quick Resistance Map. Grab a piece of paper, draw four columns:

You’ll walk into the meeting already knowing who’s likely to bristle, what they’re afraid of, and what tone will calm them down. You’re preparing for the reality that research is political. The Resistance Map gives you control before the conversation starts.

The mistake most researchers make

They try to bulldoze resistance with proof.

• “I have the data.”

• “I have the recordings.”

• “I have the quotes.”

But data doesn’t change minds. Emotion does. You can’t logic someone out of a defensive reaction. You have to give them a safer narrative to attach to. When you understand what’s really driving their discomfort, you can meet it head-on with empathy and authority at the same time. That’s when your research stops being a debate and starts being a shared decision.

Quick exercise before your next presentation

Pick one upcoming readout. Then, answer these questions in one line each:

1. Who in the room has the most to lose if this finding is true?

2. What version of this insight would they feel comfortable repeating to their boss?

3. How can you say it that way without watering it down?

If you can write those sentences before you walk in, you’ll present truth that lands instead of truth that explodes.

The real pre-work

By the time you walk into a readout, the story has already been written. Not by you, but by everyone’s expectations.

Read more

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

Hello curious human,

The number of times I’ve had someone come to me and say “let’s just run a survey on this” is almost as many times as I’ve run a survey without enough thought or intention.

Surveys are powerful little tools but, unfortunately, they can be seen as a extremely simple method to get answers quickly to something. And the reason I say unfortunately is because, a lot of the time, we are expecting way too much from surveys (kinda like personas).

Because they appear so simple on the surface, they can get very misused and yield very misguided results. I remember running surveys without clearly understanding what I was doing and interpreted them very incorrectly, leading to some poor decisions being mad.

And it’s not the fault of surveys but how we use them. So, in this article, I will talk through the subjectivity of surveys and how we can use them more appropriately (and also why I’ve started to send fewer surveys in my research projects).

PS. If you want to have a laugh…

The trap of simplicity

Surveys look easy. That’s the problem.

When a stakeholder says, “Let’s just throw it in a survey,” what they really mean is, “I don’t want to slow down and think too hard about this.” And sometimes, if we’re honest, we mean the same thing.

Surveys feel like free money. You spin up a form, blast it to a panel, and within 48 hours you’ve got hundreds of responses neatly laid out in rows and columns. It feels efficient. It feels like research. It feels like progress.

But surveys are the UX equivalent of instant noodles: quick, cheap, and not nearly as nourishing as you pretend they are.

I’ve been guilty of this. I once ran a survey with 20 questions on feature adoption. I asked things like “How often do you use X?” and “How satisfied are you with Y?” I thought I was being thorough. When the responses came in, I did what many of us do: I sorted by the biggest numbers and slapped them into a slide deck.

It looked impressive. Until someone asked me, “So what does this mean for what we build next?”

I froze. I didn’t know. The data was shallow, the questions were vague, and the only real conclusion I could draw was that people clicked boxes when asked.

That’s the trap of simplicity: because surveys are easy to spin up, we stop being critical about whether they’re the right method. We start to believe that any survey = insight. That’s not how this works.

Stop surveys from becoming your lazy default:

1. Start with the question behind the question. Don’t ask, “What should go in the survey?” Ask, “What do we actually need to know, and can a survey realistically tell us that?” If what you need is why, a survey is already the wrong tool.

2. Set a higher bar. Pretend you have to defend the survey in front of your toughest stakeholder. If all you can say is, “Well, it’s fast,” you’re not ready. You should be able to say, “We’re asking these three questions because they will help us decide between option A and option B.”

3. Make surveys the last resort, not the first instinct. Treat surveys like antibiotics: useful when needed, harmful if overprescribed. Ask yourself: could a quick interview, usability test, or even an analytics check answer this faster and better?

A quick self-check template:

Before you send out a single survey link, run it through this filter:

• What is the decision we’re trying to make?

• Can a survey actually give us the evidence to make it?

• What’s the risk if we’re wrong?

• Have we considered another method that might be stronger?

If you can’t answer these, don’t send the survey.

Expecting Surveys to Do the Wrong Job

Surveys often get hired to do jobs they’re simply not qualified for.

I’ve seen teams use them to try to explain churn, validate a new feature idea, or predict future behavior. On the surface, it makes sense: you have a question, you send it out to hundreds of people, and you get a spreadsheet of answers. Fast, neat, and clean.

Except it rarely gives you what you’re actually looking for.

At one company, we were struggling with churn. Customers were leaving at a higher rate than expected, and leadership wanted answers. The first reaction was, “Let’s run a survey asking people why they left.”

So, we did.

Thousands of churned users received the survey, and the top two responses came back as:

• “Too expensive”

• “Didn’t need it anymore”

Leadership latched onto those answers immediately. The conversation turned to pricing experiments. Maybe we should lower costs, try tiering, or roll out discounts.

But then we did follow-up interviews with some of those same customers. And the story changed. Pricing wasn’t really the problem. The real issue was that people didn’t see enough value in the product to justify the price at any level. “Too expensive” was an easy checkbox to click when you didn’t want to type out, “Your product never became essential in my workflow.”

If we had stopped at the survey, the company would have made sweeping pricing changes that wouldn’t have fixed the underlying problem and would probably have hurt revenue even more.

That’s the trap of overpromising: expecting surveys to reveal motivations, predict behavior, or validate desirability. These are jobs surveys cannot do well. They’ll give you surface-level answers, but not the depth you need to make confident decisions.

The mismatch between questions and methods

Some of the most common misuses I see:

• Validating desirability. Asking “Would you use this feature?” is nearly guaranteed to give you a false positive. People like the idea of a feature in theory. Their actual behavior is another story.

• Predicting behavior. “How often will you use this in the future?” No one can predict this accurately. People overestimate their future selves and underestimate friction.

• Explaining motivation. A five-point satisfaction scale tells you nothing about why someone is dissatisfied. It only confirms they are.

A simple way to check if a survey is the right tool

When you’re tempted to launch a survey, pause and ask:

• Do I need counts? (How many, how often, what proportion?)

• Do I need context? (Why, how, under what conditions?)

• Do I need behavior? (What actually happened?)

Here’s the shorthand I use with teams:

• Surveys → Counts

• Interviews → Context

• Analytics → Behavior

It’s not that surveys are “bad.” They just have a very narrow set of jobs they’re good at. The problem comes when we stretch them outside that boundary.

Try this with your own surveys

Think about the last survey your team ran. Open it up, look at the first three questions, and classify them into one of the three buckets above: counts, context, or behavior.

• If the question belongs in counts → good, keep it.

• If it belongs in context → wrong tool. That’s an interview.

• If it belongs in behavior → wrong tool. That’s analytics or logs.

This one exercise helps you spot overpromising quickly. It also gives you a way to push back when someone says, “Let’s just send out a survey.” You’re not saying no to the survey but instead showing the mismatch between the question and the method.

Subjectivity in Design

One of the biggest lies about surveys is that they’re “objective.” Put the same questions in front of hundreds of people, tally up the results, and voilà, you’ve got hard numbers you can trust.

Except every single piece of a survey is subjective.

• The way the question is phrased

• The scale you choose

• The assumptions baked into the wording

• The order you ask things

All of that nudges people toward certain answers. And those nudges add up fast.

Loaded wording

I once reviewed a survey that asked:

“How helpful was Feature X for you?”

Notice the trap? The question assumes Feature X was helpful in the first place. Someone who didn’t find it helpful still has to pick from a scale that presumes it did something good. They’ll either click the lowest option or skip it, but the framing has already tilted the results.

A stronger, less biased version would be:

“What was your experience with Feature X?”

That leaves the door open for positive, negative, or neutral answers.

Scale design traps

Scales look objective, but they carry a lot of hidden bias.

• A five-point scale pushes people to the middle.

• A seven-point scale spreads responses but can be overwhelming.

• A scale that labels only the end points (“Not at all useful” → “Extremely useful”) leaves the middle up to interpretation.

I’ve seen teams argue for hours about whether to use five, seven, or ten points. The truth is: none of them are neutral. You’re shaping the outcome no matter which one you pick. The key is to choose a scale, stick with it over time, and be clear about how you’ll interpret it.

Leading the witness

It’s surprisingly easy to write a survey that accidentally tells people what you want to hear.

Take this question:

“How much do you agree that Feature Y saves you time?”

That’s a leading question. You’ve already told participants that the feature saves time. Even the “disagree” option is reacting to your statement.

A better version:

“If you use Feature Y, how does it impact the time it takes to complete your task?”

Now people can say it saves time, wastes time, or makes no difference. The data is richer, and you haven’t pushed them in a direction.

How to keep yourself honest

Before you send a survey, do a quick pilot run. Ask three to five people (inside or outside your company) to read the questions and then tell you, in their own words, what they think you’re asking.

If what they say back doesn’t match what you intended, your survey is carrying bias. Rewrite until the intention and the interpretation line up.

I use a quick checklist before finalizing any survey:

• Does this question assume a positive or negative experience?

• Is this scale forcing people toward a certain answer?

• Could two different people interpret this question in completely different ways?

• Is there any jargon or insider language that someone outside the company wouldn’t get?

Surveys may look like hard numbers, but every decision we make in design turns the dial a little bit. Pretending surveys are neutral only makes the problem worse. A better approach is to admit that subjectivity exists and manage it intentionally.

Subjectivity in Sampling

Even if you write flawless survey questions, the answers still come from people. And who those people are matters more than anything else.

Surveys often get treated like magic spells: send them out, get hundreds of responses, trust the numbers. But those numbers only reflect the people who happened to answer. And if those people don’t represent the group you’re actually trying to understand, the data doesn’t mean much.

The “easy list” problem

At one company, we ran a survey about feature adoption. We wanted to know how new customers were experiencing onboarding. Sounds simple enough.

Except the survey didn’t go to new customers. It went to the email list we already had set up, the same list that included mostly long-term, power users.

Guess what happened? The responses were glowing. People loved the onboarding. They said it was clear and simple.

But those responses weren’t from the people struggling with onboarding. They were from the people who had already survived it. By surveying the “easy list,” we ended up patting ourselves on the back instead of fixing real problems.

Convenience samples sneak in everywhere

It’s not just email lists. Panels, social media links, and even intercept surveys on your product tend to pull in whoever is easiest to reach. And “easy to reach” often means a very specific type of user: the vocal ones, the loyal ones, the ones with time on their hands.

If you’re not careful, those groups become your de facto research audience. You start designing for the squeaky wheels instead of the quiet majority.

A quick gut check for representativeness

When I look at a survey, I ask myself three questions before I trust the numbers:

1. Who did we want to hear from? Be clear on the audience before you send anything. “All customers” is rarely specific enough. Do you need churned users, new users, enterprise accounts, first-time buyers? Define it.

2. Who actually responded? Look at the demographics, tenure, roles, or usage patterns of your sample. Does it match what you need? Or are you just hearing from the same 20% who always respond?

3. What’s the gap, and how risky is it? If your target was new customers but 80% of respondents were long-time power users, that’s a big gap. If you were aiming for a mix of roles but only designers responded, that’s another red flag.

Turning subjectivity into clarity

You can’t always get the perfect sample. That’s the reality of survey research. But you can at least be explicit about who you actually heard from.

Instead of saying, “Customers told us…” in a readout, frame it as:

“We heard from 250 long-term users who have been with the product for 12+ months. Their perspective is valuable, but we’re still missing newer users.”

That simple shift in framing makes the subjectivity visible. It also makes it harder for stakeholders to run off and overgeneralize the results.

Surveys will always be shaped by who shows up. You have to be honest about the lens you’re looking through, and making sure your team understands the limitations.

Subjectivity in Interpretation

You’ve crafted careful questions. You’ve checked your sample. You’ve got a tidy spreadsheet of results.

Now comes the most subjective part of all: interpreting the data.

Numbers don’t actually speak for themselves. We speak for them. And that’s where things can go sideways fast.

The story we want to hear

At one company, we ran a customer satisfaction survey after a redesign. The scores were decent with most people hovering around neutral with a few leaning positive.

When the PM presented the results, she said:

“Look, 60% of people rated the new design positively.”

Technically true. But she left out the fact that nearly 40% were neutral or negative. By spotlighting only the positive slice, the survey became a pat on the back instead of a warning sign.

This isn’t always intentional. We all fall into confirmation bias: noticing the numbers that support our hopes and quietly ignoring the rest. But in stakeholder-heavy environments, that bias can shape entire roadmaps.

The “average” trap

Another common pitfall: reporting averages.

Let’s say your survey asked people to rate ease of use on a 1–7 scale. The average score comes back as 4.8.

On paper, that looks fine. Not stellar, not terrible. Middle of the road.

But if you dig into the distribution, you might find two very different groups:

• Half of users rated it a 7 (very easy).

• The other half rated it a 2 (very hard).

Averaging those together hides the fact that you’ve got a split audience: one group sailing through, the other drowning. If you report just the average, you’ll completely miss that divide.

Numbers without context are dangerous

The temptation is to grab the highest percentage and headline it. “80% of users agree Feature Z is useful.”

But that number only means something if you put it next to context:

• Who said it?

• How many skipped the question?

• What does “useful” actually mean in their workflow?

Without that framing, you’re just throwing big numbers around. And big numbers are seductive to stakeholders who want quick validation.

How to keep interpretation honest

Before you share survey results, run through these steps:

1. Show the full distribution. Don’t just report averages. Show the range of responses so splits and outliers are visible.

2. Pair numbers with open comments. If you asked an open-ended follow-up, bring those voices in. They keep the numbers grounded in reality.

3. Acknowledge uncertainty. Frame your insights as “This suggests…” instead of “This proves…” Surveys are directional, not definitive.

4. Triangulate with other data. Always check: does this align with what we’re hearing in interviews or seeing in analytics? If not, call out the tension instead of smoothing it over.

Surveys give you patterns. It’s our job to interpret those patterns responsibly and admit where the limits are. Otherwise, we risk turning numbers into a comforting story instead of a useful one.

When Surveys Are the Wrong Tool

Read more

Paid subscribers get the power tools: the UXR Tools Bundle wi…

Read more

• My full setup process for running an unmoderated usability test in Userbrain, from goal-setting to test creation

• How to write clear, action-based and opinion-based tasks that get useful behavioral data

• Using AI to generate and refine test tasks, plus how to correct vague or over-open questions

• Techniques for analyzing unmoderated test data using AI insights, clips, and reports

• How to connect usability findings back to research and business goals to identify real impact

Key Takeaways:

1. If your research goals aren’t clear or your tasks are vague, the data you get back will be inconsistent and shallow. A well-structured setup defines what you want to learn, aligns it to business decisions, and sets measurable outcomes before the first participant even starts. Most “bad” unmoderated results trace back to poor planning, not poor participants.

2. Participants need to know exactly when a task begins and ends. Without defined boundaries, they may wander off-path or complete actions you can’t analyze meaningfully. By giving each task a specific finish line, like “stop when you reach the flight results page,” you get consistent, comparable footage that supports clean synthesis later.

3. AI can be useful for avoiding blank-page paralysis, but its phrasing is often too broad or contextually off. Treat it as a brainstorming tool—generate rough drafts, then rewrite them to fit your product, audience, and goals. The value comes from editing, not accepting what it gives you.

4. Positive feedback feels good but doesn’t move design forward. When analyzing results, zero in on moments of confusion, frustration, or unexpected behavior as those are where you find opportunities to fix or improve the experience. Stakeholders care more about barriers than affirmations.

5. Unmoderated tests produce endless data, but without a clear line to decisions or KPIs, they risk being shelved. Revisit your research goals during analysis, group findings under those goals, and connect each issue or success metric to its potential business impact. That’s what turns usability findings into strategic recommendations.

The unmoderated test guide:

Grab the full unmoderated testing guide with all the steps and examples here and try it out with your next project (or with a project you recently did!).

Try Userbrain:

Want to try this out on Userbrain? You can grab a free trial below:

Try Userbrain today!

Interested in sponsoring the podcast?

Interested in sponsoring or advertising on this podcast? I’m always looking to partner with brands and businesses that align with my audience. Reach out to me at nikki@userresearchacademy.com to learn more about sponsorship opportunities!

Stakeholder buy-in is a tale…well, a nightmare, as old as time. You run the research. You catch the cracks. You pull together quotes, clips, friction points, and five glaring moments of user confusion.

And then?

The meeting ends. Everyone goes back to business as usual. The roadmap stays exactly the same. And your work goes straight into the void…

Read more

If you want to see everything I post, subscribe below!

Subscribe now

This is a series on user research democratization — since this is a tough topic, there was way too much for one article. I will be writing this series and posting it over the next weeks and will edit this as I add to the series so you can easily navigate the different parts.

• Part 1: The Complex Landscape of Research Democratization (Free)

• Part 2: A Framework for Responsible Research Democratization (Paid)

• Part 3: Scaling research without sacrificing rigor (Paid)

Stop piecing it together. Start leading the work.

The Everything UXR Bundle is for researchers who are tired of duct-taping free templates and second-guessing what good looks like.

You get my complete set of toolkits, templates, and strategy guides. used by teams across Google, Spotify, , to run credible research, influence decisions, and actually grow in your role.

It’s built to save you time, raise your game, and make you the person people turn to.

→ Save 140+ hours a year with ready-to-use templates and frameworks

→ Boost productivity by 40% with tools that cut admin and sharpen your focus

→ Increase research adoption by 50% through clearer, faster, more strategic delivery

Grab the Everything UXR Bundle

You’ve made the leap and you’ve started democratizing user research. Stakeholders are getting involved, training programs are up and running, and suddenly you have more breathing room to focus on strategic work. Great, right?

Well, yes…and no.

If you’re anything like me, your journey probably started out promising. You saw stakeholders get excited about conducting research. They started running their own usability tests, sending out surveys, and occasionally producing some pretty solid insights. But somewhere along the way, you probably also encountered a situation where you had to bite your tongue and think:

“Wait, how did this insight even happen? That’s not what participants said at all.”

Sound familiar?

Maybe you noticed research being conducted without oversight or stakeholders accidentally twisting findings to fit their own narrative. Perhaps you’ve found yourself becoming more of a service desk, fielding endless requests to review interview guides, recruitment strategies, or analysis documents. (And, annoyingly, that’s exactly what you were trying to avoid in the first place.)

Democratizing user research is messy.

But that’s okay. You’re not alone, and this isn’t a sign of failure, just part of the process. After all, user research democratization is relatively new territory for most organizations. There isn’t a single team out there who hasn’t run into issues along the way.

By now, you already know the value democratization can provide, but you’re probably also realizing it comes with a host of challenges. My goal is to help you respond effectively to these inevitable bumps and frustrations.

In this article, I’ll share concrete strategies, realistic examples, and actionable frameworks for responding to the most common issues you’ll face while democratizing user research. I’ll walk you through how to proactively identify potential pitfalls, tackle them when they arise, and adjust your processes so they don’t become recurring headaches.

Together, we’ll cover how to:

• Spot early warning signs of democratization going sideways (before it’s too late).

• Establish clear, realistic guidelines that stakeholders can actually follow.

• Handle common pitfalls like misinterpreted insights, stakeholder overconfidence, and lack of oversight.

• Build a straightforward system to respond to ethical concerns and compliance risks swiftly.

• Navigate pushback from stakeholders or leadership who might question the value and role of user research altogether.

Democratization isn’t about handing over your expertise, it’s about helping your organization scale research responsibly.

Identifying Common Issues in UXR Democratization

When I first began democratizing user research, I felt like I’d found the solution to all my problems. Stakeholders running their own usability tests? Great! Product teams collecting their own data? Even better! I finally had more bandwidth to tackle strategic initiatives.

But it wasn’t long before the cracks started showing. Teams got excited, but enthusiasm quickly turned into confusion, misinterpretation, and occasionally, chaos.

Democratization brings enormous potential, but it also introduces specific pitfalls, some that are obvious, and others you’ll only discover the hard way. Let’s break down the most frequent challenges into four clear categories. I’ll share exactly what these problems look like (so you can spot them early), along with real examples from my experience.

Quality Issues

Let’s start here, because quality is often the first place democratization breaks down. Remember, not everyone conducting research is trained or experienced. When research quality slips, insights become unreliable, and stakeholders may lose faith in the value of research altogether.

Poorly constructed research (bias, flawed methodologies)

Stakeholders designing surveys or interviews full of leading questions. For example, a product manager once created a survey where literally every question began with: “How excited would you be…?” Naturally, all answers were positive, but completely useless for decision-making.

Early warning signs to look out for:

• Stakeholders sending research scripts or surveys to participants without your review.

• Constant use of leading, closed-ended, or ambiguous questions.

• Overconfidence in their approach despite lack of formal research training.

Misinterpretation or overgeneralization of findings

A single positive comment from one usability participant suddenly becomes proof that “users love this feature.” Once, I saw an entire roadmap change direction based on a single, misinterpreted piece of feedback from a friend of the product manager.

Early warning signs to look out for:

• Reports or presentations where quotes are cherry-picked and findings feel suspiciously aligned to stakeholders’ initial beliefs.

• Sweeping conclusions based on small sample sizes like “Users universally prefer…”

Operational Issues

Even if the research itself is decent, operational issues can still cause headaches. When different teams run their own studies without clear documentation or coordination, chaos ensues, resources get wasted, and valuable insights disappear into black holes.

Inconsistent or incomplete documentation

Stakeholders conducting studies but never logging their insights anywhere. I’ve had moments of deja vu when two teams ran essentially identical research simply because no one documented the first team’s findings.

Early warning signs to look out for:

• Multiple teams are unaware of research others have already completed.

• Missing context when stakeholders share findings (“Where’s the original data for this claim?”).

Fragmented repositories or duplicated efforts

Research scattered across Slack threads, personal Notion pages, random Google Drive folders, or worse, buried in personal email inboxes. At one company, we discovered four separate research repositories existing simultaneously (all containing different research!).

Early warning signs to look out for:

• Stakeholders constantly asking, “Where can I find research on X?”

• Duplicate requests for similar research studies from different teams.

Ethical and Compliance Issues

These are the scariest because they can have serious legal and ethical consequences. Non-researchers often lack the training to understand the nuances of consent, data protection, or privacy regulations.

Mishandling of sensitive data or consent processes

Stakeholders recording video sessions without participants’ explicit consent, or worse, sharing sensitive participant data openly across Slack or email. I’ve personally had to step in and remind teams that recording without clear consent isn’t just unethical, it’s illegal.

Early warning signs to look out for:

• Stakeholders unsure how to phrase consent forms or handle participant questions about data usage.

• Unexpected use of unapproved recording or recruitment tools.

Privacy concerns and non-compliance with regulations

Teams unintentionally violating GDPR or other privacy regulations by storing identifiable data improperly or failing to anonymize sensitive information. I’ve found participants’ personal details casually pasted into public team channels. Yikes!

Early warning signs to look out for:

• Stakeholders asking basic questions about participant data storage or privacy (“Wait, how long should we keep this data?”).

• No centralized guidance or documentation around compliance and privacy.

Cultural and Organizational Issues

Finally, democratization issues aren’t always technical—they’re often about people and culture. Resistance and misunderstanding about the role and value of research can derail even the best-laid plans.

Resistance from stakeholders or teams

Teams who either dismiss democratized research entirely or, worse, actively undermine it. I’ve encountered stakeholders who insisted, “We’ve always made decisions without research, why bother now?”

Early warning signs to look out for:

• Teams consistently questioning the validity of democratized research findings.

• Minimal engagement with or outright avoidance of your training efforts.

Devaluing professional research roles

Stakeholders assuming anyone can do research (thus dismissing your expertise). Once, an executive confidently proclaimed, “Why do we need researchers at all if product managers can do interviews?”

Early warning signs to look out for:

• Reduced hiring budgets or stalled plans for growing the research team, justified by “democratization is handling it.”

• Researchers are asked less strategic questions and expected more often to simply “check work.”

Reading through these issues, you might be nodding vigorously because you’re already experiencing one (or all) of them. I promise you’re not alone. Democratization, like most things in user research, isn’t an all-or-nothing game. It’s a careful balancing act.

Now that we’ve identified the most common pitfalls, the next step is learning how to proactively monitor and respond to them quickly and effectively, minimizing disruption and maximizing value. We’ll dive deeply into this in the next sections, covering concrete strategies and frameworks you can implement immediately.

But first, take a moment. Reflect on your organization. Which of these issues resonate with you the most? Which can you already see emerging? Awareness is the first step towards effective action.

Establishing a Proactive Monitoring System

Democratizing research isn’t “set it and forget it.” I learned this lesson early on, mostly by ignoring it until small problems became big headaches. If you don’t regularly check on your democratized research model, quality can slip, small errors will grow, and teams might stop trusting research altogether.

Think about it like a garden. You wouldn’t plant seeds, walk away, and expect flowers to bloom perfectly months later, right? A good garden needs consistent attention, watering, pruning, checking for weeds. Similarly, democratized research needs constant care and monitoring.

Let’s dig deeper into practical, actionable ways you can set up an effective monitoring system that catches issues early before they spiral out of control.

Implement Regular Quality Audits

Regular quality audits are your first line of defense. They sound boring, I know, but trust me: you’ll be amazed (and maybe alarmed) at what you uncover.

Quarterly reviews of randomly selected democratized projects

You can’t audit everything, but periodic spot-checks help you see reality clearly—without rose-colored glasses. Doing this regularly means you’ll quickly spot patterns or repeated issues and can jump on them before they spread.

How I do this:

Once a quarter, randomly choose a handful of studies conducted by non-researchers. I pick studies of different types, surveys, usability tests, quick interviews, to get a full picture of what’s happening.

Questions I ask when auditing:

• Were research goals and hypotheses clearly defined?

• Was the participant recruitment unbiased and appropriate?

• Did stakeholders ask leading or biased questions? (Spoiler: they often do.)

• Were conclusions properly drawn from data, or were insights exaggerated and cherry-picked?

During one audit, I discovered a marketing team was using highly biased questions in their surveys, questions like, “How much better is this feature?” instead of neutral language. Catching this early allowed us to quickly retrain the team before it became a bigger issue.

Define clear quality metrics and review standards

You can’t measure quality without standards. Clearly defined metrics help stakeholders know exactly what’s expected and give you a fair way to judge quality.

Metrics I typically use:

• Participant quality: Are participants representative of our actual users, or just conveniently available friends and colleagues?

• Question quality: Are questions unbiased and open-ended, or are they designed to confirm pre-existing beliefs?

• Insight quality: Are insights supported by clear evidence, or are they vague conclusions without data to back them?

For example, I created a simple, transparent scorecard stakeholders could use to self-assess before submitting their findings. It forced stakeholders to be thoughtful about their approach, and audits became faster since basic quality improved dramatically.

Set Up Stakeholder Feedback Loops

Research democratization relies heavily on stakeholders’ willingness and ability to do good work. But stakeholders won’t always volunteer when they’re struggling—sometimes due to pride, confusion, or even embarrassment. So, it’s critical to proactively reach out and give them a safe, easy way to provide feedback.

Regular surveys and interviews to understand stakeholder challenges

Regular check-ins help surface problems stakeholders might never mention unprompted. You need clear visibility into their frustrations, struggles, and successes.

How I do this:

• Quick quarterly surveys asking about pain points, confidence levels, and the types of research they’re struggling with most.

• Short interviews or casual coffee chats to dive deeper into survey findings, clarifying ambiguous feedback.

I once discovered through a quick stakeholder survey that teams avoided our research repository because they found the tagging system confusing. This simple insight led to a clearer system that increased adoption and reduced duplicated work.

Implement an anonymous feedback channel

Not everyone feels comfortable openly sharing their struggles, especially if it feels critical of you or your team. An anonymous feedback option ensures honest, candid responses.

How I do this:

I use a simple Google Form, clearly labeled as anonymous, sent out monthly. I ask stakeholders questions like:

• “What part of the research process feels most challenging or unclear?”

• “Are there barriers preventing you from using the research repository effectively?”

For example, anonymous feedback once revealed stakeholders were hesitant to ask for help, fearing they’d seem incompetent. That led me to set up casual “office hours” to normalize asking for support, quickly solving that issue.

Use Data to Track Common Pitfalls

Tracking common pitfalls systematically helps you catch trends early and tackle root causes proactively rather than continuously putting out fires.

Patterns in methodology mistakes

Repeated mistakes indicate a systemic issue, usually either training gaps or unclear resources.

During quarterly audits, I categorize common methodology issues. If the same mistakes pop up repeatedly, like consistently biased questions, I know stakeholders need refresher training.

For example, I noticed stakeholders repeatedly misunderstood when to use open-ended vs. closed-ended questions. A simple, targeted training module completely turned this around, improving question quality across all future studies.

Frequent ethical oversights or repository usage issues

Ethical issues (like improper consent forms or privacy mistakes) aren’t just embarrassing, they’re serious risks. Catching these trends early is critical. Similarly, repository issues can massively undermine the value of your democratization program.

How I track this:

• Logging ethical oversights found during audits or stakeholder feedback sessions.

• Tracking repository issues: duplicated studies, untagged reports, or documents saved in personal drives instead of central repositories.

After noticing repeated confusion around participant consent forms, we created a simple, required training video specifically on consent and privacy. Issues dropped significantly after stakeholders had clearer guidance.

Establishing a proactive monitoring system takes work. But believe me, the payoff is huge. You’ll quickly move from firefighting mode, always scrambling, to proactive mode, where you anticipate problems before stakeholders even realize they’re having them.

Your stakeholders will appreciate clear guidance, support, and continuous improvements, and you’ll sleep better knowing your democratization model isn’t secretly falling apart behind the scenes.

Remember: democratized research is a powerful tool, but only if you’re consistently looking after its health. Do your future self (and your stakeholders) a favor by setting up a proactive monitoring system today.

Responding to Quality Issues

Let’s talk about something uncomfortable but inevitable. At some point, stakeholders conducting research will produce low-quality work. And it will make your researcher heart sink when you spot biased surveys or usability tests that lack even basic structure. Trust me, I’ve been there, probably more often than I care to admit.

While it’s tempting to panic or start pulling your hair out, what’s more effective (and sanity-saving) is having clear, actionable strategies ready to respond quickly and productively.

Here’s exactly how I tackle these challenges, complete with real-life strategies you can steal immediately.

Issue: Stakeholders Producing Low-Quality Research

Low-quality research isn’t just frustrating, it actively undermines the credibility and value of user research in your organization. Once stakeholders (or worse, leadership) start questioning the accuracy or value of insights, rebuilding that trust is painfully slow.

Here’s exactly what I recommend doing to prevent, and quickly respond to, quality issues:

Response Strategy #1: Implement Mandatory Review by Trained Researchers

A mandatory review acts as a clear gatekeeper, preventing poorly constructed research from ever reaching stakeholders or decision-makers. It gives your research team a chance to catch and correct mistakes before any damage is done. Here’s how to do it:

• Clearly communicate expectations. Let stakeholders know upfront that every survey, usability test plan, or research guide needs to be reviewed by a trained researcher before it goes live.

• Build an easy submission process. Create a simple, low-friction submission workflow (Google Form, Notion page, or Slack channel) to submit research for review.

• Define a realistic review timeline. Provide a transparent turnaround time (mine is usually around 2–3 days). Stakeholders know exactly when they’ll get feedback and plan accordingly.

We once had a marketing team write a customer satisfaction survey full of leading questions (“How much do you love this feature?”). Thankfully, our mandatory review caught it in time. Instead of panicking, we scheduled a quick 20-minute call, rewrote the questions together, and ended up with meaningful insights rather than biased fluff.

Response Strategy #2: Develop a “Research Quality Checklist” for Stakeholders

When stakeholders have clear criteria to measure their research against, quality dramatically improves, even before it hits your desk for review. It helps stakeholders internalize best practices and self-correct earlier in the process.

My “Research Quality Checklist” typically includes points like:

• Objective clarity: Are research goals clearly defined and focused?

• Bias check: Do questions avoid leading language, assumptions, or confirmation bias?

• Participant recruitment: Is the sample diverse, representative, and unbiased?

• Insight integrity: Are insights backed by direct evidence and clearly linked to the original research question?

I hand stakeholders this checklist upfront (and repeatedly remind them to use it!).

A design team I worked with was notorious for usability tests with ambiguous tasks. After introducing the checklist, they started explicitly defining clear objectives and scenarios for testing. Sessions became consistently productive, and I spent far less time rewriting their scripts.

Response Strategy #3: Offer Focused, Targeted Training Sessions Addressing Skills Gaps

When you see repeated quality issues, it’s usually because stakeholders simply don’t know better (or forgot your previous training). Addressing specific, targeted skill gaps in short, practical training sessions can completely transform research quality. You can do this by:

• Identifying skill gaps: During reviews, audits, or feedback, note exactly which mistakes appear repeatedly.

• Scheduling short, targeted sessions: Run focused, bite-sized workshops on topics like “Unbiased Survey Writing” or “Structuring Effective Usability Tests.”

• Providing clear, actionable templates: Always pair your training with ready-to-use templates or examples to reinforce what they’ve learned.

Recently, we recently noticed a high rate of biased questions in stakeholder surveys (think: “Why is this feature so great?”). To fix this, we held a 90-minute workshop specifically on unbiased question-writing, complete with hands-on exercises, clear templates, and concrete before-and-after examples. The next set of surveys we reviewed showed immediate improvement, with questions that produced genuinely insightful data.

Stakeholders doing research will always come with some degree of quality risk. It’s inevitable. But instead of despairing, you can prepare proactively with these clear, actionable response strategies:

1. Mandatory researcher reviews catch errors before they do damage.

2. Research quality checklists empower stakeholders to self-correct before issues arise.

3. Focused, targeted training sessions tackle recurring problems at the source.

In my experience, clearly addressing quality issues head-on, and calmly guiding stakeholders toward improvement, does wonders for building trust, respect, and long-term buy-in for research across your organization.

Responding to Operational and Documentation Issues

If you’ve democratized research even slightly, you’ve probably encountered this headache, a fragmented documentation, inconsistent reporting practices, and duplicated insights scattered across every possible tool your company uses. You know the drill, one team has their findings in a Slack thread, another in Notion, and a third stored them in a random Google Doc no one can find. Suddenly, your organization’s insights resemble a digital scavenger hunt rather than a reliable repository of knowledge.

I’ve been there (and if I’m honest, I might even have caused it once or twice). The good news is, it’s fixable if you take clear, actionable steps early.

Issue: Insights scattered across multiple systems, duplicated efforts, repository inefficiencies

When documentation gets fragmented, insights become unreliable—or worse, forgotten. Stakeholders waste precious time chasing down the same insights repeatedly, duplicating studies, or making decisions without the benefit of existing research. This doesn’t just hurt your credibility, it also wastes everyone’s time.

Response Strategy #1: Clearly define and communicate documentation requirements

Documentation chaos usually starts because people aren’t clear on exactly what’s expected of them. Having crystal-clear documentation requirements removes ambiguity and creates consistent practices across teams:

• Create a standardized reporting template. Provide a structured template everyone uses. Include clear sections for research objectives, methods, key findings, supporting evidence, and next steps. (I usually put mine in Notion or Airtable.)

• Document exactly where insights must live. Pick one central tool (Condens, Airtable, or even a dedicated Notion workspace) and explicitly mandate that all final insights must go there, no exceptions.

• Communicate repeatedly (and kindly). Share your documentation guidelines multiple times: in training, Slack announcements, team meetings, and onboarding sessions. Don’t assume stakeholders remember after seeing it once.

When my last organization faced insight chaos, we standardized all reports into an Airtable template with clear sections. After just a few weeks (and gentle reminders), everyone started reliably documenting insights in the same place, dramatically reducing confusion and duplication.

Response Strategy #2: Regularly audit repository use, emphasizing accountability

When stakeholders know documentation is being actively monitored, compliance skyrockets. Regular audits reveal who’s using the repository correctly, who needs extra help, and who might just need a polite reminder. Here’s how to run effective repository audits:

1. Schedule quarterly repository audits. Pick random samples of research documentation across teams and evaluate them for completeness, clarity, and proper storage.

2. Create a simple scoring rubric. Develop straightforward evaluation criteria (correctly documented objectives, clearly defined next steps, insights properly tagged).

3. Share audit results transparently. Present audit results openly and clearly, recognizing teams with excellent documentation, and offering practical, supportive feedback to those lagging.

We introduced quarterly repository audits at one company after finding insights scattered across Slack, Notion, and Google Drive. At first, it felt awkward, but after sharing the first audit results transparently (with plenty of positive shoutouts), stakeholders got competitive (in a good way) about improving their documentation. Within two quarters, compliance improved by over 70%.

Response Strategy #3: Consolidate insights in a centralized, accessible, and easy-to-use system

A centralized, easy-to-use repository removes friction, making it effortless for teams to store, find, and use insights. If using your documentation system feels like pulling teeth, stakeholders simply won’t do it. Make it easy, and they’ll flock to it. Here are some steps to consolidate effectively:

1. Pick one intuitive, flexible tool: Choose something that stakeholders genuinely like using. I really recommend tools like Condens for a repository.

2. Clearly structure and tag insights. Use a simple tagging system (by project, team, method, or persona) to make insights instantly discoverable.

3. Provide training and onboarding support. Hold quick, interactive onboarding sessions showing stakeholders exactly how to use your chosen repository tool (trust me—this 30-minute training pays dividends!).

I’ve successfully used Condens to centralize fragmented research. We ran quick onboarding sessions, developed a consistent tagging system (by project, research method, and audience), and stakeholders loved the ease of searching and sharing insights. The system quickly became indispensable, solving our fragmentation issue practically overnight.

Response Strategy #4: Appoint a dedicated research operations owner or coordinator

Having someone specifically accountable for research operations ensures that documentation and repositories don’t slip through the cracks as everyone’s “second job.” A dedicated owner actively manages the system, provides support, runs audits, and makes continuous improvements.

1. Clearly define responsibilities. Make sure the operations owner knows exactly what’s expected: managing documentation guidelines, conducting audits, onboarding new stakeholders, and troubleshooting problems.

2. Empower them to drive accountability. This person should regularly check in with stakeholders, offer support proactively, and gently hold teams accountable when they slip.

3. Set measurable KPIs. Metrics might include repository compliance rates, reduced duplication, or stakeholder satisfaction with documentation processes.

We assigned one senior researcher as our dedicated research ops coordinator for documentation. She actively supported stakeholders, ran the audits, and even held open “office hours” for documentation questions. Our compliance jumped almost immediately and stakeholders genuinely appreciated the dedicated support.

Scattered documentation and inefficient repositories don’t fix themselves. But with clear, supportive, and structured interventions, you can turn chaos into clarity:

• Define and communicate clear documentation requirements (think easy templates, simple instructions).

• Regularly audit repository usage to drive accountability (friendly reminders work wonders!).

• Consolidate your insights in a centralized, user-friendly system (the right tool makes compliance painless).

• Appoint someone specifically accountable for research operations (this isn’t a side hustle, give it dedicated attention).

By tackling these operational issues directly (but kindly), you’ll improve compliance, reduce duplication, and regain trust in the research process all while saving your own sanity.

Responding to Ethical and Compliance Issues

Ethics and compliance can feel like the least exciting part of user research, but if stakeholders mess it up, things can go downhill fast. Mishandled consent or poorly managed sensitive data isn’t just inconvenient; it can trigger severe regulatory issues, damage customer trust, and genuinely harm your organization’s reputation.

I’ve seen stakeholders accidentally skip consent because they didn’t fully understand the implications, or casually store sensitive participant data in random documents.

In fact, I messed up myself big time because I was rushing and had a very minor compliance issue when recruiting participants.

It happens more often than you’d think.

Issue: Stakeholders mishandling consent or sensitive user data

When consent and data handling slip through the cracks, your organization can quickly find itself facing legal issues or, at best, seriously damaged trust with participants. Ethical missteps can even lead leadership to question whether democratization was a good idea in the first place. We want to avoid this scenario completely.

Here’s exactly how you can make sure ethical standards stay airtight and actionable:

Response Strategy #1: Require explicit ethical training for anyone conducting research

Most ethical mistakes happen simply because stakeholders don’t know what they don’t know. Clear, explicit ethical training ensures they fully understand their responsibilities, without making ethics feel scary or bureaucratic. Here is how to make ethical training actionable and practical:

• Make it short, clear, and mandatory. Run a straightforward 1–2 hour training that covers participant consent, data protection basics, and the key dos and don’ts of ethical research.

• Incorporate real-life scenarios. Use concrete examples and scenarios (ideally from your own organization or similar ones) to highlight common mistakes and exactly how to avoid them.

• Include an interactive quiz or knowledge check. Ensure stakeholders genuinely grasp the content with a quick quiz at the end. No stress, but it reinforces the essentials.

At my previous company, we rolled out a simple mandatory ethics training module with practical scenarios (“You recorded a usability test—where can you store the recording?”). Stakeholders quickly understood exactly what they could and couldn’t do, and ethical mistakes dropped sharply.

Response Strategy #2: Establish a dedicated compliance checkpoint in research workflow

Embedding a compliance checkpoint directly into your research workflow ensures ethical considerations aren’t forgotten in the rush to launch research. It puts ethics front and center at exactly the right moment. Here are some steps you can follow:

1. Build it into your research process. Clearly mark a compliance checkpoint before any research goes live, this could be a checkbox in your research approval form or a step in your research tool’s workflow.

2. Provide a simple compliance checklist. Include essential items like: consent form completed, sensitive data storage identified, participant anonymity measures in place.

3. Have clear escalation paths. Clearly communicate who stakeholders should reach out to if they’re unsure about compliance (typically you or your designated compliance owner).

For example, I introduced a mandatory “compliance check” step in our research approval workflow. Stakeholders simply couldn’t launch studies without confirming that they’d reviewed the compliance checklist. It only took an extra few minutes, but compliance rates soared immediately.

Response Strategy #3: Assign ethics reviews for all research involving sensitive data

Sensitive data, like health records, financial information, or private conversations, requires special handling. An explicit ethics review ensures risks are identified early, avoiding serious missteps. Here’s how to run one:

1. Clearly define what counts as sensitive data. Explicitly state categories (health data, financial information, personally identifiable information, etc.) that trigger an ethics review.

2. Create a quick ethics-review template. Include straightforward questions stakeholders must answer questions like: “How is data anonymized?” “Where will data be stored?” “Who can access it?”

3. Appoint an ethics review point-person. Designate someone trained in ethical practices who stakeholders can approach for quick ethics checks. This could be you or another senior researcher.

Response Strategy #4: Clearly document consent guidelines in easily accessible formats

If your consent guidelines are buried in dense documents or scattered in multiple locations, stakeholders simply won’t use them. Accessible, clearly documented guidelines make ethical compliance effortless. You can do this by:

• Creating simple consent form templates. Provide easy-to-use, clearly worded templates stakeholders can quickly adapt for their studies.

• Document exactly how and where to store consent: Give clear instructions about where stakeholders should keep consent forms.

• Make guidelines easily findable. Store ethical documentation prominently in your centralized research repository (Notion, Airtable, Condens), and pin it in Slack or internal knowledge tools.

At one org, we noticed incomplete consent forms happening frequently. We created simple consent-form templates stakeholders could easily customize, clearly communicated exactly where to store these forms (in a secured folder), and pinned these instructions in Slack. Compliance issues drastically reduced.

Ethical research isn’t just about rules, it’s about trust. By proactively embedding these clear, actionable steps into your democratized research workflow, you protect your organization, empower your stakeholders, and elevate the overall credibility of user research.

Responding to Cultural and Organizational Issues

User research democratization can quickly become contentious if stakeholders feel uneasy, resistant, or worried about the value of professional researchers diminishing. You may find yourself fielding awkward comments like, “So, anyone can do user research now?” or even dealing with stakeholders quietly conducting rogue studies out of misunderstanding or mistrust.

I’ve personally experienced team members and researchers who were genuinely anxious that democratizing research meant devaluing their hard-earned expertise. It’s a valid concern. But these cultural challenges are solvable if you’re proactive, transparent, and empathetic from the start.

Issue: Resistance from teams or concerns over the devaluation of UX researchers

Resistance isn’t just annoying, it can seriously derail your democratization efforts. If your teams don’t fully understand or support the democratization model, you’re setting yourself up for friction, confusion, and mistrust. People may become protective over their roles, defensive about expertise, or feel threatened. (Not a fun scenario.)

Let’s dive into clear, actionable strategies to prevent (or quickly fix) these cultural challenges.

Response Strategy #1: Clearly communicate the role and value of professional researchers

The root of resistance often comes down to misunderstanding or fear about roles changing. Clearly defining the ongoing critical role of professional researchers ensures everyone feels secure, respected, and confident about their place in the new model. Here are some ways to do that:

• Schedule an “All-hands” or team-wide meeting. Clearly explain the democratization strategy, emphasizing the unique skills, deep expertise, and value professional researchers bring (generative research, complex studies, research synthesis).

• Create a simple visual or diagram (use a slide, Miro, or Notion). Illustrate clearly what stays researcher-led vs. what stakeholders can lead—make this easily shareable.

• Send regular updates (monthly or quarterly emails/Slack posts). Reinforce your researchers’ critical role through clear examples, celebrating their deeper research contributions and impact.

When I first introduced democratization in my team, some researchers expressed concern about their roles. I immediately scheduled a short session clearly articulating researchers’ continuing responsibilities, highlighting strategic research, synthesis, and generative studies. Resistance immediately softened.

Response Strategy #2: Reinforce the complementary nature of democratized and dedicated research efforts

Stakeholders often worry democratization means professional research is less valuable. Clarifying how democratized research complements (rather than replaces) dedicated researchers ensures everyone sees democratization as collaboration, not competition. Some steps on how to do this include:

• Running interactive training sessions. Pair researchers and stakeholders together to illustrate how professional researchers add value by mentoring, reviewing, and guiding research quality.

• Highlighting concrete examples of collaboration. Regularly showcase successful case studies where democratized research fed into, and was improved by, professional researcher insights.

• Implementing regular pairing or mentorship sessions. Create structured opportunities for researchers and stakeholders to collaborate regularly (office hours, research pairing), reinforcing the complementary relationship.

At one org, to reduce friction, we set up weekly “Research Office Hours,” explicitly pairing researchers with stakeholders. Stakeholders quickly saw how professional researchers helped deepen insights, and researchers felt valued for their expertise.

Response Strategy #3: Showcase successful democratization examples internally

Resistance often stems from skepticism or uncertainty. Showing successful democratized research examples within your organization provides proof democratization works and can win skeptical teams over quickly:

1. Start a monthly democratization showcase. Briefly highlight one or two successful democratized studies in a short monthly update (email, Slack, newsletter, or Condens).

2. Ask stakeholders to share their own experiences. Invite stakeholders who’ve successfully run studies to speak briefly at team meetings or research gatherings about their positive experiences.

3. Create a democratization “wins” page. Use Notion, Condens, or another internal tool to collect examples of successful democratized studies, clearly summarizing outcomes and stakeholder testimonials.

We created a monthly Slack thread called “Democratization Wins” where stakeholders shared their successful usability tests and how professional researchers improved their work. Skeptical teams quickly became more open-minded.

Response Strategy #4: Set clear boundaries around what remains researcher-led and what is democratized

Ambiguity creates anxiety. Clearly defined boundaries reassure researchers that their expertise isn’t being replaced and help stakeholders feel clear about exactly where their responsibilities begin and end. Here are some boundaries to try:

• Create and distribute a simple one-pager or decision tree. Explicitly outline exactly which studies stakeholders can lead (usability tests, surveys) and those strictly researcher-led (generative, strategic studies).

• Communicate boundaries clearly and repeatedly. Reinforce these boundaries in your trainings, during office hours, and via regular communications.

• Include clear escalation paths. Clearly state who stakeholders should approach if they are unsure if a study should be researcher-led.

The key to addressing cultural issues is proactive transparency. With clear communication, consistent reinforcement, and tangible examples, you’ll quickly move your stakeholders from resistant to supportive, strengthening your democratization efforts and your organization’s trust in user research.

Creating an Issue Escalation and Resolution Framework

At some point during user research democratization, things will inevitably go wrong. Maybe stakeholders release a biased survey, sensitive data gets mishandled, or critical findings get misinterpreted, causing confusion across teams.

When these issues arise, your response matters—a lot. It not only influences the immediate problem but also sets a precedent for how seriously your organization takes user research and its credibility.

Having an issue escalation and resolution framework in place might sound overly corporate or bureaucratic. This structure will save you from confusion, anxiety, and constant firefighting down the line.

Step 1: Establish Clear Escalation Paths

When something goes wrong, stakeholders should know exactly who to contact, who will handle it, and how quickly they’ll hear back. Without this clarity, issues get lost, ignored, or handled inconsistently. Here’s how to set this up:

1. Define severity clearly and simply. Start by categorizing issues into three easy-to-remember groups:

   1. Minor: Small mistakes with limited impact (like a single biased question on a usability test).

   2. Major: Issues happening repeatedly or those seriously affecting decisions (stakeholders repeatedly misunderstanding findings).

   3. Critical: Any ethical or compliance violations (like missing consent forms or privacy breaches).

2. Identify clear ownership. Clearly assign who’s responsible at each level, for example:

   1. Minor issues → Research operations coordinator (resolved in 1–2 days)

   2. Major issues → Senior or Lead UX Researcher (response within one day, thorough follow-up within a week)

   3. Critical issues → Head of Research or Data Compliance Lead (immediate resolution within hours)

3. Communicate this widely (and repeatedly). Send regular reminders via Slack, email, or wherever stakeholders engage most. Outline the severity levels, who’s responsible, and how quickly issues will be addressed.

Step 2: Set Clear Criteria for Escalating Issues

Your stakeholders aren’t mind-readers. If they aren’t clear on when to escalate an issue, important problems may go unnoticed. Avoid ambiguity by clearly defining when something must be escalated:

1. Document specific triggers that require escalation clearly. Here are a few examples of how you could define triggers:

   1. Ethical or consent violations: Immediately escalate (critical)

   2. Repeated research quality issues (e.g., consistently poor survey design after multiple trainings): Major escalation

   3. One-time, minor methodological mistakes (e.g., single instance of a poorly phrased question): Minor escalation

2. Give concrete examples to stakeholders. Say something clear and relatable, such as:

   1. “If you find that participant consent forms were not completed correctly, escalate immediately as a critical issue. If you spot biased questions showing up repeatedly in surveys after multiple training sessions, escalate as a major issue.”

3. Reinforce escalation criteria during training. Explicitly discuss escalation processes during onboarding and refresher sessions so stakeholders know exactly when to act.

Step 3: Maintain Transparency Throughout the Escalation Process

People get anxious when they don’t know what’s happening. Transparency about what issues have come up, how you’re responding, and what you’re doing to prevent them is essential to building trust in the research process. Here’s how to put this into practice:

1. Set up a simple, transparent tracking method. This could be a Google Sheet, Airtable, or Notion page where everyone sees:

   1. A brief description of each issue

   2. Severity level and who’s handling it

   3. Current status and how it was resolved

   4. Preventative actions taken

2. Regularly communicate back to stakeholders. Monthly (or bi-monthly), share brief, plain-language summaries. For example:

   1. “Last month, we encountered two critical ethical issues around participant consent. We quickly resolved this by requiring mandatory ethics training for anyone running research. We also saw recurring issues with survey biases, so we’ve scheduled refresher training sessions.”

3. Discuss openly during quarterly research meetings. Use quarterly meetings as opportunities to talk openly about challenges and lessons learned. This reinforces accountability and a healthy research culture.

Your escalation framework doesn’t need to be complex, it just needs clarity. By clearly defining severity levels, assigning clear ownership, setting explicit escalation criteria, and maintaining full transparency, you’ll handle democratization issues proactively, calmly, and effectively, keeping user research valuable, credible, and respected across your organization.

Communicating Issues and Responses Internally

Communicating clearly about issues that crop up is vital. However, no one enjoys receiving negative news, especially when it could reflect badly on their team or their work. How you communicate these issues matters a lot. Poorly handled communication can create resistance or tension; great communication turns these moments into learning opportunities and builds trust.

Here’s how to communicate issues internally clearly, constructively, and actionably (without hurting anyone’s feelings or wasting their time).

Always Frame Issues Constructively (Opportunities vs. Failures)

No one likes hearing their project has issues, and calling out mistakes can easily make people defensive or demoralized. Instead, present challenges as opportunities for improvement or learning. This shifts the conversation from blame to growth. Here are some tips I use:

• Avoid negative language.

  • Instead of:“This survey was biased and unusable,”

  • Try “We spotted an opportunity to make our surveys clearer and more neutral to ensure high-quality insights.”

• Always include the solution alongside the issue.

  • Instead of “Participants weren’t properly consented, this is unacceptable,”

  • Try “We noticed a gap in consent processes. Let’s use this as an opportunity to clarify our guidelines, implement quick training refreshers, and avoid future issues.”

Highlight Examples Where Issues Were Successfully Addressed

People love stories. Rather than only pointing out where things have gone wrong, include clear, concrete examples where your teams successfully resolved an issue. This builds confidence and reinforces positive behaviors internally. Here are some ways to do this:

• Weekly or monthly success stories. Briefly share stories in meetings, Slack, or newsletters:

  • “Last month, the product team noticed repeated bias in surveys. After a quick training session, they wrote an unbiased survey that gave clear, actionable insights, directly leading to improved user experience. Great job!”

• Personalized shoutouts. Recognize individuals publicly (always check first if they’re comfortable):

  • “Huge thanks to Sarah, after attending the refresher on survey design, her latest survey provided some of the clearest data we’ve seen yet!”

This balances the communication about challenges with recognition, keeping people motivated rather than discouraged.

Use Clear, Consistent Language Across All Communications

Consistency builds trust and clarity. If your communication style or language is all over the place, people get confused. Keep things clear, consistent, and easy to understand so everyone knows exactly what you’re talking about each time.

1. Create a simple glossary or communication guide. Outline terms clearly, such as “biased questions,” “ethical escalation,” and “critical issues,” and always use these consistently in emails, Slack, or meetings.

2. Use structured communication templates. For example, a short, clear message structure for issues might look like this:

   1. Issue Identified: (Brief description in neutral, factual language)

   2. Opportunity: (Positive framing of issue as an improvement opportunity)

   3. Immediate Actions: (Exactly what’s being done right away)

   4. Next Steps: (Any follow-up training, check-ins, or audits planned)

Example of a short internal communication:

Issue Identified:

Consent forms were incomplete on three recent user interviews.

Opportunity:

Great chance to refresh our team’s awareness on consent guidelines to improve data compliance.

Immediate Actions:

We’ve scheduled a brief, focused training for next week on consent processes.

Next Steps:

Compliance checks will be reinforced to prevent recurrence. Any questions—reach out directly!

Keep Regular Updates Short and Actionable

Your stakeholders are busy. Long, drawn-out emails or Slack messages won’t get read thoroughly. Short, actionable messages are far more effective.

• Use bullet points instead of paragraphs. People skim, so bullet points grab attention: Instead of “We noticed multiple issues with biased questions in recent surveys, and it’s essential that we address these issues quickly to ensure our data remains valid and trustworthy…”

• Try

  • Issue: Recent surveys have biased questions.

  • Solution: Immediate refresher training this Friday at 11am.

  • Action: RSVP here (link) and attend live or watch the recording by end-of-day Monday.

• End each message with a clear action or call to action. For example, “Action required: Attend the training session or watch the recording by next week.”

This approach ensures your messages drive immediate, helpful actions, rather than being ignored or postponed.

Here’s how you might combine all of the above into one clear, positive, actionable message:

Quick Update: Improving Survey Quality

Issue:

We recently spotted biased questions in some stakeholder surveys, which limits the accuracy of our findings.

Opportunity:

This is a great chance for everyone to brush up on survey best practices and improve data quality together!

What’s happening next:

• A quick, practical survey design workshop is scheduled this Thursday at 3 pm (RSVP here).

• We’ve added clearer templates to our documentation (available here).

• Shoutout to Alex’s team, after attending this session last quarter, their recent surveys have been excellent!

Action:

Please RSVP and attend the session or watch the recording by the end of the week. Any questions, Slack me!

Communication around democratization issues should never be scary or anxiety-inducing. When you frame issues constructively, celebrate successes, keep your language clear, and communicate actionably and briefly, your team will see research democratization as a continuous improvement process, one they’re excited to be a part of, rather than afraid of getting wrong.

Start small, stay consistent, and keep the tone positive. It really makes all the difference.

Democratization Issues Are Normal

If you’re feeling overwhelmed by all these potential democratization issues, take a deep breath. Encountering problems when democratizing user research isn’t just normal, it’s expected. Even the most thoughtfully built frameworks hit snags along the way. The difference between successful democratization and a messy situation is proactively managing these bumps rather than letting them spiral.

Expect Issues

First off, normalize the idea that democratization won’t be perfect from day one. Stakeholders will inevitably write biased surveys, repositories might get messy, and ethical slip-ups could occur. These are not failures—just signals you need clearer guidance, training, or oversight.

• Remind yourself (and your stakeholders!) frequently that issues are learning opportunities, not disasters.

• Have your escalation and response frameworks clearly documented and ready to go, so you’re never caught off-guard.

Use Clear Governance and Proactive Monitoring

A clear governance structure is like the scaffolding around your democratization efforts. It holds everything steady. Regularly checking in on your democratized research through audits, feedback loops, and clear checkpoints ensures your framework stays healthy and credible.

• Set up quarterly quality audits and stakeholder feedback loops immediately.

• Publish your governance framework widely so everyone knows exactly how things work and how they can quickly flag or resolve issues.

Targeted Responses Solve Problems

When issues arise, don’t just react randomly—be intentional. Having specific strategies to address different types of problems (quality, operational, ethical, cultural) makes your responses faster, clearer, and more effective.

• Create easy-to-follow response plans for each type of issue we discussed:

  • Quality: Quick checklists, targeted training refreshers, mandatory reviews.

  • Operational: Centralized, clearly-documented repositories, dedicated research ops oversight.

  • Ethical: Simple templates, explicit consent guidelines, mandatory ethical training, and compliance checkpoints.

  • Cultural: Clear boundaries between democratized and researcher-led studies, regular celebration of successes, reinforcing the value of professional research roles.

Continuous Improvement Is Not Optional

Democratization is never “done.” It’s a constantly evolving process. Regularly revisiting your approach and adjusting your strategy keeps your organization sharp, credible, and effective.

• Schedule regular review checkpoints at least quarterly to reassess how your democratization model is performing.

• Create an easy way for stakeholders to give ongoing feedback—anonymous surveys or open Slack channels—so you know exactly where to focus improvement efforts.

Responding to democratization issues doesn’t mean something’s gone wrong, it means you’re doing democratization right. Every organization faces these challenges, but the ones that thrive are proactive, clear, and structured.

Democratization issues can be like weeds in a garden, inevitable, but manageable if you consistently check, prune, and nurture. By clearly communicating your plans, proactively monitoring your processes, and positively addressing challenges, you’ll keep democratization growing healthy and strong.

Now, go tackle democratization confidently. You’ve got this.

Stop piecing it together. Start leading the work.

The Everything UXR Bundle is for researchers who are tired of duct-taping free templates and second-guessing what good looks like.

You get my complete set of toolkits, templates, and strategy guides. used by teams across Google, Spotify, , to run credible research, influence decisions, and actually grow in your role.

It’s built to save you time, raise your game, and make you the person people turn to.

→ Save 140+ hours a year with ready-to-use templates and frameworks

→ Boost productivity by 40% with tools that cut admin and sharpen your focus

→ Increase research adoption by 50% through clearer, faster, more strategic delivery

Grab the Everything UXR Bundle

Stay curious,

Nikki

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

This is a series on user research democratization — since this is a tough topic, there was way too much for one article. I will be writing this series and posting it over the next weeks and will edit this as I add to the series so you can easily navigate the different parts.

• Part 1: The Complex Landscape of Research Democratization (Free)

• Part 2: A Framework for Responsible Research Democratization (Paid)

• Part 4: Responding to UXR Democratization Issues (Free)

Stop piecing it together. Start leading the work.

The Everything UXR Bundle is for researchers who are tired of duct-taping free templates and second-guessing what good looks like.

You get my complete set of toolkits, templates, and strategy guides. used by teams across Google, Spotify, , to run credible research, influence decisions, and actually grow in your role.

It’s built to save you time, raise your game, and make you the person people turn to.

→ Save 140+ hours a year with ready-to-use templates and frameworks

→ Boost productivity by 40% with tools that cut admin and sharpen your focus

→ Increase research adoption by 50% through clearer, faster, more strategic delivery

Grab the Everything UXR Bundle

Scaling Research Without Sacrificing Rigor

Research democratization is not a one-size-fits-all solution. What works for one company might fail in another due to differences in team size, research maturity, leadership buy-in, and decision-making culture. Instead of adopting a democratization model blindly, your first step should be research on your own organization.

This chapter has outlined multiple approaches to research democratization, from fully decentralized models to research-led approaches with controlled access. But choosing the right approach requires an honest evaluation of your company’s unique needs, challenges, and research maturity.

This is where your own research skills come into play. Before deciding how to scale research within your organization, take time to assess your current environment, define your goals, and determine the level of structure and oversight required to ensure success.

Assess the Current State of Research in Your Organization

To scale research without sacrificing rigor, you first need a comprehensive understanding of how research currently functions within your organization. Without a clear baseline, democratization efforts risk becoming chaotic, misaligned, or ineffective. Don’t skip this step! We do this:

• To identify exactly who is conducting research.

• To understand the types of research being performed.

• To find bottlenecks preventing effective research.

• To gauge how leadership values research.

• To document how research insights are shared and consumed.

Let’s dive into how to assess the current state.

1. Map Out Current Research Roles and Responsibilities

Objective: Clarify exactly who is conducting research, formally or informally.

Steps:

1. List all individuals conducting research regularly, including:

   1. Trained researchers (User Researchers, UX Researchers, etc.)

   2. Designers

   3. Product Managers

   4. Marketers

   5. Engineers

   6. Customer Support or Success Teams

2. Determine the frequency with which each role performs research:

   1. Is research part of their job description, or are they doing it informally?

   2. How frequently do non-researchers independently initiate studies?

2. Inventory Types of Research Currently Conducted

Objective: Understand what research methods are being used and by whom.

Steps:

1. Catalog recent research projects over the last 3-6 months.

2. Categorize these by research type:

   1. Usability testing (quick tests, prototype evaluations)

   2. Surveys (customer satisfaction, feedback)

   3. Interviews (generative or evaluative)

   4. Analytics reviews (product usage analysis)

   5. Generative or strategic studies (exploratory, opportunity-focused research)

3. Highlight gaps between desired and actual types of research performed.

3. Identify Research Bottlenecks and Pain Points

Objective: Determine the obstacles preventing effective and timely research.

Steps:

1. Conduct stakeholder interviews or surveys asking:

   1. “How often are you delayed by waiting for research results?”

   2. “Have you ever skipped research due to lack of availability?”

   3. “How often do you have to conduct research on your own without support?”

2. Quantify these pain points if possible (“70% of Product Managers skip research due to long wait times”).

Example survey question (with rating scale):

“On a scale of 1-5, how often do you find research availability a blocker for timely decisions?”

(1 = Never, 5 = Always)

Example finding:

“80% of Product Managers rated research availability as 4 or higher, indicating significant delays.”

4. Evaluate Leadership’s Attitude Toward Research

Objective: Assess how research is valued by leaders and decision-makers.

Steps:

1. Conduct targeted leadership interviews or distribute a leadership-focused survey. Ask clear, pointed questions such as:

   1. “Do you consider research essential, helpful, or optional for decision-making?”

   2. “Can you provide examples of recent decisions influenced by research?”

   3. “How much are you willing to invest in research resources and training?”

2. Analyze responses to determine if leadership views research as:

   1. A critical component

   2. An occasional input

   3. A luxury or nice-to-have

Example question:

“Describe a recent instance where research directly impacted your decision-making.”

Example finding:

“We delayed launching the new pricing model until the UX team conducted surveys—research is crucial for big decisions like pricing.”

5. Assess How Research Insights Are Currently Shared and Stored

Objective: Understand how research insights are documented and made accessible.

Steps:

1. Identify all locations where research insights currently live:

   1. Centralized (Dovetail, Airtable, Confluence)

   2. Decentralized (Google Drive folders, Slack, emails)

2. Check how consistently insights are documented:

   1. Do insights consistently include the research question, methods, results, and actionable recommendations?

3. Evaluate accessibility and discoverability:

   1. Are insights easy to find by people across the organization?

   2. How often do stakeholders complain about not finding past research?

6. Summarize Your Findings Into a Clear Research Landscape Report

Objective: Create a succinct, actionable summary highlighting gaps, strengths, and weaknesses.

Suggested structure:

• Current research roles:

  • Who’s conducting research (trained vs. informal)?

• Research types in use:

  • Methods commonly and rarely used.

• Identified bottlenecks:

  • Delays in conducting or accessing research.

• Leadership alignment:

  • How critical is research viewed by leadership?

• Research documentation & sharing:

  • Current status of knowledge management and accessibility.

Example:

“Research is primarily done by one full-time UX researcher, supported informally by designers and PMs. Usability testing is frequent, but generative research is nonexistent. Teams often skip research due to delays, and leadership sees it as important but secondary. Documentation is decentralized, causing frequent duplication and wasted efforts.”

Define Your Organization’s Research Needs and Risks

Not all organizations require the same level of research rigor, nor can they accept the same level of risk. Clearly understanding your organization’s specific needs and risk tolerance is essential to creating a democratization model that is both effective and safe. This step is necessary to:

• Ensure the democratization model aligns with your organization’s specific risk and rigor requirements.

• Prevent costly errors resulting from inappropriate levels of oversight.

• Leverage existing skills within your organization efficiently.

1. Determine the Level of Research Rigor Required

Research rigor refers to the quality standards and methodological thoroughness expected within your organization.

Steps:

1. Classify decision types and their consequences. List recent or upcoming decisions influenced by research. Categorize these by the impact and risks involved.

2. Categorize the decisions into tiers of required rigor:

   1. High-Rigor: Decisions have significant financial, legal, or safety implications.

   2. Medium-Rigor: Decisions impact user satisfaction, retention, or moderate financial outcomes.

   3. Low-Rigor: Decisions are incremental, reversible, or experimental.

Prompting questions:

• What kinds of decisions does your organization regularly face?

• What is the worst-case scenario if research for these decisions is inaccurate or incomplete?

• Can you group your decisions into categories based on the potential risk or consequence?

2. Clarify Your Organization’s Risk Tolerance

Risk tolerance defines how much uncertainty or potential harm your organization is willing to accept as it expands research responsibilities.

Steps:

1. Conduct internal interviews or workshops to gauge comfort with risk:

   1. Ask stakeholders to rate their tolerance for potential research errors (low, medium, high).

   2. Discuss potential consequences openly and document responses.

2. Create a risk assessment matrix to visualize tolerance clearly.

Prompting questions:

• How comfortable is leadership with research findings from non-researchers driving key decisions?

• What types of errors or biases can your organization afford, and what is completely unacceptable?

• Which areas (finance, regulatory, health) require the strictest oversight, and which can afford some flexibility?

3. Evaluate Existing Research Skills in Your Organization

Understanding the research skills and experience within your organization is essential for deciding how much oversight or training you’ll need to implement.

Steps:

1. Create an inventory of current research skills among non-research stakeholders.

2. Use surveys or interviews to capture their research experience.

3. Categorize teams by experience (High, Medium, Low).

4. Assess the gap between current skills and desired research rigor levels.

Prompting questions:

• Do your product or design teams have formal research training?

• Are there team members regularly conducting interviews, usability tests, or surveys without oversight?

• Which teams consistently produce reliable insights, and which require significant researcher intervention?

Identify the Right Democratization Model for Your Context

Selecting the appropriate democratization model is critical. The right model enables your organization to effectively scale research without sacrificing quality, credibility, or reliability. Using insights gathered from assessing your current state (Step 1) and defining your organization’s research needs and risks (Step 2), follow the guide below to pinpoint exactly which model aligns best with your organization’s unique circumstances.

If your organization has a small research team supporting many product teams:

Read more

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

This is a series on user research democratization — since this is a tough topic, there was way too much for one article. I will be writing this series and posting it over the next weeks and will edit this as I add to the series so you can easily navigate the different parts.

• Part 1: The Complex Landscape of Research Democratization (Free)

• Part 3: Scaling Research Without Sacrificing Rigor (Paid)

• Part 4: Responding to UXR Democratization Issues (Free)

Stop piecing it together. Start leading the work.

The Everything UXR Bundle is for researchers who are tired of duct-taping free templates and second-guessing what good looks like.

You get my complete set of toolkits, templates, and strategy guides. used by teams across Google, Spotify, , to run credible research, influence decisions, and actually grow in your role.

It’s built to save you time, raise your game, and make you the person people turn to—not around.

→ Save 140+ hours a year with ready-to-use templates and frameworks

→ Boost productivity by 40% with tools that cut admin and sharpen your focus

→ Increase research adoption by 50% through clearer, faster, more strategic delivery

Grab the Everything UXR Bundle

The Framework for Responsible Research Democratization

Scaling research while maintaining rigor is not a simple process. Without structure, democratization can result in misleading insights, ethical missteps, and wasted effort. However, when implemented correctly, it empowers teams to make user-centered decisions while ensuring that research retains its credibility and influence.

This framework is designed to help research leaders establish a structured, effective, and scalable democratization model, one that enables non-researchers to contribute to research without compromising quality.

Step 1: Define What Can and Cannot Be Democratized

One of the biggest mistakes in research democratization is assuming that all research methods can (or should) be conducted by non-researchers. That is not the case.

A successful framework begins with clear definitions of what research activities can be democratized and what must remain with trained researchers. This prevents low-quality research from being used in high-stakes decision-making and ensures that non-researchers are only conducting studies that fit their skill set.

Create a Categorization System for Research Methods

Break research activities into four tiers:

1. Fully Democratized – Can be run by non-researchers with minimal oversight.

2. Democratized with Oversight – Can be conducted by non-researchers, but requires a trained researcher’s review.

3. Guided Research – Non-researchers can be involved, but a trained researcher must lead the study.

4. Restricted to Researchers – Must be conducted exclusively by trained researchers.

Create a Decision Framework for Stakeholders

Once research categories are defined, build a decision tree that helps stakeholders determine:

• When they can conduct research independently.

• When they need to partner with a researcher.

• When they need to escalate to a research team.

For example:

• Does this research involve sensitive user data or compliance risks? → If yes, it must be conducted by a trained researcher.

• Is this a usability test for a minor UI update? → If yes, a trained non-researcher can conduct it following a structured template.

• Is this a strategic or generative study exploring unmet needs? → If yes, it must be conducted by a research professional.

Having a clear framework removes ambiguity and prevents research from being misused or diluted.

Step 2: Create Clear Guidelines and Guardrails

Without clear guidelines, research democratization can quickly spiral into inconsistent methods, poor-quality data, and confusion across teams.

1. Develop Standardized Research Protocols

To ensure consistency, create a set of research protocols that all teams must follow. These should include:

1. Usability Testing Guides – Pre-written usability testing scripts, rubrics for evaluating responses, and success metrics.

2. Survey Templates – Guidelines on how to write unbiased survey questions and analyze responses correctly.

3. Participant Recruitment Best Practices – Prevents teams from relying on biased, unrepresentative samples (only interviewing internal employees).

4. Data Storage and Handling Policies – Ensures that participant privacy and legal compliance are followed.

2. Implement Pre-Approved Research Templates

Rather than letting teams design research studies from scratch, provide pre-approved templates that ensure structured, repeatable processes. For example, a usability test template might include:

• Scripted introduction to ensure consistency in test facilitation.

• Pre-written, unbiased tasks for participants.

• A standardized results sheet to ensure that findings are logged consistently.

Templates help prevent ad-hoc, low-quality research from creeping into the organization.

3. Build Research Governance into the Process

• Require all studies to be logged in a central repository before they are conducted.

• Assign a researcher to review methodologies for any study run by non-researchers.

• Create a decision tree for ethical considerations, ensuring that sensitive studies are escalated appropriately.

By creating strong governance from the start, research democratization remains structured, not chaotic.

Step 3: Provide Training and Ongoing Support

Training is not optional in research democratization. It is the foundation that determines whether non-researchers will conduct studies that actually improve decision-making or introduce flawed, misleading insights into the organization.

Without training, democratization does not scale research, it scales bad research. Untrained stakeholders may run usability tests with leading questions, interpret survey data incorrectly, or unknowingly introduce bias into their studies. Worse, they may present their findings with false confidence, leading to major business or product decisions being made on inaccurate or incomplete data.

Many organizations make the mistake of treating research training as a one-time event—a workshop, a few documentation pages, or an online course. But research is a skill that requires reinforcement, practice, and feedback. Even experienced researchers continually refine their craft.

For democratization to be effective, organizations need to establish an ongoing, structured training system that aligns with the level of research responsibilities stakeholders will have.

1. Build a Tiered Training Program

Not every stakeholder needs the same level of research expertise. The goal of training is not to turn product managers or designers into full-fledged researchers, it’s to ensure that they have enough knowledge to conduct certain types of research effectively while knowing when to escalate more complex studies. A tiered approach ensures that training is scalable, relevant, and structured.

Level 1: Research Awareness (Mandatory for All Stakeholders Involved in Research)

This is the foundational level for anyone conducting or relying on research insights. It is designed to ensure that all stakeholders understand the purpose of research, when it is appropriate for them to conduct studies, and when they need to escalate to a trained researcher. Topics covered:

• Bias Awareness and Mitigation – How to recognize and reduce bias in research questions, participant selection, and interpretation of results.

• When to Conduct Research vs. When to Escalate – A clear decision framework for determining whether a study should be owned by a researcher or if it can be conducted by a non-researcher.

• Ethical Considerations in Research – Understanding participant consent, privacy requirements, and ethical issues related to data collection and storage.

• How Research Fits Into the Organization – The role of research in decision-making and how democratized research should feed into the broader research ecosystem.

This training should be a required baseline for anyone involved in research—no exceptions.

Level 2: Basic Research Training (For Those Conducting Tactical Studies)

This level is for stakeholders who will be running their own research studies, such as product managers, designers, or marketers conducting usability tests or small-scale surveys. Topics covered:

• How to Conduct Usability Testing – Structuring usability tests, avoiding leading questions, and synthesizing findings.

• Survey Design Best Practices – Writing unbiased questions, selecting appropriate response formats, and analyzing survey data responsibly.

• Basic Interviewing Skills – When and how to ask open-ended vs. closed-ended questions, active listening techniques, and how to probe deeper without leading.

• How to Synthesize Findings Responsibly – Avoiding cherry-picking data, recognizing patterns, and presenting insights objectively.

At this level, stakeholders should still have oversight from researchers, but they can conduct certain studies independently with structured templates and review processes in place.

Level 3: Advanced Research Training (Optional for Stakeholders Seeking Deeper Expertise)

This level is not required for most democratized research participants but can be beneficial for stakeholders who want to develop more advanced research skills and greater autonomy. Examples of who might pursue this level:

• Senior designers who frequently run complex usability studies.

• Product leaders who want to deeply integrate research into their strategy.

• Marketers conducting ongoing customer insights research.

Topics covered:

• Advanced Interviewing Techniques – Learning how to facilitate in-depth qualitative research, including Jobs-to-Be-Done (JTBD) interviews.

• Behavioral Data Analysis – How to connect qualitative insights with analytics data for a more comprehensive understanding of user behavior.

• Longitudinal and Diary Studies – How to structure longer-term research that tracks user behavior over time.

• How to Lead Research Synthesis and Workshops – Training on how to facilitate research readouts and stakeholder engagement sessions.

Stakeholders at this level may require less oversight for certain research types, but they should still have their work peer-reviewed by professional researchers.

2. Set Up Ongoing Research Mentorship and Coaching

Training is only effective if it is reinforced through practice, feedback, and ongoing support. Organizations that simply provide training sessions but fail to offer continuous coaching often find that:

• Stakeholders forget key research principles over time.

• Poor research practices start creeping back in.

• Teams still struggle with synthesizing and interpreting insights correctly.

A structured mentorship and support system ensures that research remains high quality over time and that non-researchers have access to expert guidance when needed.

1. Office Hours with Researchers

Setting up weekly or bi-weekly office hours allows non-researchers to:

• Get feedback on their research plans before launching a study.

• Ask questions about synthesis and reporting.

• Discuss challenges or uncertainties they’re facing in their research.

This system creates a structured yet flexible way for researchers to provide ongoing guidance without needing to hand-hold every study.

2. Research Coaching Programs

Some organizations may benefit from a formal coaching program, where trained researchers mentor non-researchers through their first few studies. A structured coaching model might look like this:

1. Observation Phase – The non-researcher shadows a researcher conducting a study, taking notes on best practices.

2. Co-Facilitation Phase – The non-researcher conducts part of a study under the guidance of a researcher.

3. Supervised Execution – The non-researcher conducts a full study independently, with a researcher reviewing their work and providing feedback.

4. Independent Research with Oversight – The non-researcher is approved to conduct select studies on their own but still submits research plans and synthesis for review.

This gradual introduction to conducting research ensures that stakeholders build real skills rather than diving in with little preparation.

3. Quality Review Check-Ins

To maintain consistency, all democratized research should be subject to regular quality reviews. This includes:

• Pre-study reviews – A researcher approves study designs before they begin.

• Post-study reviews – Researchers check that findings are synthesized correctly and insights are actionable.

• Quarterly audits – Reviewing all democratized research to identify trends, common mistakes, and areas for additional training.

These regular check-ins act as a safety net, ensuring that non-researchers remain aligned with best practices and that the research function maintains credibility.

Step 4: Establish a Centralized Research Repository

Read more

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

This is a series on user research democratization — since this is a tough topic, there was way too much for one article. I will be writing this series and posting it over the next weeks and will edit this as I add to the series so you can easily navigate the different parts.

• Part 2: A Framework for Responsible Research Democratization (Paid)

• Part 3: Scaling Research Without Sacrificing Rigor (Paid)

• Part 4: Responding to UXR Democratization Issues (Free)

Stop piecing it together. Start leading the work.

The Everything UXR Bundle is for researchers who are tired of duct-taping free templates and second-guessing what good looks like.

You get my complete set of toolkits, templates, and strategy guides. used by teams across Google, Spotify, , to run credible research, influence decisions, and actually grow in your role.

It’s built to save you time, raise your game, and make you the person people turn to.

→ Save 140+ hours a year with ready-to-use templates and frameworks

→ Boost productivity by 40% with tools that cut admin and sharpen your focus

→ Increase research adoption by 50% through clearer, faster, more strategic delivery

Grab the Everything UXR Bundle

The Complex Landscape of Research Democratization

User research is at an inflection point. Demand for research insights is growing exponentially, but research teams remain small. This imbalance forces organizations to explore democratization, enabling non-researchers to conduct research.

At its best, democratization scales insights, increases research buy-in, and enhances customer-centricity across an organization. At its worst, it leads to poor-quality research, biased data, and diluted research rigor. For researchers, democratization can feel like a double-edged sword: it helps meet demand, but it can also erode the depth and expertise of the field if done poorly.

The Growing Demand for Research Across Organizations

User research has expanded beyond the traditional UX and product development lifecycle. Today, research is needed for:

• Product strategy – Understanding user needs before features are even conceptualized.

• Marketing validation – Ensuring messaging aligns with real customer pain points.

• Customer support optimization – Identifying friction points that lead to high support ticket volumes.

• Business decision-making – Using research to inform investment, expansion, and prioritization.

As research extends into these diverse functions, the traditional researcher-to-team ratio has become unsustainable. Many researchers find themselves spread too thin, juggling too many projects with too few resources. In some cases, researchers must reject critical research requests simply because they don’t have the bandwidth. This leads to frustration among stakeholders who feel they lack access to the insights they need.

Additionally, many researchers face the dilemma of either being a solo UXR or small team of researchers trying to take care of multiple teams (I was once working across 10 teams), foundational processes, ops, and maintaining a research framework.

However, research teams haven’t scaled at the same rate as demand. According to Maze’s 2023 Continuous Research Report, 64% of companies now have a democratized research culture to cope with increasing research requests. Yet, research bandwidth remains a major challenge:

This imbalance is what drives the need for democratization but, without structure, it can create chaos rather than efficiency.

The Growing Desire from Non-Researchers to Engage in Research

It’s not just research teams feeling the pressure; stakeholders themselves are becoming more eager to engage with user insights. Product managers, designers, and even marketing teams want direct access to users. They see the value in speaking with customers, testing hypotheses, and gathering feedback.

This shift is largely positive. When more people across an organization have a user-centric mindset, better decisions are made. However, without structure, this enthusiasm can lead to problems:

• Biased research – Without training, non-researchers may unconsciously lead participants toward desired answers.

• Unethical practices – Mishandling of participant consent, privacy, and data security.

• Poor research methodologies – Relying on convenience sampling, asking leading questions, or misinterpreting results.

A 2023 industry survey found that 73% of UX researchers reported spending significant time correcting or guiding poorly conducted research by non-researchers. This often happens because non-researchers unknowingly introduce confirmation bias, leading questions, and flawed synthesis.

The Risks and Rewards of Democratizing Research

Like many trends in UX and product development, democratization is neither inherently good nor bad, it depends entirely on how it is implemented.

Potential Benefits of Democratization:

1. Scalability – More research gets done without overburdening researchers.

2. Stakeholder Buy-in – Teams feel more ownership of insights, increasing the likelihood of acting on findings.

3. Faster Decision-Making – Teams don’t have to wait weeks or months for research results.

4. User-Centric Culture – More teams engaging with research can help embed user thinking into company culture.

Potential Risks of Democratization:

1. Compromised Research Quality – Without structure, teams may conduct poorly designed studies, leading to misleading conclusions.

2. Research Fragmentation – Multiple teams running isolated studies without alignment, leading to duplicated work and inconsistent data.

3. Undermining the Value of Research – If anyone can “do research,” the expertise of trained researchers may be devalued.

4. Ethical Concerns – Improper consent collection, storing sensitive data insecurely, or asking questions that could cause harm.

In a survey done by User Interviews, participants rated their feelings about democratization on a scale from 1 (very concerned/dissatisfied) to 5 (very excited/satisfied). On average, participants rated their feelings a 2.95 out of 5—just below neutral. Sentiment toward democratization was lowest among UXRs, who gave an average rating of 2.84.

The key to democratization is finding the right balance by enabling access to research while ensuring rigor and ethical responsibility.

A Personal Reflection

I’ll never forget the first time I experienced the impact of ungoverned research democratization. At one company, a well-intentioned product manager decided to run their own customer interviews. They were frustrated that the research team couldn’t prioritize their request, so they took matters into their own hands.

On the surface, it seemed great, my stakeholders were taking initiative. But when they presented their findings, I quickly realized the data was riddled with issues:

• They had only interviewed three participants, all of whom were personal contacts.

• The questions were leading, designed to confirm the PM’s assumptions rather than uncover real insights.

• They had misinterpreted responses, turning neutral feedback into positive validation.

As a result, they advocated for a product change that was completely misaligned with actual user needs. It wasn’t until months later, after launch failure, that the team realized their mistake.

This experience solidified my belief that democratization without structure is dangerous. However, the opposite extreme—gatekeeping research—also isn’t the answer. If research teams hoard insights, they risk becoming bottlenecks and alienating stakeholders.

Defining Democratization in a Research Context

At its simplest, research democratization is the process of making research more accessible beyond the UX research team. It allows product managers, designers, marketers, customer support teams, and even engineers to engage with research, conduct studies, and apply insights. But accessibility doesn’t mean a free-for-all, it requires structure, training, and well-defined boundaries.

Nielsen Norman Group has called this ‘Democratization 2.0’ where research is distributed but carefully guided through training, templates, governance, and tiered research access.

For democratization to work, it must be intentional. It’s not about handing research tools to anyone who wants them. It’s about equipping the right people with the right skills to conduct the right kinds of research under the right conditions.

What Democratization Looks Like in Practice

A well-structured approach to research democratization includes:

• Training and education – Non-researchers need to be taught not just how to conduct research but how to recognize its limitations, avoid bias, and synthesize insights properly.

• Clear guidelines on who can conduct what research – Not all research should be democratized. Simple usability tests? Yes. Complex generative studies? No.

• Templates and frameworks – Providing standardized interview guides, usability testing scripts, and survey templates reduces the likelihood of poorly designed studies.

• A review and oversight process – Researchers should act as coaches and advisors, ensuring studies are structured correctly and that findings are interpreted responsibly.

• A centralized research repository – Without a system for documenting and sharing insights, research efforts become fragmented, leading to duplication and inconsistencies.

At one company, we introduced a tiered democratization system to balance access with quality control:

• Product managers and designers were trained to run usability tests using a structured process. They had to submit a research plan before running any sessions, and a researcher reviewed their findings before they were shared.

• Marketing and customer success teams were given access to pre-approved survey templates but needed a researcher’s sign-off before launching a survey.

• All generative and exploratory research remained the responsibility of trained researchers, ensuring foundational insights were handled by those with the expertise to do them properly.

This system allowed the research team to focus on high-impact projects while enabling stakeholders to conduct low-risk research on their own. It wasn’t about giving away research, it was about scaling it responsibly.

Common Misconceptions About Democratization

Much of the resistance to research democratization comes from misunderstanding what it actually entails. Let’s break down the biggest misconceptions.

Misconception #1: “Democratization means replacing researchers.”

One of the most common fears among researchers is that democratization is a thinly veiled cost-cutting measure, a way for companies to avoid hiring or retaining research talent. The reality is, if democratization is implemented as a replacement for researchers, it will fail. Research quality will drop, teams will make decisions based on incomplete or biased findings, and the organization will ultimately feel the consequences in lost revenue, increased churn, or misguided product investments.

Democratization should extend the impact of research, not eliminate the need for researchers. When stakeholders conduct basic research, it frees up researchers to focus on deeper, more complex studies—the kind that require a trained researcher’s skill set.

A responsible approach to democratization: A product team struggling with usability issues trained designers to run usability tests using a pre-approved script. However, researchers still guided the study setup, reviewed findings, and ensured insights were properly synthesized. This allowed research to happen faster while maintaining quality.

A dangerous approach to democratization: An organization decided researchers weren’t needed because product managers could “just talk to users.” Without training or structure, these conversations were riddled with leading questions, incorrect assumptions, and cherry-picked data that confirmed pre-existing biases. The result? A product launch based on faulty insights, leading to poor adoption and wasted development time.

Misconception #2: “Anyone can do research well.”

It’s tempting to think that research is just about asking people questions. After all, everyone talks to users in some capacity, doesn’t that mean anyone can conduct research? Not exactly. Good research requires more than just talking to customers. It involves:

• Knowing how to frame a study to uncover real insights, not just confirm assumptions.

• Asking the right kinds of questions—ones that don’t lead or bias participants.

• Understanding how to analyze responses in a way that reflects true patterns, not just individual anecdotes.

• Recognizing the limits of what a given method can tell you.

I once worked with a marketing team that wanted to “validate” a new pricing strategy by running a customer survey. When I reviewed their draft, I found that nearly every question was leading: “Would you be excited to see this new lower price?” “How much better is this compared to what we had before?” The survey was structured in a way that guaranteed positive responses, and they nearly made a major pricing change based on biased data.

The solution isn’t to ban stakeholders from doing research, it’s to train them on how to do it properly and put safeguards in place.

A balanced approach: Educate non-researchers about common biases, provide pre-approved templates, and have researchers review research plans before launch.

A risky approach: Assume that because someone understands their product, they automatically understand how to conduct valid research.

The Spectrum of Research Democratization

Not all organizations take the same approach to democratization. There’s a spectrum, ranging from tightly controlled research to fully open, self-directed studies.

1. No Democratization:

   1. Research is conducted solely by dedicated UX researchers.

   2. Insights are centralized but often bottlenecked by research bandwidth.

   3. Teams rely entirely on the research team for user insights.

2. Partial Democratization:

   1. Non-researchers conduct some research but within a structured framework.

   2. Usability tests, surveys, and small-scale studies can be run by trained stakeholders.

   3. Researchers maintain oversight and provide guidance.

3. Full Democratization:

   1. Research is open to everyone with minimal oversight.

   2. Teams run studies independently, without researcher involvement.

   3. Insights are often fragmented, with no centralized knowledge base.

   4. Without strong governance, this approach usually leads to unreliable data and misalignment across teams.

Most organizations benefit from structured, partial democratization. It allows research to scale while maintaining rigor.

The Case for Democratizing Research

Democratizing research isn’t just about efficiency, it’s about survival. The landscape of product development moves at an unforgiving pace. Decisions are being made constantly, whether research has informed them or not. Research teams, however, rarely scale at the same speed as their organizations. While demand for research has skyrocketed, the number of dedicated researchers often remains stagnant.

This gap has forced research leaders to rethink traditional models. If a research team can’t directly support every initiative, how can research still be embedded in decision-making across an organization? The answer, for many, has been some form of research democratization—empowering non-researchers with the tools, training, and guardrails to conduct research on their own.

Done correctly, this creates a system where research isn’t just something that happens within the confines of a UX research team. It becomes part of how the organization operates. It allows for more user-centered decisions at scale, better alignment across teams, and an overall stronger connection to customer needs.

But before getting into how to democratize research effectively, it’s important to understand why this shift is happening and what’s at stake.

The Need for Scale

Most research teams face an impossible task: meeting an increasing demand for research with limited resources.

• A single researcher might be responsible for supporting five to ten product teams, each with multiple ongoing projects.

• Companies are making huge strategic bets on product roadmaps, go-to-market strategies, and design decisions, but often without the research capacity to inform them properly.

• Many research teams spend their time prioritizing projects rather than conducting research, meaning valuable but lower-priority questions go unanswered.

I’ve seen this firsthand. In one company, I was the only researcher supporting seven product teams. There were simply not enough hours in the day to conduct research on every feature, design iteration, or customer pain point that needed attention. No matter how well we prioritized, important questions were left unanswered.

At the same time, my colleagues—product managers, designers, and marketers—were desperate for insights. They wanted to understand users, but without access to a researcher, they were forced to rely on assumptions or whatever anecdotal evidence they could gather on their own.

This is the core problem democratization attempts to solve. If every research question has to go through an overburdened research team, insights become a bottleneck. But if teams are enabled to conduct certain types of research themselves, more questions get answered, and research scales alongside the company.

The key is to ensure this doesn’t lead to a free-for-all where bad research does more harm than good.

The Benefit of Increased Empathy

One of the most overlooked benefits of democratization is how it transforms the way teams think about users.

Research isn’t just about gathering insights; it’s about changing perspectives. When product managers, designers, or marketers engage directly with users, it fundamentally shifts how they approach their work. They start making decisions based on what they’ve heard and seen, not just what they assume.

• A designer who watches users struggle through an onboarding flow will never unsee those frustrations. Instead of relying on second-hand reports, they will instinctively advocate for a better experience.

• A product manager who sits in on user interviews stops thinking about features in isolation and starts seeing the bigger picture—the messy, real-world contexts in which customers actually interact with their product.

• A marketing team that tests messaging directly with users will refine their approach based on evidence, not just gut feeling.

I once worked with a product manager who, before engaging in research, had a firm belief that customers wanted more customization options. He pushed hard for this, confident that flexibility was the key to retention. But after sitting in on just three customer interviews, he completely changed his mind. Customers didn’t want more customization; they were overwhelmed by the complexity of the product and wanted simpler, more guided experiences.

That shift in thinking didn’t come from a research report, it came from direct engagement with users. That’s the power of democratization.

When more people in an organization interact with customers, it builds a culture of customer empathy, where decisions are made with a deeper understanding of real user needs.

However, this benefit only materializes when teams are engaging with research in the right way. Without structure, direct engagement can just as easily reinforce biases rather than challenge them. That’s why a thoughtful approach to democratization is critical.

Faster Decision-Making

Speed matters. In fast-moving companies, decisions are made quickly, often without research, simply because waiting weeks for insights isn’t an option.

• Product teams are pressured to ship. They can’t always afford to wait for a dedicated researcher to become available.

• Executives expect quick answers. Delays in research can sometimes mean the difference between launching a feature and missing a market opportunity.

• Customer expectations are evolving constantly. The faster a company can learn, the faster it can adapt.

Democratization, when done well, allows teams to validate assumptions quickly, reducing the risk of making costly missteps. For example:

• A design team that has been trained to conduct usability testing can validate whether a new checkout flow is intuitive in days, not weeks.

• A product team with access to survey tools can gather user sentiment data before launching a feature, ensuring they’re not blindsided by poor reception.

• A marketing team can test messaging with real users before committing to a campaign, avoiding misalignment with customer expectations.

By giving teams the ability to get user feedback quickly, democratization reduces reliance on guesswork. However, the key here is ensuring that teams know when to move fast and when to slow down. Not all research can or should be done quickly. Usability tests and surveys? These can often be done efficiently. Generative research or behavioral studies? These require more time and expertise.

Without a clear framework for what research should be democratized and what should remain within a dedicated research team, organizations risk prioritizing speed over accuracy—which can lead to even bigger problems down the road.

The Risks and Challenges of Research Democratization

Research democratization, if structured well, can expand an organization’s ability to incorporate user insights into decision-making. But when done poorly—or without enough oversight—it can introduce serious risks that undermine the credibility of research altogether.

Scaling research across non-researchers means reducing barriers to participation, but without guardrails, it also increases the likelihood of biased findings, ethical missteps, and fragmented efforts that don’t drive meaningful change.

Quality Control Issues

One of the most immediate risks of democratization is a decline in research quality. When individuals without formal training in research conduct studies, common methodological mistakes can creep in, sometimes with significant consequences for product and business decisions.

In a study of research democratization practices, 73% of UX researchers reported spending significant time correcting or guiding poorly conducted research by non-researchers. This often happens because non-researchers unknowingly introduce confirmation bias, leading questions, and flawed synthesis. One research leader shared that democratization without guardrails turned research into a ‘game of telephone’—insights became increasingly distorted as non-researchers misinterpreted findings, leading to misguided product decisions.

1. Risks of Biased Research, Leading Questions, and Poor Methodology

Non-researchers often approach research with the best of intentions, but without training, they can unintentionally introduce bias at every stage of the process:

• Confirmation bias – Asking questions designed to validate existing assumptions rather than uncovering new insights.

• Leading questions – Steering users toward certain responses rather than letting them express their true thoughts.

• Poor sampling – Interviewing a narrow or unrepresentative set of users, leading to skewed conclusions.

• Flawed synthesis – Cherry-picking insights that align with stakeholder preferences rather than accurately reflecting patterns in the data.

At one company, a product team wanted to “validate” a new feature idea. Since the research team was at capacity, a product manager ran a quick round of interviews. But instead of an open-ended discovery study, they asked leading questions like, “Wouldn’t you find this feature helpful?” Predictably, most users responded positively.

The team took this as a green light to move forward, investing months of development resources. After launch, usage was almost nonexistent—because while users agreed in interviews, their actual behavior told a different story. The issue wasn’t the idea itself, but the flawed research approach that had given them false confidence.

2. The Danger of Superficial or Cherry-Picked Insights

Without proper synthesis, research findings can become over-simplified, misinterpreted, or cherry-picked to support pre-existing ideas. Teams conducting their own research may:

• Over-rely on a few strong opinions, mistaking them for broad trends.

• Ignore conflicting feedback that doesn’t align with their preferred narrative.

• Mistake usability issues for lack of user interest, discarding features too quickly.

A marketing team wanted to refine its messaging and conducted a quick user survey. Most responses were positive, leading them to assume their messaging was strong. But when a researcher later reviewed the data, they found that negative feedback had been dismissed as “outliers.”

In reality, those “outliers” represented a critical segment of potential customers who found the messaging unclear. Because this nuance had been ignored, the company missed an opportunity to improve conversion rates.

Ethical Concerns

User research involves handling people’s personal data, stories, and behaviors. When research is democratized, it’s critical to ensure that ethical best practices aren’t compromised.

1. Consent, Privacy, and Proper Handling of Sensitive Data

When non-researchers conduct studies, they may not fully understand data protection laws or consent protocols. Common mistakes include:

• Failing to obtain proper consent before recording or storing user data.

• Not anonymizing sensitive information, increasing the risk of privacy violations.

• Misusing user data beyond the scope of consent, which can lead to legal repercussions.

A designer I worked with ran an unmoderated usability test using a third-party tool but forgot to include a consent disclaimer. Participants were unaware their sessions were being recorded, violating privacy policies. This led to a compliance issue that required removing all collected data, wasting weeks of work.

2. The Risk of Manipulating Research to Confirm Pre-Existing Biases

Research can be weaponized. When stakeholders conduct their own studies, there’s a risk that they will design the research to confirm what they already want to believe. This can lead to:

• Over-reliance on supportive data while ignoring conflicting insights.

• Framing research questions in ways that guarantee a preferred outcome.

• Misrepresenting insights to push a particular agenda.

An executive wanted to push a new subscription model and asked for research to support the decision. Instead of conducting an unbiased study, they only surveyed customers who had previously expressed interest in subscriptions. The results? A misleadingly high approval rate that didn’t reflect the broader customer base.

When the new model launched, churn increased dramatically because the real majority of customers had never been considered in the research.

Undermining the Value of Professional Research

One of the most contentious risks of research democratization is the fear that it diminishes the role and expertise of trained researchers. As more non-researchers take on research tasks, there’s a real concern that leadership will begin to deprioritize the need for dedicated research professionals altogether.

When organizations assume that “anyone can do research,” they often fail to recognize the depth of expertise required to conduct meaningful, unbiased, and methodologically sound studies. This can lead to fewer dedicated research hires, underfunded research teams, and a loss of credibility for research as a discipline.

But this problem doesn’t emerge overnight. It often starts subtly by shifting responsibilities away from researchers and making research a distributed, secondary task rather than a core business function. If this shift goes unchallenged, researchers can quickly find themselves fighting for relevance rather than driving strategic impact.

How Democratization Can Devalue Research Roles

Democratization, when unchecked, can lead to a misunderstanding of research as a profession. Instead of being seen as a specialized discipline requiring training, rigor, and experience, research is sometimes reduced to a simple task that anyone with access to a survey tool or a scheduling link can handle. There are a few ways this devaluation takes shape:

1. The Erosion of Research Credibility

When non-researchers conduct studies without proper training, they often produce flawed, biased, or misleading insights. These insights, if used to inform decisions, can lead to failed product launches, wasted development resources, or misaligned marketing strategies.

However, when these failures happen, the blame doesn’t always fall where it should. Instead of acknowledging that the methodology was flawed, teams may conclude that research itself isn’t valuable or that it doesn’t lead to actionable insights.

Over time, this weakens the perception of research within an organization. Instead of being seen as a critical function, research becomes an optional, nice-to-have activity that doesn’t always justify investment.

At one company, product managers were given the freedom to conduct their own research. Over time, they ran dozens of studies, but because they lacked training, their insights were inconsistent, biased, and often contradicted each other.

Executives began questioning the value of research altogether. “Why are we spending time on this if every study seems to say something different?” they asked. Instead of realizing that the issue was the lack of research rigor, they assumed that research itself wasn’t producing useful outcomes.

2. The Shift from Research as a Discipline to Research as an Admin Task

When democratization isn’t structured properly, research risks being reduced to a tactical, administrative function rather than a strategic discipline.

Instead of being valued for their critical thinking, synthesis, and ability to uncover deep insights, researchers may find themselves relegated to checking survey drafts, reviewing discussion guides, or approving stakeholder-run studies. This shift has serious long-term consequences:

• Researchers lose their influence in shaping business and product strategy.

• The organization stops seeing research as a driver of innovation and only values it for usability testing and validation.

• Research teams become service providers rather than thought leaders.

A UX research team at a large company started a democratization initiative that allowed product managers and designers to run usability tests. Over time, stakeholders became accustomed to doing their own research and started relying less on the research team.

Eventually, leadership began questioning the need for a dedicated research function at all. “If product teams can do their own research, why do we need a full research team?”

Instead of scaling research, democratization led to the gradual defunding of the research department, reducing it to a small oversight function rather than a core driver of decision-making.

3. The Budget and Hiring Freeze Effect

One of the most polarizing debates in research democratization is whether it threatens the job security of UX researchers. In a 2023 survey, 7% of researchers explicitly linked democratization to layoffs or role reductions. Some companies, after implementing democratization, froze research hiring or shifted research into hybrid roles rather than dedicated teams. However, research leaders argue that structured democratization should enhance, not replace, UX researchers. The key distinction is ensuring researchers own complex studies while enabling non-researchers to contribute within predefined boundaries.

When leadership perceives that research is happening without dedicated researchers, they may start questioning the need to invest in research at all. This can result in:

• Reduced budgets for research tools, participant recruitment, and training.

• Hiring freezes for research roles, even when the demand for insights remains high.

• Reallocation of research responsibilities to non-researchers, leading to burnout and ineffective studies.

This often happens gradually. At first, democratization is seen as a way to scale research—but without careful structuring, it can quickly lead to justification for cost-cutting.

At one startup, researchers trained designers to conduct usability tests. Initially, this helped the research team focus on generative studies. However, when budget season rolled around, leadership pointed to the success of democratization as a reason not to hire additional researchers.

Within a year, the research team was stretched even thinner, and designers—who were supposed to be running only tactical usability tests—were now expected to handle all product research. The result? A research culture built on speed, not depth, with major gaps in insight quality.

How to Protect the Value of Research While Scaling Access

If democratization is necessary, researchers must take an active role in shaping its implementation rather than passively accepting it. Here’s how to do that:

1. Define the boundaries of democratized research

   1. Be clear about what types of research can and cannot be democratized.

   2. Ensure that high-risk, high-impact research remains with trained researchers.

2. Establish research standards and oversight

   1. Create a research framework with clear guidelines for methodology, synthesis, and reporting.

   2. Require peer reviews and quality checks before insights are shared.

3. Position research as a strategic partner, not just a service

   1. Proactively contribute to decision-making conversations, not just research execution.

   2. Show how research can drive innovation, reduce business risk, and uncover opportunities that teams hadn’t considered.

4. Continuously advocate for research expertise

   1. Educate leadership on the depth and complexity of research.

   2. Track and report the impact of research on business outcomes, so it’s clear why dedicated researchers are still essential.

When and How to Democratize Research Responsibly

Democratizing research isn’t an all-or-nothing decision. Done well, it can scale research efforts, integrate user insights across an organization, and build a stronger culture of customer empathy. Done poorly, it can introduce bias, lead to poor decision-making, and undermine the credibility of research as a function.

The key to responsible democratization isn’t just who conducts research, but how, when, and under what conditions. This section breaks down the circumstances in which democratization makes sense, when it doesn’t, and how to ensure that research remains rigorous even as it becomes more widely distributed.

When Should Research Be Democratized?

Democratization works best when it’s filling a gap, not replacing expertise. In the right contexts, it can help teams make better, faster, and more user-centered decisions while allowing researchers to focus on high-value work. Here are the conditions that make democratization beneficial:

1. When Research Demand Exceeds Researcher Capacity

Research teams—especially in growing organizations—are often stretched thin. The number of product teams, marketing initiatives, and business strategies that could benefit from research far outweighs the available researcher capacity. In these situations, democratization allows research to scale beyond the limitations of a small team.

However, this does not mean handing over all research responsibilities to non-researchers. Instead, it means creating a system where smaller, tactical studies can be owned by trained stakeholders, freeing researchers to focus on more complex, high-impact work. Without this structure, research functions become bottlenecks, delaying projects and forcing teams to make decisions based on assumptions rather than data.

To manage this well, researchers should define the types of studies stakeholders can conduct and establish guidelines for when their involvement is required. This ensures that research demand is met without compromising quality or overwhelming the research team.

2. When Teams Need Quick, Low-Risk Insights

There are times when teams need immediate feedback on relatively small decisions—such as refining copy on a landing page, testing a minor UI change, or gauging user reactions to a new feature layout. These types of research questions are not deeply exploratory and do not require advanced methodologies, making them ideal for democratization.

But even these quick-turnaround studies need guardrails to ensure findings are still meaningful. Without structure, teams may conduct rushed, poorly designed research that introduces more noise than clarity. For democratization to work in these cases, organizations need:

• Pre-approved templates and research guides to ensure consistency.

• Baseline training on research bias and question framing to avoid leading questions or faulty assumptions.

• Access to a repository of past research so that teams don’t conduct unnecessary studies when existing data already holds the answer.

By putting these supports in place, teams can run research without reinventing the wheel or making common mistakes that undermine their findings.

3. When Non-Researchers Are Trained and Supported

One of the biggest mistakes organizations make with democratization is assuming that anyone can do research effectively without training. In reality, even seemingly simple methods—such as usability testing or surveys—can introduce bias or misinterpretation when not handled correctly.

For democratization to succeed, non-researchers must be properly trained in research fundamentals. This doesn’t mean turning them into full-fledged researchers, but rather ensuring they have enough knowledge to avoid common mistakes and recognize when they need additional support. Training should include:

• How to ask unbiased questions and avoid leading participants.

• How to recruit representative samples rather than relying on convenience sampling.

• How to synthesize findings in a way that reflects patterns rather than isolated opinions.

• How to understand ethical considerations, such as participant consent and data handling.

Beyond training, ongoing support is necessary. Research should not be a one-time training session that leaves stakeholders on their own. Researchers should act as mentors, reviewing research plans, helping synthesize findings, and ensuring that non-researchers have the support they need to conduct meaningful studies.

4. When Research Rigor is Maintained Through Structured Oversight

Democratization should never mean unstructured or uncontrolled research. While it allows for more people to participate in research, it should still operate within a defined system that ensures research quality remains high. This requires clear oversight mechanisms, including:

• A standardized research review process where trained researchers sign off on study designs before they are executed.

• A centralized research repository where all findings are logged and cross-referenced to prevent duplication and inconsistencies.

• Regular research audits to evaluate the quality of democratized studies and refine processes over time.

Without these structures, research can become fragmented, inconsistent, and difficult to trust—leading to decisions being made based on unreliable data.

When Should Research NOT Be Democratized?

Just as there are times when democratization is beneficial, there are also clear situations where research should remain exclusively within the domain of trained researchers. These tend to be higher-risk studies where poor execution can have serious consequences.

1. When the Study Requires Advanced Methodologies

Some research methods are simply too complex to be handled by non-researchers. These include:

• Generative research that explores unmet needs and uncovers new opportunities.

• Behavioral research that requires deep observation over time.

• Mixed-method studies that involve advanced synthesis across qualitative and quantitative data.

These methods require expertise in study design, recruitment, analysis, and synthesis to ensure findings are valid, reliable, and actionable. Handing them over to non-researchers can lead to inaccurate conclusions that derail business strategies.

2. When Biases Could Significantly Distort Findings

All research contains some level of bias, but certain situations make it especially difficult to remove. If the person conducting the research has a vested interest in the outcome, there is a high risk of unintentional—or even deliberate—bias shaping the results.

For example, if a product manager is testing their own feature, they may subconsciously lead users toward positive feedback or ignore negative comments that challenge their assumptions.

In cases like these, research should be handled by an independent researcher who can approach the study with neutrality and objectivity.

3. When Ethical or Privacy Concerns Exist

Studies that involve sensitive topics, vulnerable populations, or legally protected data require a high level of ethical oversight. If non-researchers are not trained in research ethics, they may unknowingly:

• Fail to obtain proper consent before recording user data.

• Collect and store sensitive data in ways that violate privacy regulations.

• Ask questions that unintentionally cause harm or distress to participants.

For any study that involves healthcare, finance, children, or legally protected information, research should be conducted only by trained professionals who understand compliance, consent, and ethical risk mitigation.

Scaling Research Without Losing Rigor

Research democratization is a reality for many organizations, and it’s clear that it is not inherently good or bad—it depends entirely on how it is executed. When structured effectively, democratization enables faster, more user-informed decision-making without sacrificing research integrity. However, without proper governance, it risks lowering research quality, fragmenting insights, and reducing the perceived value of dedicated research teams.

The key takeaway from this first part of the series is this: Democratization is not an all-or-nothing approach.Organizations that find success with it strike a balance between empowerment and oversight—providing stakeholders with the tools and training they need while ensuring researchers maintain quality control.

In the next part of this series, we’ll explore specific frameworks and methodologies that enable responsible democratization, including:

1. A framework for responsible research democratization

2. Scaling research without losing rigor

3. Responding to democratization issues

Stay tuned, and if you want to ensure you don’t miss the next part of the series, subscribe for updates!

Subscribe now

Stop piecing it together. Start leading the work.

The Everything UXR Bundle is for researchers who are tired of duct-taping free templates and second-guessing what good looks like.

You get my complete set of toolkits, templates, and strategy guides. used by teams across Google, Spotify, , to run credible research, influence decisions, and actually grow in your role.

It’s built to save you time, raise your game, and make you the person people turn to.

→ Save 140+ hours a year with ready-to-use templates and frameworks

→ Boost productivity by 40% with tools that cut admin and sharpen your focus

→ Increase research adoption by 50% through clearer, faster, more strategic delivery

Grab the Everything UXR Bundle

Stay curious,

Nikki

If you want to see everything I post, subscribe below!

Subscribe now

Read more

If you want to see everything I post, subscribe below!

Subscribe now

Hi there, curious human!

You’ve gathered insights. You’ve compiled data. And now, you’re staring at it all, wondering where to begin. You’ve got so much information but feel like you’re swimming in quicksand. Every choice feels monumental, and the fear of missing something critical keeps you stuck.

Sound familiar? You’re not alone.

This is analysis paralysis, and it’s one of the most frustrating challenges we face as researchers. But here’s the good news: breaking free is not only possible—it’s simple, with the right tools. Today, I’m going to share a step-by-step guide to help you cut through the noise, make confident decisions, and transform your insights into action.

By the end of this article, you’ll have a clear roadmap to turn data into decisions starting today. Ready? Let’s dive in.

Why analysis paralysis happens

Before jumping into solutions, let’s acknowledge the root causes of analysis paralysis. When you understand why it happens, it’s easier to break free.

• You’ve gathered a mountain of data, and every piece feels essential. How do you decide what to focus on without leaving something important behind?

• What if you prioritize the wrong insight? What if your recommendations miss the mark?

• You want your deliverable to be flawless, but perfection is the enemy of progress.

• You’re juggling multiple (and sometimes conflicting) stakeholder needs, unsure of which ones take precedence.

It’s important to recognize that analysis paralysis doesn’t mean you’re bad at your job. In fact, it often happens because you care deeply about delivering high-quality work. But staying stuck doesn’t help you, your stakeholders, or your users. Let’s fix this.

Step 1: Identify your North Star

When you’re drowning in data, you need a compass—a guiding light that helps you navigate the chaos and focus your energy. That compass is your North Star. It’s the single most important goal your research should address. The North Star provides direction, helps you filter out distractions, and ensures your insights align with what your stakeholders truly need.

But finding your North Star isn’t always straightforward. It requires understanding stakeholder priorities, aligning with business objectives, and sometimes challenging vague or conflicting goals.

Why your North Star matters

Without a North Star, your research efforts risk becoming scattered and unfocused. Imagine working on a project with five equally “important” areas of feedback:

1. Users are struggling with onboarding

2. The checkout process is clunky

3. Product recommendations don’t feel personalized

4. The search function needs improvement

5. The mobile app experience is inconsistent

Each of these areas could lead to meaningful improvements. But attempting to tackle all of them at once will dilute your efforts and overwhelm stakeholders with too much information.

The North Star allows you to:

• Prioritize effectively: Instead of spreading yourself thin, you focus on the issue that delivers the highest impact.

• Communicate clearly: Stakeholders know exactly what your research is solving and how it connects to their goals.

• Achieve tangible results: Concentrated efforts are more likely to drive measurable outcomes.

For instance, if the checkout process is the primary reason for lost revenue, your North Star might be: “Reduce cart abandonment by simplifying the payment experience.” Everything else takes a backseat.

How to find your North Star

Finding your North Star involves collaboration, curiosity, and often a bit of digging. Here are the steps to uncover it:

Start with stakeholder conversations

Your North Star should reflect the priorities of your stakeholders—whether that’s your product team, business leaders, or clients. Start by asking questions to understand their goals:

• What’s the biggest challenge you’re trying to solve?

• If this research could answer one question, what would it be?

• What does success look like for you?

• What decision are you hoping to make with this research?

Example conversation:

You’re working on an e-commerce project, and your stakeholder says, “We need to improve the customer experience.” That’s too broad to be actionable. You might ask:

• “What part of the customer experience is causing the most frustration?”

• “What metrics do you want to see improve?”

• “Where do you see the biggest opportunity for growth?”

After discussion, the stakeholder reveals that cart abandonment is their biggest concern. Further exploration shows that unclear payment instructions are the main culprit. Your North Star becomes: “Simplify the payment process to reduce cart abandonment.”

Use data to evaluate and focus

Stakeholders often have assumptions about what matters most, but data can provide clarity. Review your research findings and analytics to identify trends and pain points:

• Which issues affect the largest number of users?

Look for patterns in user feedback, surveys, or analytics.

• Which problems have the highest impact on business goals?

For example, a friction point in the checkout process may directly affect revenue, making it a higher priority than a minor UX tweak.

• What insights are supported by the strongest evidence?

Prioritize areas where your data is reliable and actionable.

Example:

In usability testing, you notice 60% of participants struggle with the payment screen, and analytics show a 40% cart abandonment rate at the same step. This aligns with the stakeholder’s goal of reducing abandonment, solidifying your North Star.

Simplify and narrow down

A good North Star is specific and actionable. It should clearly define what you’re focusing on and why. Avoid vague or overly broad goals.

Compare these two examples:

• Vague: “Improve the user experience.”

• Clear: “Simplify the payment process to reduce cart abandonment.”

The second version provides focus and connects directly to stakeholder goals.

Examples of North Star goals

To help you better understand how to craft a strong North Star, here are examples across different contexts:

E-Commerce:

• North Star: “Reduce cart abandonment by simplifying the checkout process.”

• Why: Cart abandonment is directly tied to lost revenue, and the checkout process has clear friction points.

SaaS product:

• North Star: “Increase activation rates by improving the onboarding flow.”

• Why: A smoother onboarding experience ensures more users adopt the product, leading to better retention.

Mobile app:

• North Star: “Enhance usability for key workflows on small screens.”

• Why: Mobile users are dropping off due to poor navigation, impacting engagement metrics.

Internal tool:

• North Star: “Improve task completion speed by optimizing the search function.”

• Why: Employees spend excessive time searching for information, reducing productivity.

Common challenges

Sometimes, finding your North Star isn’t as straightforward as it sounds. Here are a few common challenges and tips to tackle them:

Challenge: Stakeholders give vague or conflicting goals.

• Solution: Ask clarifying questions to dig deeper. Use data to help narrow the focus.

Challenge: Multiple priorities seem equally important.

• Solution: Use frameworks like RICE (discussed in Step 2) to rank potential goals based on impact, reach, and effort.

Challenge: The North Star changes during the project.

• Solution: Be flexible but transparent. Communicate changes to stakeholders and adjust your approach accordingly.

Step 2: Prioritize using a framework

Once you’ve identified your North Star, the next challenge is deciding where to focus your efforts. Not all insights are created equal, and without a system for prioritizing them, you risk wasting time on low-impact areas or spreading yourself too thin. A prioritization framework gives you a structured way to evaluate and rank your insights, ensuring you’re working on the most valuable tasks first.

Why prioritization matters

You’ve conducted usability testing for a product and identified 10 different issues. They range from minor visual inconsistencies to major usability roadblocks. Without a clear prioritization method, you might:

• Spend too much time on low-impact changes.

• Overwhelm stakeholders with a long list of recommendations.

• Fail to address the most critical pain points, which diminishes the overall impact of your research.

Prioritization helps you focus on the areas that:

• Directly support your North Star.

• Deliver the greatest value to users and the business.

• Align with available time and resources.

By prioritizing effectively, you can work smarter, not harder, and ensure your efforts lead to measurable outcomes.

How to prioritize insights

There are many prioritization methods, but two of the most effective for user research are RICE Scoring and the Eisenhower Matrix. Each serves a unique purpose and can be tailored to your specific needs.

Read more