A RESEARCH ASSISTANT THAT SHOWS ITS EVIDENCE, AND ITS GAPS

A RESEARCH ASSISTANT THAT SHOWS ITS EVIDENCE, AND ITS GAPS

Role

Design engineer & builder

Team

Solo, private project

Timeline

7 days

Status

Prototype

Services

AI ENGINEERING

PROTOTYPING

RESEARCH SYNTHESIS

WORKFLOW OPTIMISATION

Overview

A seven-day prototype that reads research notes and journey maps as one body of evidence. The real design problem turned out to be trust: showing where each insight came from, and saying so when the evidence wasn’t there.

7

days from question to tested prototype

3 → 1

sources read as one body of evidence

0 of 3

insights fully linked on thin research, until the check I added flagged it

01

Context

The slow half of a project

• Constraints

AI as a product problem

Not a design tool. I scoped it to discovery and analysis, the stretch of a project where the hours disappear and nothing looks like progress.

Sample research, real pipeline

Python on the Claude API, tested on sample research I wrote myself, modelled on public-service journeys. No real citizen data.

02

Role

Designer and builder

Rather than approaching AI as a design tool, I treated it as a product problem: where could it support the research, discovery and analysis work that normally takes the most time?

What I did

Framed the problem and set the success criteria

Designed the workflow and its data structure

Tested it on thin sample research, then added a completeness check

Built with

Python

Claude API

Markdown files and Notion databases

03

Problem

Three sources, linked by hand

At the Dutch Tax Authority and DigiD I hit the same wall twice. Research findings, journey maps and service documentation sat in separate places, in separate formats. Every time I needed to know where users struggled, and what evidence sat behind a conclusion, I linked the sources by hand.

• What I kept running into

Linking took longer than analysing

Connecting evidence across three separate documents ate more time than the analysis itself.

Hours with nothing to show

Every question about where users struggled meant cross-referencing by hand, and none of it showed up as progress.

Untraceable means indefensible

An insight I couldn’t trace back to a quote was one I couldn’t defend in a room, so I checked it by hand again.

04

Opportunity

One pass over all the evidence

An assistant that reads the research notes, journey maps and service context in one pass, and hands back the risks along with the questions nobody has answered yet.

• Hypothesis

If I structured the research first, working through a complex service journey should take a fraction of the time it used to.

• Success criteria

Traceability: every insight leads back to its source.

Synthesis: findings cluster without rereading transcripts.

Evidence: every opportunity stays tied to the research.

The loop: every insight stays traceable in both directions

05

Prototype

A small Python app on the Claude API

I built it in Python on the Claude API, with the research held in structured markdown files. The test was simple: could it pull journey steps and research findings into one analysis?

• Input

Journey steps, research notes and themes, from markdown and Notion.

• Decision: structure first

Every note carries its research type, evidence strength and journey step, so an insight can always point back.

• Decision: room for doubt

Every insight has a confidence field and a place for an open question.

main.py reads from Notion, asks Claude, and writes the insights back

The concept: research in, risks and open questions out

The pipeline: markdown, Python, Claude API, JSON, report

06

Reliability

Making it say what it doesn’t know

The first runs read convincingly. Then I fed it research I knew was thin. It still wrote confident conclusions, and nothing showed which ones had no evidence behind them.

• What went wrong

On thin evidence it wrote conclusions with more confidence than they had earned.

• My decision

A completeness check before anything is saved: every insight needs evidence, a journey step and a theme, or the run says so.

• Result

The same thin research now comes back flagged, and the model used the room for doubt: low confidence, open questions instead of answers.

The check: 0 of 3 insights fully linked, flagged in the run

In Notion: low confidence and open questions instead of answers

07

Outcome

What held, and what didn’t

No users and no launch. I never timed it against doing the work by hand, so the speed claim stays a hypothesis. What I could judge were the three criteria.

• Traceability · held

Every insight that was linked led straight back to its quote and journey step, so checking the reasoning took one click instead of a search.

• Synthesis - partly held

With full research, findings clustered into themes I recognised. With thin research, the clusters were thin too.

• Evidence · partly held

The structure kept opportunities tied to research, but the thin run showed 0 of 3 insights fully linked until the check flagged it.

• Traceability · held

Every insight that was linked led straight back to its quote and journey step, so checking the reasoning took one click instead of a search.

• Synthesis - partly held

With full research, findings clustered into themes I recognised. With thin research, the clusters were thin too.

• Evidence · partly held

The structure kept opportunities tied to research, but the thin run showed 0 of 3 insights fully linked until the check flagged it.

08

Reflection

Trust is the part worth designing

I came out of this less interested in what AI can produce. The part worth designing is the one that shows people where an insight came from, so they can decide for themselves whether to act on it.

• Key learnings

Generating is the easy part

Insights came quickly. Making them transparent and evidence-based enough to support a decision was the real work.

Show the source, or people check by hand

Put the evidence next to the answer, or people will go and check it by hand anyway.

The judgement stays with the team

AI sped up the sorting. Deciding which risk matters, and what to do about it, stayed with me, and in a product team it should stay with the team.