UXR Team, Not UXR People: A Manifesto on How a Modern Research Team Should Work

Last week I promised that this week I would finally post the last part of my series on UX research for AI-native teams. Well, I lied. Part six is still coming, but this one would not wait.

The biggest problem in UX research right now is that most companies with a UXR team have UXR people. I think it's bigger than AI and bigger than the job market.

Fair warning, this started as a rant. It has been in my head for so long that it finally manifested, so call it a manifested rant if you like. Some of it will annoy people, and I'm fine with that.

A team has a shared plan and a shared standard for the work, and its members depend on each other to do the job well. UXR people are researchers who report to the same manager and each work alone for their own PM. From the outside the two look the same, because both have an org chart, a Slack channel, and a weekly meeting.

I think the field has to redefine what a research team is, and soon, because companies are already redefining it without us. Layoffs are doing it, and so are PMs with AI interview tools. So this post goes problem by problem. For each one I describe what I see and what I think we should do about it as a function. The full list of commitments is at the end.

Most UXR teams share a manager and nothing else, so the first fix is a one-page vision

By that I mean the reporting line is the only thing the researchers have in common. They report to the same manager, attend the same weekly meeting, and post in the same channel. Their work never touches. They have no goal that takes more than one of them to reach, no agreed standard for good work, and no knowledge they hold together. Each researcher's week would look the same if the other researchers did not exist.

There are two quick ways to check whether this describes your team. The first is to ask every researcher what the team is for. On most teams each person describes their own product area, and no two answers match. The second is to take the last ten studies the team shipped and count how many a second researcher read before a stakeholder did. On the teams I've seen, the count is close to zero.

A group like that is a set of individual contributors on the same calendar invite. Each researcher sits with a product team, gets judged by that product team, and is loyal to it. The research manager approves vacation, collects bullet points for the monthly update, and passes requests along. If you removed the manager and the weekly meeting, the work would continue exactly as before, and that tells you how much the team adds.

The field treats this as normal. One researcher embedded in each product team is still described as the ideal setup, and nobody asks what connects those researchers to each other. I think that gap makes research easy to cut. When layoffs come, leadership looks for what the research team does and finds nothing that belongs to the team. It finds eight people doing separate work for eight PMs, and separate work can be removed one person at a time.

The best objection here is that embedding works. An embedded researcher knows the product and has the PM's trust, and a central team taking requests from a distance loses both. I agree, and I am not asking anyone to pull researchers out of product teams. Stay embedded for the daily work. Belong to the research team for the plan, the standards, and the critique. When the two conflict, the research team comes first.

I put the vision first because every other fix in this post depends on it. A critique needs a standard to hold work against, and rules for requests need priorities to sort by. Most teams have a roadmap instead, and the roadmap is every PM's requests in one spreadsheet. That is a queue. It says what the team will be busy with and nothing about what the team is trying to become.

So I think we should start with one page, written by the whole team in one room. It says what the team is for, in words a head of product would recognize. It says what the company should know about its users a year from now that it doesn't know today. And it says what the team will stop doing to make room, which is the part most vision documents leave out.

Next to the page we keep a plan for the year, with names and dates, and it includes work no PM asked for. Then we show both to the head of product and ask for a reaction. A vision that nobody outside research has read changes nothing.

Being friends doesn't make you a team, and cliques form where nothing is written down

Plenty of these groups get along. The researchers like each other, eat lunch together, and have a group chat full of jokes about their PMs. I'm glad when that happens. But being friends with each other doesn't make you a team. Friendship can even get in the way, because it is hard to tell a friend that their discussion guide is leading or that their sample can't support the headline finding. So nobody says it, and the work goes out as it is.

The friendships can also harden into cliques. When nothing on paper says how the team works, people sort themselves by who they like. Two or three researchers share information with each other first. They praise each other's work to the manager. They settle questions in a side chat, and everyone outside the group hears about the outcome later, as a decision already made.

To explain why, I have to go back to how these teams were staffed. In March I wrote that most UXR teams are never designed and just accumulate. Then the boom came. UXR postings went from an index of 100 in Q1 2018 to 566 in Q1 2022 on Indeed's data. Companies hired researchers faster than anyone could decide what the researchers were for.

