KADE
A research synthesis tool built outside client hours, to give researchers back the three to seven days every study lost to transcript cleanup and manual clustering.
- Role
- Product Design + Build
- Timeline
- 2026 · Built outside client hours
- Platform
- Web app
- Type
- 0 → 1 · 3rd of 15+ teams at the hackathon
- Team
- Two of us. I owned the design and the build
At a glance
Problem
Every study on the project lost the same three to seven days. Someone from the client side sat in on every call just to press record, transcripts were cleaned by hand in a three-step prompt sequence, German interviews were translated manually, and the clustering happened on a Mural board the rest of the organisation never opened. None of that work produces insight. All of it has to happen before insight can.
Approach
Talk to four researchers before writing production code, then build what they actually asked for. They all said a version of the same thing: AI should do the evidence work, humans have to stay in charge of what it means. So it shipped as two modes, an AI synthesis path and a manual coding workspace, because speed and trust are different jobs.
Outcome
A working tool whose report goes into the organisation's own Confluence exactly as it comes out, nothing to rewrite, for about €2.30 a study, against €6,000 to €36,000 a year in licensing for a commercial alternative at the same team size. Third of more than fifteen teams at the hackathon.
3rd
Of 15+ teams at the hackathon
3-7 days
Of synthesis per study, before KADE
~€2.30
To run a six-interview study
4
Researchers interviewed before any production code
The problem
The problem nobody was measuring
Every research initiative on the project followed the same quiet, expensive pattern. A researcher runs six interviews. Someone from the client side has to join every call just to press record, because outside tools are not permitted on that infrastructure. When a recording fails mid session, which happens more often than anyone would like, the session restarts from a backup.
Once a recording exists it is uploaded, transcribed and cleaned through a three-step manual prompt sequence: strip the timestamps, assign the speaker roles, anonymise the names. If the interview was in German, someone translates it by hand next. Only then does synthesis begin. Reading, re-reading, clustering sticky notes on a Mural board, writing up themes. And somewhere between that board and Confluence, where the rest of the organisation actually looks for things, most of it quietly disappears.
Nobody had put a number on this, so I did. A study of six interviews, done properly, was taking three to seven days of active synthesis spread across one to two weeks of elapsed time. Multiply that by the studies a design team runs in a year and you are looking at weeks of skilled research time spent on transcript cleanup and manual clustering, work that produces no new insight, only the conditions for insight to eventually happen.
- ✺A client-side colleague has to sit in on every call just to press record
- ✺Transcripts cleaned by hand: timestamps, speaker roles, anonymisation
- ✺German interviews translated manually before synthesis can start
- ✺Clustering lives on a Mural board the wider organisation never opens
- ✺Three to seven days per study before a single new insight exists
“AI should do the evidence work. Humans have to stay in charge of what it means.”
Business case
What the old way cost, and what this one does
Two costs sit behind this tool. The one everybody feels is researcher time: three to seven days a study on work that generates no insight of its own. The one that decides whether an internal tool is allowed to exist is the running bill, so I costed that too, and took both numbers into the stakeholder conversations.
3-7 days
Active synthesis per six-interview study
Spread across one to two weeks of elapsed time, before anything reaches Confluence
€6k-36k
A year in licensing, commercial alternative
Published pricing for a comparable tool at this team size
~€2.30
To run one study on KADE
About €140 to €250 a month for twenty researchers, and €0 on the local path
Honest about all three. The three to seven days is my own measurement of how the work was actually running on this project, not a controlled study, and the tool does not delete all of it: it removes the cleanup and the first pass at clustering, and the researcher still owns the judgement. The licensing range is published pricing rather than a quote anyone gave us. The running cost is directional, taken from the rates the app is configured with, and transcription is roughly nine tenths of it.
Process
How I approached it
- 01
Talked to four researchers before writing production code
A researcher in the trade show industry who ran Rose, Thorn, Bud and was already feeding her manual affinity clusters into an AI tool to speed up How Might We. A colleague on our own team who described, unprompted, the feature I had not thought to build: tag one transcript, have the system suggest the same tags across the rest, and you just verify them. A senior researcher out of banking and C-level work, candid that she had disagreed with AI-generated insights 'a lot of the time', and that text alone loses something, because you cannot tell from a transcript whether someone's 'okay' was resigned or genuine. And a fourth who wanted the system to show its confidence: 'This is something I'm 100% sure of because all users said it. This is something I'm 40% sure of.'
- 02
Let their one shared answer be the brief
Four people, four contexts, nothing coordinated between them, and one consistent message: AI should do the evidence work, humans have to stay in charge of what it means. That sentence became the brief, and every decision after it was judged against that rather than against how impressive the automation could look.
- 03
Built two tools instead of one
The instinct in most AI research products is a single pipeline: transcripts in, insights out, trust the model. Every researcher I spoke to told me in their own words why that was wrong here. So the AI path reads every transcript, pulls behaviours, friction points and verbatim quotes per interview, then looks across all of them for patterns that genuinely recur, each one traceable back to the participant and the file it came from. The coding workspace is for the researcher who does not want the model's first read to be the final word: transcript list, reader and code library in three panes, tags they build themselves, and a patterns view showing which tags recur across transcripts and which appeared once. Neither mode is a compromised version of the other.
- 04
Made the report shape follow the question the study asked
A study exploring a new problem produces a behavioural pattern with a 'because' attached, explaining why people do what they do. A study testing a specific concept produces a reaction to something that was shown, tied to a screen or a flow, not a general truth about behaviour. Early versions forced both into one format, and it showed: a study built to evaluate a redesigned interface kept coming back as a list of unrelated complaints about the existing system. Technically accurate, and an answer to the wrong question. The fix was not a better instruction. It was asking, before synthesis begins, what this study was trying to learn, and shaping everything downstream around that.
- 05
Put the cost in the architecture
Per-interview extraction is repetitive work, so it runs in parallel on a cheap model. Synthesis across interviews is the only part that needs real reasoning, so that is where the expensive model gets spent. Run the app on your own machine and it can drive your own logged-in AI CLI or a local model instead, which costs the budget nothing and keeps client data off any outside service.
- 06
Ended where the organisation actually looks
The report comes out as a finished document that a researcher uploads straight into Confluence. Nothing to reformat, nothing to rewrite, no separate vendor, and nothing leaving the client's infrastructure. Once it is there the organisation's own search can find it. The gap between the Mural board and the place people actually go looking was half the original problem, so shipping without closing it would have missed the point.
Craft
Decisions worth defending
Suggest, never auto-apply
In the coding workspace the model can propose the tags a researcher already defined across the rest of the transcripts, and that is the whole of its authority. Every suggestion needs confirmation. The feature came from a researcher who asked for it unprompted, and so did the constraint on it.
Confidence in the headline can never exceed confidence in the evidence
A finding from one person reads as one participant everywhere it appears: in the evidence table, in the theme label, and in the first sentence a stakeholder reads. The counts are computed after the model returns rather than written alongside the prose, because that is the only version a deadline cannot talk out of it.
Two modes, not one opinionated pipeline
A quick first pass when speed matters, and full manual control when trust matters more. Offering both costs more to build and to explain than picking one, and it is the reason a sceptical researcher can use this at all rather than being asked to take the model's word for their own study.
Nothing leaves the client's infrastructure
Outside tools are not permitted there, which is not a detail to design around. It is the reason someone had to sit on every call in the first place. Publishing lands in the organisation's own Confluence, and the local path runs the entire pipeline without a vendor API key at all.
Reading surfaces stay still
There is an ambient particle field on the upload and processing screens, where you are waiting with nothing to do, and nowhere else. The transcript reader, the coding workspace and the report carry no motion at all. Ambience belongs to the waiting, never to the reading.
The export is the deliverable, not a data dump
The report that leaves the tool is the thing colleagues read, so it is typeset from the same tokens as the app rather than dumped as raw output. That is what makes the last step an upload rather than an evening of reformatting, and it is why the deliverable does not look like it came from a different product than the one that made it.
Built with AI
Designed and built with AI
I designed KADE and built it, front to back: the app, the pipeline behind it, the prompts, and the export templates, with Claude as the pair, almost entirely outside client hours. That is the second reason these cost numbers exist. When you are the one wiring up the model calls, the per-token bill becomes a design material rather than something you hand to someone else and hope about.
It also changed what a design decision looks like. 'The report should be honest about how many people said it' is a nice principle in a deck. In the build it became a rule that the headline can never claim more confidence than the evidence table, which is the version that survives contact with a stakeholder readout.
Honest reflection
What it taught me
The most useful thing I did in the entire build was hold my own tool up against a careful human report and find it wanting.
What changed in the process
Compare against the best human alternative, early
I ran the same three transcripts through KADE and through a research report a person had written. The human report told a clean story: participants understood a proposed redesign, liked its logic, and the one point of confusion had already been caught and fixed in a follow-up round. KADE opened with something close to 'salespeople are losing cars and customers because of a system failure', built almost entirely on a single participant's account. Both were using real evidence. Only one was being honest about how much of it there was.
The data can be right while the prose lies
The underlying table was already calibrated: it labelled findings 1 of 3 and 2 of 3 accurately. The executive summary was not carrying that forward, so one person's account was being written up with the confidence of a team-wide pattern. Nothing about the intelligence had to change. What changed was a discipline no prompt had enforced: match the story to the sample size, every time, without exception. It is a small rule, and it is the difference between a report a sceptical stakeholder trusts and one that gets torn apart in the first two minutes of a readout.
Four conversations beat any amount of solo speculation
One researcher handed me a feature I had not thought of. Another handed me the constraint that shaped the entire manual mode. A third told me exactly which part of an interview a transcript cannot carry. None of that was reachable by thinking harder on my own, and all of it arrived before there was any code to be precious about.
What I got wrong
I built one report shape for two different questions
A study run to evaluate a specific redesign kept coming back as a list of unrelated complaints about the existing system. I kept trying to fix it with better wording in the prompt, when the actual problem was that an exploratory finding and a reaction to something you showed someone are structurally different things. Rebuilding around that was more work than I wanted at the time and the only thing that could have worked.
My own tool overclaimed, and I nearly did not notice
The dramatic headline read well. It was persuasive, quotable, and standing on one participant. If I had not run the comparison against a human report, the first person to catch it would have been a stakeholder in a readout, which is the worst possible place to discover your tool is confident and wrong.
I raised the ceiling on one side and broke the other
I expanded the synthesis instructions with a full report standard, and every report started failing. The model was hitting its output limit and stopping mid-sentence, so the parser died and the app showed a flat 'Analysis failed'. A longer report needs both a bigger output ceiling and a longer timeout. The fix I care about more is that the failure now names the exact limit it hit instead of shrugging.
Outcome
What shipped
Upload recordings or transcripts directly, audio, video or text. It transcribes automatically with speaker detection, and translates German to English on demand while preserving every quote exactly as spoken. It generates a full report, themes, workarounds and scope-tagged recommendations, or hands control to the researcher in the coding workspace. The finished report goes straight into Confluence as it is, with nothing extra to write, immediately searchable by the organisation's own tools, with no separate vendor and no data leaving the client's infrastructure.
It costs roughly €2.30 to run a six-interview study, against €6,000 to €36,000 a year in licensing for a commercial alternative at the same team size, and the local path costs nothing at all. That turns the approval conversation from a guess into arithmetic.
We took it to the hackathon and placed third out of more than fifteen teams, in the category recognising the steepest learning curve and the heaviest experimentation with AI, presenting to a panel of client stakeholders, product owners and experience design leads. I owned the design and the build, with a colleague joining for the sprint. Third, for a tool built almost entirely outside client hours against teams with dedicated engineering time, is a real result rather than a consolation.
The placement is not the part I care about most. What came after it is. The tool was validated internally, and what we walked away with was a mandate to keep working with the research team rather than a certificate. The moment that actually meant something was a senior researcher who had told me flat out that she does not trust AI synthesis by default, saying she would use this one. An honesty rule is only worth anything if it convinces the person with every reason to reject it.
What I'd tell someone starting something like this
Talk to the people who will have to trust the thing before you build anything they have to trust. Compare your output against the best human alternative you can find, early and often: the gap between what KADE said and what a careful researcher said was not a failure, it was the most useful finding of the build, because it showed exactly where the tool needed to be more honest rather than more capable. And build something that respects the judgement of the people you built it for. Every researcher I spoke to said a version of the same sentence: do not replace our thinking, help us do it faster. KADE only works because it holds that line.