Quant (and Qual) UX Researcher org structures

data-culture Oct 27, 2026

Every so often, people ask me how my work is embedded in relation to the various teams around me. What does the work tend to look like with respect to who I work with and that the problem space is. The answer is of course "it depends", but the overall dynamics tend to follow certain patterns. The patterns of course have as much to do with how I personally tend to work (and thus, what management styles I self select into), as they do with how work in general is done.

The one universal dynamic is one of asymmetry. The job title "Quantitative UX Researcher" has always been a rare one, to the point where even when I was at Google the ratio between "normal" UX researchers and quants was easily higher than 10-to-1. Outside in the broader world, the ratio is even worse. At most you have folks who fulfill the quantitative role, usually a data scientist or analyst of some sort, but very often those data folks are not a part of the larger UX organization. Then there are usually multiples more software engineers than UX staff. Even the ratio of product mangers to all UX Researchers, let alone quants, tends to be very lopsided. All of these factors add together to create situations where team dynamics get pretty complicated.

So, while I certainly haven't experienced all the different permutations of how researchers can be organized, I figured I'll note down the ones I've experienced.

Quant+qual teams under the same reporting chain

There's a couple of variations of this, but at a high level, there's usually a "research team" that consists of a mix of qUXRs and UXRs. Depending on the exact size of the team, everyone might be a peer to each other under the same manager, or the qUXRs are split off into a small "quant team" separate from the "qual team". Everyone is largely aligned with similar goals and stakeholder partners, the group is usually tightly knit with connections between everyone. Regardless of the specifics of who reports to whom, which teams get more or less of every researcher's time, I lump all of them together because organizationally speaking, the research team itself is tasked with providing research work for product teams in some way and they organize to handle the problems at hand.

Inevitably, given how staffing works out, for any given problem there are more UXRs around than qUXRs. This is generally because UXRs are more flexible – there are qualitative methods that can apply to all stages of product development, from conception to post-launch. At any point in time, you can always grab people to ask questions or observe. Quants have a few spots where if no data is available, we have limited tools (often surveys or telemetry and metric design) to provide insights. We can't analyze or even collect data if the systems haven't been built.

This org structure tends to feel the most "natural". Research insights and knowledge does not care about methodological boundaries, and very often the questions that need answering can only be fully answered by taking input from both quant and qual approaches. As the saying goes, qUXRs are good at answering "What" is happening, while UXRs are good at answering "Why". Even stakeholders recognize the value in mixing methods together because they inevitably ask a question that requires the help of a researcher from "the other side".

But even with this natural pairing of methodologies under one org structure, the researchers work quite differently in practice. UXRs almost inevitably work more closely with product teams. Qualitative studies take time to develop. Interview questions need to be agreed upon. Subject recruiting criteria need to be hammered out. Usability setups and tasks need to be prepared and tested before subjects are brought in. Creating a survey requires a lot of input, discussion, and sign-off. Results are very nuanced and require thoughtful read-outs with proper voice overs.

Meanwhile, qUXRs inevitably work more horizontally, juggling work across multiple product teams. Part of this is the lack of staffing levels I mentioned, but the other part is that there is an ebb and flow to when quant methods are "needed". qUXRs are most busy right around big milestone events like a product launch. Right before the event we make sure telemetry and metrics are in place, success is well defined. Right after the event, we're monitoring to make sure data is coming in, as well as answering questions that come up using the data as it comes in. But there are parts in the software development cycle where our help isn't necessary – for example, if telemetry is already defined, we mostly wait until the engineers finish their work before we need to do anything else. Until then, qUXRs can use their time to support other teams or do something else.

So my experience has always been that qUXRs partner more closely with their UXR counterparts than the product teams themselves. Instead of going to five individual product team weekly standup meetings, they usually negotiate some kind of proxy method where they get pulled into important meetings as-needed, but aren't necessarily bound to a specific team.

This natural pairing of quant and qual methods works out quite well because for any given research project, both researchers usually have something important to contribute and say – the story is incomplete without both and both researchers know it and act accordingly.

Completely separate quant team