A lot of the people hired in that boom came out of a bootcamp or a certificate program, or moved sideways into research from another job. Most of them know one method, and it is usually qualitative. In 2021 that was enough. I wrote in May that pure qual is cooked, and the market has not changed its mind since.

Titles went out by timing too. A researcher who joined in 2019 became a manager in 2021 because six new hires needed someone to report to. Then postings fell 73% from 2022 to 2023, and whoever held a title when the hiring stopped kept it. The result is low-skill researchers in positions they shouldn't hold. Some of those hires kept learning and are excellent now. Others have four years of titles and one year of experience repeated four times, and they are leads and managers.

What follows is my read from the teams I've seen, and I can't prove it for the whole field. I think a lot of cliques are self-defense. A researcher who knows one method is exposed when the questions change, and a group is safer than standing alone. So the group agrees that the way it already works is the right way. When a colleague brings a survey or an experiment, the group treats it as a threat. It questions that colleague's judgment in private and closes ranks in public.

Some people build these cliques on purpose. In a group with no written rules, a clique is how you get influence and how you keep your position. It decides whose work is called good, who hears about the reorg first, and whose name comes up when a promotion slot opens. None of that has anything to do with the quality of anyone's research, and everyone on the outside knows it.

Cliques depend on private information and private decisions, so I think we should make both public inside the team. Decisions about the team's work get made in the team's meeting or channel, with the reasons written down. Study plans and readouts are open to every researcher. If a decision was made in a side chat, it gets made again in the open or it doesn't count.

Nobody is going to take back four years of titles, so the rest of the fix looks forward. Before the next hire or promotion, we write down what the role has to be able to do, and we hold the candidate to it. And we make method range the team's job. A qual researcher and a quant researcher pair on the next study, and each leaves knowing some of the other's method. Learning a second method is a better defense than a clique.

Researchers like working alone and are judged alone, so review and reward have to change for everyone

I've blamed managers and history so far. Researchers keep this arrangement going too, because it is comfortable.

When you are the only researcher for a product area, nobody checks your work. The PM can't tell a good discussion guide from a bad one. The relationship is yours, the praise is yours, and you are the expert in every meeting you attend. A team takes some of that away. A colleague reads your plan and says the sample is wrong. I think plenty of researchers who complain about having no team would not enjoy having one.

Senior people are often the biggest obstacle, because they have gone the longest without review. A staff researcher who hasn't had a study plan questioned in five years will not welcome it now.

The reward system pushes the same way. The promotion cases I've seen list the person's studies, their impact on their product area, and quotes from their PMs. Nothing in that case rewards the hour spent reviewing a colleague's guide or teaching someone a method. At many companies researchers on the same team also compete for a limited number of top ratings, so helping a colleague look good costs you something.

You can ask people to act like a team all you like. If the review cycle pays them to work alone, they will work alone, and they will be right to.

I think we should change both things. Everyone's plans and readouts go through the team first, and that includes the staff researcher and the manager. If only juniors get reviewed, the seniors have just found another way to work alone. And team work gets written into the expectations for every level. A senior researcher's review should ask whose work they improved this year, and it should expect an answer with names.

Researchers present work no other researcher has seen, so we need a weekly critique and a quarterly retro

Designers run critique. Engineers review every pull request before it merges. Researchers field studies and present readouts that no other researcher has looked at. We are the function that tells everyone else to test things before they ship, and we ship our own work untested.

I think we should hold a critique every week. One researcher brings a study plan before it fields, or a readout before it's presented. The others read it in advance and look for leading questions, for a sample that doesn't match the decision, and for claims the data can't support. Everyone is in it, so feedback comes from the whole team and not only from the two colleagues you're friends with.

Timing matters here. A critique of a study plan can still change the study. A critique of a finished readout can only change the slides. So most of what comes to critique should be plans. A researcher who only ever brings finished work is asking for applause.

This is uncomfortable, and most teams skip it. Critiquing a colleague's study gets treated as rude. I think that norm is backwards. A PM or a data scientist will find the weak claim in the readout anyway, in front of the whole product team. It costs far less when a colleague finds it on Tuesday in a room of researchers.

We should also run a retro once a quarter. We go through the studies that shipped and ask which ones changed a decision. For the ones that didn't, we ask why we ran them. Most teams never look back, so they run the same kind of study the next quarter and it changes nothing again.

