Scaled research by building a system that enabled cross-functional teams to run rigorous research
CHALLENGE
Product and marketing teams were doing research without a dedicated UXR team, but the work was inconsistent, duplicative, and often not grounded in a shared standard.
WHAT I DID
Defined what good research should look like with leadership, reframed the problem around researcher judgment, and built three connected systems: a standards framework, a playbook, and a Claude plugin.
OUTCOME
Three connected systems shipped in six weeks: a standards framework, a playbook, and a Claude plugin with two skills. The early signal was the one I wanted, with PMs and designers checking existing research before commissioning new work.
ROLE
Director of Product Design
TIMELINE
Mar - Apr 2026
TEAM
CEO and CPO
DETAILED PROJECT BREAKDOWN
Without a shared research standard, and no UXR team, product decisions were often weakly grounded.
When I joined, research was happening across teams, but there was no shared standard for doing it well.
BioRender builds software that helps scientists communicate their research. Understanding those scientists should have informed product decisions consistently, but there was no dedicated UX research team. Product and marketing were both doing research, often inconsistently and sometimes duplicating work that had already been done.
Teams scheduled new calls when relevant answers already existed
Research quality varied by person and team
Product decisions were too often weakly grounded in user needs
The real problem was a lack of a shared bar for excellence.
At first, I thought the fix would be training. The deeper issue was that nobody had defined what good research looked like at BioRender.
I expected to focus on capability building: better discussion guides, stronger method choices, and better facilitation. After speaking with PMs, designers, and the director of marketing, I realized the main gap was more fundamental.
Without a shared definition of quality, teams had no clear way to improve, align, or know when the work was strong enough.
The issue was not lack of effort
The issue was no explicit standard
That changed the question from “how do we train people better?” to “how do we make researcher judgment accessible?”
Instead of training everyone to be researchers, I built systems they could use.
Working with the CEO and CPO, I focused on making researcher-quality judgment accessible to non-researchers.
As we defined what strong UX research should look like at BioRender, it became clear that we were really describing the judgment of an experienced researcher: weighing evidence, reducing bias, and distinguishing between what users say and what they actually do.
So instead of asking every PM, designer, or marketer to become an expert researcher, I built systems that helped them make better research decisions in their existing workflow.
I created three tools that made better research easier to do.
built a standards framework, a playbook, and an AI-assisted toolset to help teams do better research with the resources they already had.
1. Research standards framework
I created a framework that defined three areas of competency:
Product and user fluency
Research design and preparation
Facilitation and synthesis
The first version was a more detailed rubric with levels and ratings. It did not survive review because it felt too process-heavy. I simplified it into something clear enough to guide teams and light enough that they would actually use it.
2. UX research playbook
I created a playbook that established a clearer sequence for teams to follow:
Check what is already known
Decide whether new research is actually needed
Design the study well if it is
This reduced redundant research and made existing knowledge easier to reuse.
3. Claude plugin for researcher judgment on demand
I helped create a Claude plugin with two practical functions:
One skill searched across connected research sources and evaluated the evidence
One coached teams while planning and reviewing research, catching leading questions, compound questions, and other forms of bias before a study ran
Early usage showed the system was useful, but adoption needed stronger distribution.
The most encouraging early signal was that PMs and designers started checking existing research before launching new work.
That was the behavior change I wanted to see. It showed that the system was helping teams use evidence earlier instead of defaulting to new research.
I left before I could see whether adoption held at scale, so I would not overstate the longer-term impact. What I can say is that the work established a shared standard, improved access to prior research, and gave teams practical support without requiring a dedicated UXR team.
If I did it again, I would start lighter and adapt faster to the company’s culture.
My first instinct was to create a more structured framework for assessing research quality and helping teams improve. At BioRender, that was too heavy for the way the teams worked.
The company was more averse to process and formal frameworks than I initially understood. My first version was a system for assessing where people were and guiding training. This introduced more structure than the team was ready to adopt. A lighter-weight standard would have been faster to roll out and easier for people to use.
I would also have pushed distribution earlier. Building the plugin and framework was tractable; getting them into people’s hands without a formal publishing path created friction and slowed adoption.
