Scattered findings to searchable knowledge
Building the infrastructure for a UX research repository
Role: Lead UX Researcher
Scope: UXR tooling, ux research ops, governance
THE PROBLEM
When I joined Harvard Web Publishing three years ago, one of my first tasks was to interview every member of the team, including developers, researchers, designers, project managers, and leadership. I wanted to understand what they needed from UX, what was working, and what wasn't.
One theme came up in nearly every conversation. People wanted a user research repository. Research was being conducted, studies completed, findings documented, recommendations written, but the knowledge wasn't accumulating anywhere it could be found. Reports sat dispersed across Google Drive folders that only their creators reliably knew how to navigate. Patterns that emerged across studies went unconnected. When team members needed to make design decisions and wanted to know whether user research existed to support them, the honest answer was often: probably, but good luck finding it.
The problem wasn't a lack of research, but a lack of research infrastructure. Without a centralized, structured repository, insights were effectively lost after the study closed, unable to inform future work or provide the kind of institutional memory that makes a product team more informed over time.
This project was the answer to that gap. I led every aspect of it: the proposal, the tool evaluation, the implementation plan, the data migration, the taxonomy development, the platform configuration, the training, the launch, and the ongoing governance.
THE CONSTRAINTS
No formal mandate. Just organizational appetite.
There was genuine enthusiasm for a repository at the team level, but no pre-existing directive to build one. That meant the case for it had to be made carefully. I needed to demonstrate not just that a repository was a good idea in the abstract, but that this team would actually use it, and that the investment was worth making before the heavy infrastructure work began.
Budget and tooling constraints.
Finding a tool that offered the core functionality we needed proved harder than expected. Global tagging across projects (not just within individual studies) was a non-negotiable feature, and most repository platforms either lacked it entirely or attached a price tag for this functionality out of our budget. The search was extensive before Condens.io emerged as the right fit.
Limited researcher seats.
The Condens plan the team could support provided only three researcher/administrator seats. Deciding who held those seats, and how to give other team members and stakeholders meaningful access without consuming them, required careful thinking about roles, access tiers, and governance from the start.
Six years of unstructured data.
The team had been conducting user research for years. Migrating that history into the repository wasn't a simple import. It required auditing what existed, determining what was worth migrating, and deciding how far back to go. Studies completed before the repository existed also required re-analysis to take full advantage of Condens's tagging system.
DECISION POINTS
Decision #1: Validate the need before building anything
What I noticed
The team interviews I conducted when I joined made it clear that everyone wanted a repository. But wanting something and actually using it are different things, and there was concern that this could become a project that consumed significant time and then sat unused.
Before investing in full implementation, I needed a way to test the premise. The team recommended building a prototype with a small number of studies loaded so people could interact with the concept rather than evaluate it abstractly.
The choice I made
I built a lightweight prototype in Condens.io and populated it with a handful of small studies from existing research. I also developed a formal proposal for leadership that outlined the tool, the plan, and the rationale. This was accompanied by user personas and user journeys to illustrate concrete use cases for different team members grounded in what people already told me they needed. In summary, I UXed the repository.
Why that choice was made
Showing beats telling. A prototype makes a repository real in a way that a proposal alone can't. By giving team members something tangible, I gave them something they could provide genuine feedback on rather than hypothetical opinions. The personas and journeys gave stakeholders who weren't researchers a clearer picture of how the repository would fit into their actual work. Leadership buy-in came easily but I'm aware that’s not always the case, so I wanted the groundwork to be solid regardless.
Decision #2: Treat taxonomy as a product design problem
What we noticed
A repository is only as useful as its taxonomy. If tags are too specific, they proliferate into noise. If they're too broad, they don't help anyone find patterns.
Condens differentiates between global tags, applied across all projects to surface patterns, and project-level tags, which are more granular and created during individual study analysis. Getting the global tags right was the foundational problem. I drafted the initial taxonomy with my manager as a sounding board, then ran a workshop with the broader team to pressure-test the categories and land on a final version everyone felt ownership over.
The choice I made
I built the initial global taxonomy by reviewing past research projects and identifying the categories and concepts that recurred most consistently. I also used AI to draft definitions for each taxonomy term, which freed me to focus on the conceptual work rather than wordsmithing descriptions from scratch.
The platform's two-level taxonomy limit turned out to be a useful function that kept the taxonomy manageable rather than expanding indefinitely.
Why that choice was made
Generic global tags are more durable than specific ones. If tags are too closely tied to current project contexts, they become hard to apply consistently as the research portfolio grows. The goal was a taxonomy that would hold its shape across different researchers, different study types, and different years. Running the workshop with the broader team was essential to achieving that. Involving colleagues meant the final tags reflected how everyone searches, not just how I do, which is what makes a taxonomy actually stick.
Decision #3: Evangelize the repository to drive adoption
What I noticed
Knowing a team needs something and getting them to actually use it are two different problems. Tools and processes fail all the time not because they're poorly built but because they don't get traction. Because I had seen it before, this is always a concern I’m contentious of when considering adopting a new tool or process. The team had been asking for a repository for years, but that enthusiasm alone wasn't going to translate into a new habit of consulting a tool before making a decision.
The choice I made
I involved the team in the implementation process deliberately, at a level where they had input without feeling overwhelmed by it. The taxonomy workshop was part of this. So was a demonstration I ran after the initial setup was complete, designed to show the team how powerful the repository already was with real data in it. Seeing findings surface across multiple studies in response to a single search made the value clear.
After launch, I continued to advocate for the repository actively, not just maintain it quietly. When a team member proposed a design direction based on a hunch about what users would prefer, I would ask whether we had consulted the repository first. More often than not, we had research that was directly relevant. Those moments, repeated over time, are what shift a habit.
Why that choice was made
Adoption doesn't happen overnight, especially when you're asking people to change an established process. Years of working a certain way doesn't reverse after a single training session. Evangelism had to be ongoing and grounded in real examples, not abstract arguments about why the repository mattered. The goal was to make consulting the repository feel second nature.
Decision #4: Design governance before problems arise
What I noticed
A repository degrades without governance. Tags drift, naming conventions loosen, ownership gets murky, and the system becomes less reliable over time. I had seen this play out firsthand with documentation on the platforms that preceded this effort, and I wanted to build the maintenance framework into the implementation rather than add it as an afterthought.
The choice I made
I created a repository management framework covering project creation standards, naming conventions, tagging protocols, access permissions, and roles and responsibilities across all user types. I also planned early for the public-facing dimension of the repository. Condens supports a public magazine view, and thinking through which research to share and with whom before those decisions were urgent made the process significantly smoother.
Why that choice was made
Governance isn't exciting to build, but it's the difference between a repository that gets better over time and one that quietly erodes. By establishing the framework before launch rather than after, the expectations were set from the start. Team members who were trained on the platform were trained on the standards at the same time.
OUTCOMES
The repository launched in October 2024. Since then it has become the team's central infrastructure for research knowledge. One of the more tangible shifts has been in how the team makes decisions. Where discussions used to rely on institutional memory or whoever happened to remember a relevant finding, team members can now pull supporting evidence from the repository in real time. Design decisions that might have been debated on instinct alone are increasingly grounded in documented research.
Repository launched on schedule, with research data, global taxonomy, participant pool, and governance documentation in place at launch
Global tag system covering 9 parent categories and dozens of child tags, enabling cross-study pattern discovery
Project templates created to standardize how new studies are set up, reducing setup friction for future research
Repository Management Framework completed, covering roles, access, data quality, ethical considerations, training, and documentation standards
REFLECTION
This project started with a question I asked myself during those early team interviews. If everyone wants this, why doesn't it exist yet? The answer is that infrastructure is easy to defer. It doesn't ship a feature or solve an immediate user problem. It creates the conditions for better work over time, which is harder to prioritize.
What I learned building this repository is that the same principles that make good UX make good research ops. Things need to be findable. The system needs to reflect how people actually search, not just how the person who built it thinks. And adoption depends on people feeling ownership, not just obligation.
Adoption was also slower than I expected, and I think that's worth being transparent about. Changing an established habit takes time. I had to keep showing up in team meetings, keep pointing to the repository when relevant findings existed, and keep making the case through real examples rather than reminders. All while trying not to become the person my colleagues dreaded seeing raise the little Zoom meeting hand every five minutes. 🙂 It’s not the most glamorous kind of advocacy but it's what moves the needle in the right direction.
What I'm most proud of is that it exists and is being used to better support my team. The team that told me three years ago they needed this thing, has it now.