Kaleidoscope: my own research engine
Synthesis was eating my week: five evidence sources, one insight, endless tab-hopping. So I designed and built the tool that does the fetching, and gave it to the team.
In 30 seconds
- Problem
- Evidence lived in five places. One readout meant a day of tab-hopping before any thinking started.
- What I did
- Designed and built a tool that fetches, cross-checks and drafts, with every claim traced to a source.
- What changed
- Readouts now start from a sourced first draft I edit. The time goes into judgement, not retrieval.
01 · The problem
Retrieval kills momentum
A good readout (the research summary for stakeholders) is mostly logistics. Find the relevant study. Pull the right survey responses. Match a quote to its transcript. Check it against last quarter's report. Only then do you get to think.
Most of that is retrieval, and retrieval is exactly the part that doesn't need me. But it's also the part that quietly kills momentum: by the time you've gathered everything, you've lost the thread you started with. The evidence lived in five different places, and stitching a readout together by hand meant tab-hopping until the insight went cold.
There's a second, worse failure. When synthesis is expensive, it doesn't get repeated. Years of research had already been paid for and sat unread, so every new question got answered from whatever three decks someone happened to remember.
02 · What I did
Design the workflow, then build it
- Workflow before code. I mapped how I actually build a readout, where I start, what I reach for, in what order, and designed the tool around that path instead of around the data sources. It gathers from all five places, cross-checks them, and produces an evidence-backed one-pager as a starting point, not a finished answer. It also proposes a report storyline and adapts the content to the target group; every step can be steered manually.
- Triangulate, don't summarize. The useful output isn't what each source said. It's where the sources converge, where they diverge, and where there's a hole. The gap between what people say in interviews and what they do in analytics is usually the finding. A summary flattens that. This doesn't.
- Evidence non-optional. Every claim in the output traces back to a source. It won't hand me a confident sentence with nothing underneath: exactly the restraint my AI assistant research kept asking the product to practice. The tool practices what I preach.
- Participant data handled properly. Interview transcripts are cleaned of personal data before they're indexed. A research tool that quietly pools raw participant data is a liability, and "it's internal" is not a defence. Getting this right was the precondition for anyone else using it.
- Packaged for the team. A tool only I can run is a party trick. I turned it into something colleagues install themselves: clean setup, no secrets baked in, nobody's configuration touched. One install, and a colleague has the same engine I do. New evidence sources plug in over the open standard for connecting AI tools to data (MCP), so the engine grows with the evidence. Right now it is being rolled out to the whole product organisation, with almost no setup on their side.
03 · What came out
Judgement instead of fetching
Readout assembly went from a day of tab-hopping to a first draft I edit. The team got a shared, repeatable way to synthesize across sources: the analysis stops depending on who happens to know where everything lives.
And because every output is sourced, "trust me" stopped being an acceptable answer. Even from me.
A researcher who designs and, apparently, a designer who ships.