Product
Twelve interviews recorded, two of them read
Themes with participant counts and verbatim quotes, plus a flag wherever the evidence is thin.
What the worker does
User research synthesis with an AI worker means the transcripts get read. The worker is given a folder of interview transcripts through the Google Drive connection, reads all of them, and returns themes with the exact quote that supports each one, the number of participants who raised it, and an explicit note where a theme rests on one or two people. The synthesis document arrives attached to the task.
- Input
- A folder of transcripts
- Connections
- Google Drive, Notion
- Output
- Themes, quotes, counts
The research that got done and never got used
Twelve conversations, roughly fourteen hours of recording, and a transcript folder that fills up faster than anyone opens it. The person who ran the interviews remembers the two that were vivid. The rest inform nothing, which means the research budget bought a feeling rather than a finding.
Reading twelve transcripts properly takes most of a day. It is the kind of task that never wins against anything urgent, and it stays undone until the quarter ends and the folder is stale.
What good synthesis output looks like
The rules worth writing into the worker's skill file, because they are what separate a synthesis from a summary.
Every theme carries a verbatim quote
Not a paraphrase. The participant's own words, with the participant identifier, so anyone can go back to the transcript and check.
Counts are stated, not implied
Four of twelve participants, not many participants. The difference decides whether a theme is a finding or a coincidence.
Thin evidence is labelled thin
A theme built on one person is worth recording and worth flagging. Instruct the worker to mark it rather than to promote it into the same list as everything else.
Disagreement survives
Where participants contradicted each other, both sides appear. Synthesis that resolves every tension has smoothed away the interesting part.
The shape of the delivered document
| Section | Contents |
|---|---|
| Method | How many participants, which segment, dates of the sessions |
| Themes | Each with a participant count, verbatim quotes and an evidence strength note |
| Contradictions | Where participants disagreed, with both quotes |
| Unanswered | Questions the interviews raise but do not answer |
| Source map | Which transcript each quote came from |
Where the synthesis lands
The delivery is a comment on the task with the synthesis document attached. In Polaris, documents are versioned and support review comments, so the synthesis can be argued with in place rather than forwarded around as an attachment that forks into four versions.
The task stays open until you close it. Closing is where you decide the synthesis is fair, and the rating you leave is the review that informs the next run.
Questions people ask
+Does the worker transcribe recordings?
No. It reads transcripts and notes you already have in Google Drive. Recording and transcription stay with whatever tool you use today, and the worker picks up from the text.
+How is this different from usability testing synthesis?
Discovery interviews produce themes about problems, needs and context. Usability sessions produce task-level failures: where someone hesitated, what they clicked, what they could not find. The output shapes differ enough that they are briefed as separate jobs.
+Can I trust the quotes?
They are copied from the transcripts and each one names its source file, so any quote can be checked in under a minute. Requiring a source reference per quote is worth writing into the task acceptance criteria, which the worker ticks as it works.
+What if the transcripts are in different formats?
Mixed notes and transcripts in one folder are normal and the worker handles them, but the method section of the delivery will say what it was working from. A synthesis built partly on rough notes is weaker evidence, and the document should say so.
Related
Product management with an AI worker on the roster
Five jobs a product team can hand to an AI teammate, and the ones it should never hand over.
Eight sessions recorded, and the same hesitation in six of them
Session notes turned into a task-by-task table of where people stalled and what they said.
Sixty requests, and no idea how many people asked
Clustered requests with a real count of who asked, so the argument is about value rather than recall.
Connect Google Drive to Polaris
Files a worker produces already arrive as attachments on the task. Files your team already keeps in Drive are the part still waiting.
Hire an AI research analyst
Assign the question on Tuesday afternoon and read the brief before your Wednesday call, with every claim carrying the URL it came from.
When the deliverable is a file
A chat reply is not a deliverable if the thing you needed was a document somebody can open.
Delivery comment
Work arrives where the task already lives, attributed and reviewable, and the task stays open.