Building the research memory

The problem

navify Digital Pathology is, in effect, the digital replacement for the microscope — pathologists review whole-slide images on it to diagnose cancer. What they conclude in it feeds back to the clinician and into a patient’s treatment — a false positive flags cancer that isn’t there, and a false negative lets real cancer go undiagnosed. Those stakes are why the design decisions behind the tool have to hold up.

We weren’t short on research; we were short on memory. The team had run a handful of pathologist studies since 2020, but each tended to serve its immediate purpose and then fade. Funding was a recurring fight — the business didn’t always see the value — and studies often moved slowly enough that findings arrived after the decision they were meant to inform. Just as often, a study aimed at one question would surface valuable observations about how pathologists actually work, and because those weren’t the focus, they slipped away. We came to know a great deal about our users that we could no longer point to: we could say what pathologists tended to do, but not which study had taught us — and recovering it meant hours in old reports and raw notes.

A telling example: we’d heard off-handed requests for more keyboard shortcuts for years, but when the time finally came to add them, it took days of combing raw notes from old studies to back up what we already knew intuitively.

In most products, that’s inefficiency. In a regulated medical device, it’s also exposure — a decision you can’t trace back to evidence is one you can’t defend.

Why it became mine

No one assigned this. There was no mandate and no budget. It just bothered me — knowing there was research I couldn’t get to — so I asked for it, reaching out to everyone who had worked on the product and getting their reports into one shared place.

What I wanted from it was easy to say and hard to do: to build on what we’d already learned instead of starting cold each time, to defend a design decision with something concrete to point to, and to make sure future research would accumulate instead of scatter.

How it came together

Having everything in one place was a start, not a finish — a pile of reports is still a pile. I’d come across the Atomic UX methodology and knew it was the structure I wanted: research broken into small, linked, reusable pieces. But applying it by hand to years of studies would have taken more time than I had, and I couldn’t yet make the business case for a dedicated tool. So I held onto the idea and waited for the means — and AI is what eventually provided them.

The first step was Confluence: a single place to compile and assemble everything we’d done. It pointed in the right direction and it helped, but it was still just storage, and I knew it would have to become more.

Next I moved the corpus into Google Drive and put NotebookLM on top of it, so the compilation could be queried by AI. That was a genuine step up — good for the gist, and, more useful to me, good for finding which study to open: if I needed something a study had only touched on, rather than what it was labeled about, NotebookLM could at least point me to the right report. What it couldn’t do was keep facts and inferences straight; it weighted findings unevenly and surfaced claims I couldn’t fully trust, so it stayed a guide, never a system of record.

The turning point was Claude Code. I used it to build the Atomic UX structure directly in Confluence — having it break our research into facts, which I reviewed one by one, then consolidate those into insights, which I reviewed again. The AI did the heavy lifting while I stayed responsible for everything it produced. That review wasn’t optional: left alone, the model would occasionally invent a quote or misattribute an observation, and in a regulated context that is exactly what you can’t allow. With the check in place, the full Source → Fact → Insight → Opportunity flow ran for the first time — and it worked well enough that I could finally show the business what it was worth. They got on board, and research won real funding.

That funding changed the problem. We were suddenly running more studies, more often, and the repository had to scale with them — and Confluence couldn’t. It wouldn’t sort, filter, or link the way the system needed, and in practice it could only be driven through Claude Code. So I built a standalone repository of my own, purpose-built for the job. As of this writing it’s what the team works from, and I expect to keep improving it for as long as I’m the one using it.

The system

What came out of that is a model adapted from Atomic UX, shaped to how we actually work:

Source → Fact → Insight → Opportunity

• Source — wherever the knowledge comes from: a study, a set of interviews, an ad hoc conversation, voice-of-customer feedback, even a business need. It isn’t only for UX.
• Fact — a single, verifiable observation, tied to its source, with no interpretation.
• Insight — what the facts add up to: an interpretation that holds across more than one fact.
• Opportunity — once insights carry weight, they point to opportunities: data-backed spaces worth exploring that feed straight into product development, so we begin already confident something worthwhile is there.

Insights are the bread and butter. Doing the work up front to tie every fact to an insight means nothing useful falls through the cracks — even an off-hand comment from a study about something else keeps rolling forward, a snowball gathering evidence, until the pattern is too clear to ignore. And because every insight wears its evidence on its sleeve — one observation, several, or confirmation across independent sources — we can act on what we actually know instead of the loudest voice in the room. They’re never frozen, either: when new evidence contradicts one, it gets challenged and retired, so the system keeps sharpening itself instead of hardening into folklore.

Long story short: the structure turns scattered observations into compounding, trustworthy knowledge — and with the right tool beneath it, that knowledge can supercharge how we decide what to build.

In practice

A few things the standalone repository does that Confluence couldn’t:

• Fuzzy search across everything — any fact, insight, or source by keyword in seconds, even with typos.
• Linked facts ↔ insights — see exactly which evidence backs each insight, and how many independent sources.
• Tag-based filtering by theme (navigation, annotation, workflow, algorithm).
• A built-in review workflow — move through AI-extracted facts quickly, with confidence-based triage so human judgment goes where it matters most.
• Everything live and linked — no exports, no stale copies.

Outcome

• I can point to the exact source and quote behind a design decision — real traceability, which is an asset in a regulated environment.
• The method is written down and repeatable, so processing a study no longer depends on me.
• So far the system holds 409 facts across 15 sources, distilled into 47 insights — with only about half the studies processed. Every one we add makes it more useful.
• Insights now feed opportunities that flow directly into how we decide what to build.
• It has also changed how the business sees research. Because findings now feed visibly and directly back into the product, research has gone from a hard sell to something the business wants to invest in — the opposite of where we started.

What I’d do differently

Two things, neither a real regret — just sooner. I would have committed to the Atomic UX approach earlier rather than circling it. And I would have left Confluence sooner: I tried building a separate tool early on, hit a wall, and backed off because I couldn’t see the path forward. What I learned later is that you don’t always need that path mapped out — sometimes you build the thing so people have something to rally around, and it earns its support from there.