When I started managing the user research team, I ran into the same issue on day one: findings and recommendations lived in slide decks, private folders, and scattered files. Nothing connected. If someone asked, “Do we already know something about this?”, the answer depended on who remembered which project.

We built a human-in-the-loop, AI-enabled research operations system in Notion to turn scattered reports into a structured Findings Repository. The goal was speed and visibility without losing traceability. Every insight needed a source, a clear scope, and enough evidence that someone else could trust it. We also needed simple governance to prevent duplicates, taxonomy drift, and stale “truths.”

One rule stayed non-negotiable: AI drafts, humans decide.

Role: Design Research Ops / DesignOps (workflow + governance + prompt design)

Research existed, but it didn’t compound

The team ran plenty of research each year, but the learning didn’t build over time. Results sat in slide decks, Figma files, PDFs, and personal folders. We had a shared repository for presentations, yet uploads were inconsistent. People forgot, or they assumed someone else would do it.

When a product team needed evidence, they asked around. Researchers and designers became the indexing system. That created predictable failure modes:

• Teams repeated studies that already existed.
• Decisions leaned on gut feel when the relevant insight couldn’t be found fast enough.
• Knowledge disappeared when people changed teams or left.
• Researchers and designers re-synthesized work instead of building on what was already known.
• Collaboration suffered because the system didn’t help people share or discover learning.

At the start, automation looked tempting. Then we got honest about what AI does well and where it gets sloppy. That pushed the project toward a tighter workflow: AI can help draft structure, but it cannot be the final author of insight.

Findings, not reports

We stopped treating “a report” as the unit of knowledge.

A report is long and full of context. It’s also hard to search and even harder to reuse. A finding is smaller, clearer, and easier to connect across projects.

So we structured the system around individual findings: one observation per entry, written so it can travel. Each finding is designed to be:

• Small and specific (one idea per entry)
• Searchable (tags + structured metadata)
• Traceable (linked back to a source report and an evidence snippet)

The system: two databases, one workflow

We built the repository as two connected databases:

1. Reports Hub The source-of-truth list of research reports.
2. Findings Repository The searchable layer of structured findings.

That split keeps the insight usable while keeping the evidence close. People can find what they need without reading a full deck, and researchers can still trace every entry back to its source.

Where AI works and where it doesn’t

Our early tests surfaced the same issues again and again:

We didn’t solve this by giving AI more freedom. We did the opposite. We made the output stricter, so review became faster and safer.

Guardrails we introduced

Governance

We kept governance simple:

1. Findings enter as 🔍 Pending Review.
2. A researcher decides: Approved / Partial pass / Fail.
3. Quarterly maintenance: sweep for duplicates vs updates, retire what’s stale, merge and tidy tags.

How to use the whole system

To operationalize the workflow, we implemented two small skills:

1. Extraction skill Only used by researchers

Reads a report and extracts discrete, structured findings into the repository.

2. Search skill Used by everyone

Searches the Findings Repository in natural language.

Learnings

AI is changing how teams design tools and workflows. The biggest shift for me was practical, not philosophical: if you want AI in your system, you need definitions, constraints, and review paths. When we treated the Findings Repository as a product with governance, AI became useful. When we treated it like automation, quality drifted fast.