On April 8 I had the pleasure of speaking on a webinar hosted by Maze, alongside the
amazing Brooke Skye, Daniel Soranzo, and Kate Pazoles. We received a ton of thoughtful questions from the audience before and during the session, but we had such a productive discussion that we were only able to get to a handful of them. So I took the liberty of writing up the rest as this FAQ.
Each of these questions could easily be its own blog post, so in the interest of keeping this readable, I took a bit of a lightning round approach — as if I were answering these live on the webinar — intentionally keeping things short and focused on the key points.
Some of the original question phrasing wasn’t entirely clear, so I made some assumptions about intent. If I missed the mark on yours, please reach out. I also left out questions that were too vague or highly dependent on your specific organizational context to answer responsibly. If you don’t see your question here, reach out and I’ll add it to the list.
You can catch up the webinar recording if you missed it.
Here goes.
Career Path & Skill Development
Specialization, transitions, demand, and hybrid roles
What research area should I specialize in?
Assuming here this question is asking about quant vs. qual. If not, whoever asked this — please correct me!
Quantitative research is all about large sample study designs — surveys, structured data, statistical rigour. By design, quant research is good at answering “what” and “how many.” If you’re the kind of person who finds confidence in large data sets and enjoys the precision of numbers telling the story, quant is going to feel like home.
Instead of “what” and “how many,” qual research is great at answering the “how” and “why.” Qualitative research is often faster, more fluid, and deeply human. You’re having direct conversations with customers, iterating quickly, and working with smaller data sets. It’s more intimate and more adaptable — you can shift your approach between sessions, or even on the fly, based on what you’re learning.
Neither is “better.” They answer different questions in different ways, and often they’re complementary. The question to consider is: what kind of thinking energizes you? If you’re drawn to patterns in large data sets, lean into quant. If you’re drawn to the nuance of human conversation, lean into qual. Many researchers I’ve worked with have at least a working appreciation for both.
How do I transition from market research to UXR?
The biggest mindset shift is speed, and getting comfortable with what might feel like a lack of data (see above for quant vs. qual). I’ll be honest — I struggled with this when I made the transition almost 10 years ago, having spent the first seven years of my career in traditional market-research-heavy industries.
The power of UXR is fundamentally qualitative. You’re often making decisions based on conversations with five to eight people at a time, which is a far cry from the hundreds or thousands you’re used to in market research. That can feel unsettling at first.
But what you gain in return is the ability to iterate much more quickly. You can run sessions back to back with fast turnaround, and you can adjust your approach between sessions — or even mid-session — based on what you’re hearing. That’s something you simply can’t do with a survey that’s already in field.
So the transition really comes down to this: get comfortable with ambiguity and speed, and trust that confidence builds over time through iteration, not sample size. You’re not going to have all the data up front. That’s by design, and frankly that’s the beauty of the methodology. The process is built to get you to clarity faster, even if the path feels less certain along the way.
Can a senior designer transition into research without research experience?
Absolutely, and it’s not as big a stretch as you might think. If you have a solid UX knowledge foundation, many of the core skills transfer well — you already know how to frame problems, think about user needs, and synthesize information into something actionable.
Here’s the thing, though: in the context of industry, what separates a good researcher from a great one isn’t actually the craft. It’s the relationships you build and the credibility that comes with them. Great researchers know how to navigate their organizations, build trust with stakeholders, and position insights so they actually influence decisions. Those are muscles you’ve likely been building as a senior designer already.
So don’t let the lack of a “researcher” title hold you back. The craft you can learn and hone over time. The organizational instincts and relationship skills are what you need to pay attention to.
Should researchers now learn design?
This is a tough one to answer without context, because there are a lot of nuances around organizational needs, personal interest, and where the industry is headed.
But the question I’d push back with is: don’t ask “should I?” — ask “why would I want to?” As the saying goes, “just because you can doesn’t mean you should.” As researchers, it’s our job to understand the underlying motivation and get to the root of the problem. So ask yourself: what’s the motivation here? Is it to fill a gap your organization needs? Is it a personal interest you’ve been wanting to explore? Is it about future-proofing your career? Are you reacting to the AI pressure and its impact on the industry?
All of those are valid reasons, but they lead to very different answers. Learning design to satisfy genuine curiosity or to bridge a gap on your team is very different from learning it out of anxiety that your current skills won’t be enough. Whatever you choose, make sure you’re doing it for the right reasons — not because the internet told you to, but because it serves a clear purpose in your career and your circumstance.
Research Operations, Knowledge Management & Scale
Systems, insights reuse, and cross-functional knowledge
How should we organize research findings into a knowledge system?
If the question is whether you should have one, the answer is a resounding “yes, absolutely.” A research knowledge system is essential. If the question is how, the honest answer is: use whatever system works within your organizational context and for your stakeholders. There’s no one-size-fits-all here, and while there are plenty of tools out there (and some are definitely better than others), the tool matters less than the principles behind how you set it up.
Two factors I’d prioritize above all else. First, accessibility — it needs to be easily accessible by all your stakeholders, and ideally adopted by as wide an audience as possible. A knowledge system that only researchers use is a knowledge system that isn’t doing its job. Second, ease of use. There is nothing more discouraging than a knowledge system that people avoid because it’s clunky or confusing.
And here’s the thing people tend to underestimate: maintenance. Once you have a system, you have to keep it up. Whatever tool you choose, make sure you have a good process for upkeep over time. It’s not just about keeping the insights fresh — the system itself needs to stay fresh, and the whole team needs to work together to remind and encourage usage. A neglected repository quickly becomes a graveyard that nobody trusts, and rebuilding that trust is harder than building it in the first place.
How do we manage knowledge across functions — like CX, CSMs, and PMMs — who also have customer insights?
This is a common pain point, and I get why — I’ve dealt with this. When multiple teams are sitting on their own customer insights, things can get territorial fast. But just like research enablement, you have to approach this with a high-trust mentality. You can’t gate knowledge the same way you can’t gate research. Think reciprocity (a topic I’ll write about on this blog someday) — you’re all working toward the same goal, and the information flows better when everyone treats it that way.
So the first step is relational: build the credibility and trust with those teams to be able to collaborate effectively. That’s table stakes. From there, work together to create a system that can house all of your collective knowledge, so you start to work towards a single source of truth. Again, like the research repository, what you pick here almost doesn’t matter. I know that’s easier said than done, especially when teams feel protective of their domain. But remember — the goal isn’t to own the insights. The goal is to make sure the organization has the best possible picture of the customer, and that means balancing the different needs and perspectives across teams.
How do we support non-researchers who are doing research?
I spoke about this on the webinar, so I’ll keep this short: the answer is research enablement. If you don’t already have a good research enablement process, start thinking about building one. Just know that starting from scratch is a lot of work, especially if you have a small team. You’re looking at building tooling infrastructure, training, documentation, and an ongoing consultative model where you provide guidance and feedback so the process improves over time.
Here’s the guidance I want to emphasize most: not everyone is going to have the same skill level as trained researchers, and that’s okay. Start from a place of empowerment and encouragement, not punishment. The goal is to get people doing research and then work with them to raise the quality bar over time. It’s a journey, and you’re not going to get there overnight.
Think of it as teaching someone to fish. There’s a lot of work upfront, but over time it frees up a ton of capacity for your research team to focus on higher-value, more complex work. I’ve done this twice now in my career and it’s paid off every single time.
How does a lean research team balance execution with enablement?
This is one of the hardest problems for small research teams. If you’re a team of one or two without dedicated research ops support, trying to do enablement on top of executing research can feel overwhelming.
A few thoughts here.
If you’re a research leader currently building a team — and you anticipate the team won’t get very large relative to the PM or design org you’re supporting — I’d seriously consider making a research ops hire one of your first. Not your third or fourth. It’s a huge unlock that pays for itself quickly. Research ops was my second hire when I joined 1Password four years ago.
If you already have a small team and you’re in the thick of it, take it in strides. Don’t try to solve all of enablement at once. Identify the most critical phase of the research workflow that needs solving for your stakeholders — the biggest pain point, the place where things break down most often — and tackle that first. Chunk the problem up and go at it one piece at a time so you don’t overwhelm yourself or the people you’re trying to help.
And lastly, look at what AI tools can do for you right now. There are a lot of options out there that can automate parts of the operational burden and give your team back meaningful time. It’s worth the investment to explore what you can offload.
Organizational Strategy & Influence
Positioning research for impact
Where should research sit in the org structure?
I’d love to say there’s no right answer, but there actually is — at least directionally. You want research to report into wherever core product decisions are made. Or at the very least, get as close as possible.
Your direct reporting line determines two things: the immediate context you get and the degree of influence you have. For example, reporting into design means you’ll work alongside people who are closest to user problems, who understand UX concepts deeply, and who understand UXR ways of working best. Reporting into product gives you a direct line to the head of product, which means when strategy and roadmaps are being discussed, you’re already in the room — and that proximity creates more opportunities to influence.
I’ve led research orgs that reported into both product and design, and both have worked well in my career. But generally speaking, if you have the choice, I’d advocate for being as close to product as possible. The proximity to product decisions and roadmap influence is hard to replicate from further away.
One important caveat: I’m speaking here about tech companies that have a somewhat mature product and design practice, which is what I’m assuming most people asking this question are working in. If you’re in CPG, retail, finance, manufacturing, etc., the answer can look quite different. CPG companies, for example, are usually marketing-led — marketers hold the P&L — so it’s more common for research (often called Consumer Insights in that world) to report into marketing. The principle is the same though: follow the decisions.
How do you keep a strategic seat at the table?
There’s truly no gimmick here. A strategic seat at the table is earned, not given, and it’s never permanently yours. To earn it, you and your team have to consistently provide value to your stakeholders. You have to consistently ship high-quality work that moves the needle on the decisions that matter to them. And as a leader, you have to consistently drive visibility and understanding of that work and its impact on key organizational and product decisions.
That’s it. It sounds simple, but the word “consistently” is doing a lot of heavy lifting. It’s not about one great project or one insightful readout. It’s about showing up, again and again, with work that earns trust. And it means understanding what “value” looks like to the people across the table from you — because their definition might not match yours.
AI in Research: Practical Application
Where AI fits in workflows today
What’s the best way to integrate AI into user research? Where should you use it — and where shouldn’t you? Where does AI meaningfully change the workflow? How should we think about AI tools, agentic automation, and the right level of automation? What are your thoughts on AI moderation and synthetic users?
There were a bunch of related questions on AI and automation, so I’m going to answer them together.
Off the bat, the answer is going to depend largely on your research stack and the AI tools available to you. My experience at 1Password isn’t going to map cleanly onto yours. But I can share some principles and corresponding examples from how we’re using AI to support our research process.
In broad strokes, use AI to automate the tedious and repetitive tasks. Things like building templates, research briefs, and discussion guides — those are a great starting point. We outsource this kind of work to AI at the top of a research project, and it gets our enabled stakeholders 70 to 80% of the way there without them having to start from scratch every time.
Another example: looking up historical research. We have hundreds of projects in our repository, and people just don’t want to dig through them. What ends up happening is they Slack a UXR for the answer instead, and it happens with such high frequency that it’s not a good use of anyone’s time. So we built a custom agent integrated into Slack that searches our repository and surfaces what’s relevant.
The part of research we’ve deliberately not outsourced to AI is synthesis and analysis. Our belief as a team is that learning and iteration happens through the grind of the work, and true customer empathy is built through that labour of love. So we’ve focused on automating away the parts of the process that aren’t worth our time and energy, and preserved the space for things like synthesis and analysis — because that’s how we stay the authority on our customers and the voice of the customer inside the organization. I wrote more about this sentiment here.
Some additional thoughts from Ginnie Morse, Staff UXR on my team: at 1Password, we haven’t found a compelling use case for AI moderation or synthetic users — our focus is building for cybersecurity professionals, and our target personas are hyper-niche compared to your average B2B or B2C customer, so the promise of speed and scale that comes with those approaches isn’t what we’re optimizing for. But five years of deep, foundational research across the product means we can do something more interesting: we can use that historic data to train AI, build our own version of “synthetic users” grounded in real research and trained on our own transcripts to get quick feedback on things like messaging or PRDs, and create agents that tap into our repository so stakeholders can ask questions and get answers rooted in what we actually know about our customers. And when the agent surfaces gaps in confidence, it automatically creates an item for the research team to review — so we can see what’s top of mind for our stakeholders, where our knowledge is thin, and use that to continuously build out our research roadmap.
At the end of the day, the real question for everyone is: what are you trying to optimize for when it comes to AI usage? If you have a small research team, low research maturity in your org, and you’re looking to optimize for speed and scale, then by all means — give AI moderation and synthetic users a look and see where they can help your research process. But if you have a decent-sized research team with high research maturity, and you’re optimizing for deep understanding of your customers and continuing to build that intuition without sacrificing quality, then I’d look at AI tools that improve your process and operations to free up time so your researchers can focus on interfacing directly with customers.