Sometimes, organizationally, the quant teams floats free from other user research teams. Sometimes these groups still sit under the UX umbrella doing "horizontal" or "consultancy" work, but oftentimes they're more like a data science team tasked with doing their own projects. Very often these teams are doing things like "helping teams find more revenue" or "develop XYZ resource/model for other teams to use". Occasionally they "provide insight to stakeholders". These roles are going to be more "data science-y/engineer-y" in nature and less "user-focused", but the specifics will vary based on what's going on.

Here, work tends to come to the team instead of being actively sought out. While no one likes being the helpdesk that gets projects thrown over a fence at them, it happens quite a bit. Teams that have better leadership backing can sometimes actively seek out problems to solve, but it all gets done in between "urgent" work coming in.

One of the biggest problems these teams face is figuring out what they should be building that's not "whatever some random stakeholder asks". Most of us know that stakeholder requests may not actually align with "The Most Important Problems". Since the team effectively a kind of internal-facing product team, they constantly have to ground themselves in problems that other teams are facing and that can't happen in a vacuum. The most common way to find problems to solve is to pump leadership for information until something seemingly impactful falls out. When there's a lack of leadership guidance (gasp), these teams often have to go talk to individual product teams (typically the product manager/lead) to get a sense of what is going on, what problems need solving.

But besides the PM, who always have a specific agenda they're trying to accomplish, qualitative UXRs are an (un)surprising source of user and systemic pain points. You often have to go out of your way to make contact, but there's a lot of hidden value in sharing notes, working together, and occasionally stumbling on some pain point that needs quant+qual help to solve.

Fully embedded within a silo

While rare, it does occasionally happen when a quant researcher is just directly attached to a single product silo. It gives them a the time and access to focus on problems within a domain for longer. It also means they can build stronger relationships to different parts of the team, not just the more typical PMs and UXRs.

Usually, in the inevitable slow periods of the product lifecycle, qUXRs are talking to folks and trying to anticipate what problems will need to be solved in the near future. This includes things like anticipating infrastructure needs and "big strategic questions". Having relatively more access to lull periods compared to the other organizational layouts means having the luxury to do more deeper thinking about what needs to be done. Teams like these, if they have an academic bent, are often the ones who wind up writing publications about the new refined methods they developed, because they're typically the only ones who have the mental bandwidth to do that kind of work. Everyone else is usually juggling a bunch of other competing projects.

Org structure doesn't perfectly define engagement models

While the usual adage of everyone shipping their org chart applies pretty universally, org structure alone doesn't dictate how teams work. Anyone can implement a consultancy model (ugh) in just about any org structure. You can usually get away with semi-embedding into one or more teams and having close relationships up until your calendar or brain explodes. You can choose who you work with and specifically seek out teammates and partners that work well and do great work with them. Some org structures tend to prefer some engagement models, but I've never seen an instance where people can't just decide to not work some other way they prefer.

Subscribe!

Marcos this week saw a wild claim in a Gemini ad that claimed the phase of the moon correlated with baseball phenomenon and called BS on it by breaking out the math and models.

Standing offer: If you created something and would like me to review or share it w/ the data community — just email me by replying to the newsletter emails.

Guest posts: If you’re interested in writing something, a data-related post to either show off work, share an experience, or want help coming up with a topic, please contact me. You don’t need any special credentials or credibility to do so.

"Data People Writing Stuff" webring: Welcomes anyone with a personal site/blog/newsletter/book/etc that is relevant to the data community.

Counting Stuff Official Forums: Discuss posts, or other data topics with the community.

I’m Randy Au, Quantitative UX researcher, former data analyst, and general-purpose data and tech nerd. Counting Stuff is a weekly newsletter about the less-than-sexy aspects of data science, UX research and tech. With some excursions into other fun topics.

All photos/drawings used are taken/created by Randy unless otherwise credited.

All Tuesday posts to Counting Stuff are always free. The newsletter is self hosted. Support from subscribers is what makes everything possible. If you love the content, consider doing any of the following ways to support the newsletter:

Consider a paid subscription – the self-hosted server/email infra is 100% funded via subscriptions, get access to the subscriber's area in the top nav of the site too
Send a one time tip (feel free to change the amount)
Join the Approaching Significance Discord — where data folk hang out and can talk a bit about data, and a bit about everything else. Randy moderates the discord. We keep a chill vibe.
Get merch! If shirts and stickers are more your style — There’s a survivorship bias shirt!