The retro also gives the team something better to send leadership than the monthly list of studies per person. That list makes it easy to ask which researchers the company can do without. I think we should send one page a quarter, organized by decision. It says which decisions research changed, and which ones it should have changed and didn't. Reporting your misses takes nerve, but it shows leadership a team that measures itself by decisions.

Each researcher's findings stay in their own decks, so the team needs one shared record of what it knows

Ask a research team what the company currently believes about its users. You will get pointed to a folder of decks, organized by whoever ran each study. That folder is a list of studies. It doesn't tell you what is still true, where two studies disagree, or what nobody has looked at in two years.

When each researcher works alone, the knowledge also leaves with them. A researcher moves to another product area or another company, and the next person starts from zero or runs the same study again.

I think we should keep one shared record, looked after by the team, of what the company believes about its users and how sure it is. It is written as claims in plain sentences, each with the evidence behind it and the date it was last checked. Every finished study updates it, and one named person is responsible for keeping it current.

I have been writing about this for a while under the name the Frame. The Frame is the company's model of its users, built up over time from many sources and kept current by someone who is responsible for it. It has four properties. Coverage is which users and problems the company understands well. Freshness is when each part was last updated. Confidence is how strong the evidence behind each part is. Ownership is who is accountable for knowing whether it still holds.

The full version is in my book, AI-Powered UX Research. On the blog, I defined it in On the Concept of the "Frame" and covered how to build one in Build a memory, not an archive.

No single researcher can keep this up alone, and no product team will do it for us. It is the clearest case of work that only a team can do.

Most teams run whatever a PM asks for, so we need written rules for what gets studied

Most research teams work like a vending machine. A PM asks for a study, and a study comes out. The researcher's judgment goes into how to run the study and never into whether to run it. Saying no feels impossible, because the PM is the person who writes your feedback.

Nothing is written down about who gets research and why. It gets settled by seniority and by who is friends with whom. So the loudest PM gets the most research, and the quiet team making a large bet with no evidence gets nothing, because nobody from that team asked.

A lot of the requests are also not questions. They are requests for cover. The decision is already made, and the study is there to put a user quote on the slide. Every researcher knows this kind of request, and most of us run the study anyway, because refusing is a fight we would have alone.

I think we should fix this with governance, which is a dull word for a few written answers. We write down who decides what gets researched and on what criteria. We write down what counts as enough evidence for a roadmap decision, and who is allowed to say no. I went through these questions in an earlier post on AI-enabled teams.

With rules, a request starts a conversation about the decision behind it. We ask what is being decided, by when, and what would change the PM's mind. If nothing would change their mind, there is no study to run. Some requests get a study. Some get an answer from work the team already did. And some get a no, with the reason, from the team and not from one researcher standing alone.

PMs and designers will run their own research, so the team should train them and set the bar

Democratization is coming whether research approves or not. Vendors already sell AI-moderated interviews straight to product managers. The pitch is that a PM can get interviews done this week without waiting for a researcher. Research often hears about the purchase after the contract is signed.

I think this will change how research functions operate more than anything else in this post. The concept test, the quick round of interviews, and the usability check are exactly the work these tools are built for. They are also most of what many research teams do.

Researchers who work alone respond in one of two ways. Some refuse to engage and call the work bad, which is sometimes true and never persuasive. Others quietly help their own PM, each with their own advice. Neither response gives the company a standard, and the PM keeps running studies either way.

A team can get ready, and the job is to hold a standard, not to stand at a gate. I think we should publish one standard for what counts as evidence, and it applies to everyone who produces any. Every finding carries a label that says what was observed, who it involved, how many people, and how confident we are. A PM's six interviews are still evidence. The label says they are six interviews, and the decision gets weighed with that in view.

I wrote about this standard in Democratization is happening whether research approves or not. The test I use there is that evidence is good enough when its strength matches the cost of being wrong on the decision it serves. Six interviews can carry a decision that is easy to reverse. They can't carry a quarter of engineering work.

Around the standard, we give PMs and designers training, templates, and a named person to ask. And we get into the vendor decision before the purchase.

That standard has to cover our own use of AI too. On most teams it is a private habit. One researcher trusts the summary, and another checks every quote against the recording, and their readouts look the same. We should write down what a person checks before anything reaches a stakeholder, starting with every quote against its source.

