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.
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.