This changes the researcher's job. Less of the week goes to running routine studies. More of it goes to the hard questions, to the shared record, and to checking that what the company calls evidence is evidence. If we don't set those terms, a vendor's sales deck will.

Research and data science first meet in the readout, so we should plan each quarter together

A company splits what it knows about users across functions. Data science knows what users did. Research knows why they did it. Market research knows how many of them there are and what they would pay.

On most teams these groups first meet in the readout. The researcher presents, and a data scientist raises a hand to say the numbers show something else. The PM then picks the answer they already preferred, and both functions lose some credibility. Part of this is our fault. Researchers have treated data science as a rival for years, and one-method researchers have the most reason to keep their distance.

One researcher can be friendly with one data scientist, but only a team can agree with another function on a quarter of shared work. So I think we should plan with them. At the start of the quarter we pick the questions together and agree who takes which part. Then we present one answer with all our names on it. Three functions with three partial answers look like three cost centers, and one group with a full answer looks like something worth keeping.

Research managers who report to different directors build territories, so research needs one head

Bigger companies split research by vertical. Each vertical has a research manager, and that manager reports to whoever runs design or product for the vertical. Nobody in the company has research as their whole job across all of it.

Plenty of companies split research by vertical and still have a head of research above the managers. I am not talking about those. I mean the setup where that person doesn't exist.

Each manager then answers to a different boss with different goals. A design director is usually not a researcher, so they can't judge the research and they can't coach the manager. When two research managers disagree, they have no shared boss to settle it, so it stays unsettled for years.

The result is territory. Each manager puts their own stake in the ground and protects their headcount, their stakeholders, and their way of working. Standards drift apart until "senior researcher" means something different in each vertical. Every other fix in this post stops at the edge of one vertical, and a PM who gets a no from one research manager can go and ask another.

I think this one is not optional. If a company has more than one research manager, they should all report to one head of research. The title can be director or lead. What matters is that one person owns the vision, the standards, and the headcount across verticals, and that research is that person's whole job. The researchers stay embedded, and the design directors stay their partners. Only the reporting line changes.

That person also keeps the team pointed at where the company is going. Reorgs move product areas around, and engineering teams are being rebuilt around AI agents. So every quarter the head of research lists where decisions about users are being made now and which of them research is missing, and then moves people to match. A manager who can't tell a PM that their researcher is moving will keep the team exactly where it was in 2022.

A research team that wants a say in its own future commits to ten things

Here is all of it in one place. If you run a research team, or sit on one, this is what I think we sign up for.

1. We work from one page that says what the team is for, and people outside research have read it.
2. We make decisions about the team's work in the open. Nobody should need to be in the right group chat to know what is going on.
3. We hire and promote against a written bar, and we teach each other the methods we lack. Being there first is not a qualification, and neither is being liked.
4. We show our work to each other before we show it to anyone else, and nobody is too senior for that. Reviewing a colleague's work counts in our own reviews.
5. We report to leadership as a team, on the decisions research changed and the ones it failed to change.
6. We keep one shared record of what the company believes about its users, and every study updates it.
7. We decide what gets studied, by written rules, and we say no with a reason. We stop being a vending machine.
8. We train the PMs and designers who run their own research, and we hold their work and our own AI output to one standard.
9. We plan with data science and market research, and we bring the company one answer.
10. We report to one head of research, who checks every quarter where the team should be.

Most of this needs no headcount and no new tool. Two items need leadership to act, the head of research and the promotion criteria. A team can start on the rest this month. What it takes is people who will put up with being uncomfortable. The manager has to tell a PM no. The researchers have to hear from a colleague that a study plan is weak, and then fix it.

I know how this sounds to a team that has been comfortable for years. But the field is being redefined right now, by layoffs and by PMs with AI tools. Researchers who each work alone have no answer to that, because they can be cut one at a time. A team with a plan, a shared standard, and written rules is harder to cut, and it gets a say in what the job becomes.

If your manager won't do any of this, start with one colleague and an hour of critique a week. If you are the manager and this post made you angry, ask yourself which section did it.

Tell me where I'm wrong. And if your team already works this way, tell me how it got there.

🎯 If this annoyed you, subscribe to The Voice of User. I am going to keep saying it either way, and you may as well see it coming.

📖 If you want to build the shared record this post keeps coming back to, I cover the Frame in my book, AI-Powered UX Research: How to Run Research at the Speed Your Team Actually Needs.