Draft an Interview Synthesis from Approved Notes with AI at the Cursor

Short answer: A UX researcher can speak four verified inputs (an observation, anonymized evidence, a hypothesis and a next question) together with a clear instruction. SpeakLingo is designed to help turn that into a structured synthesis draft at the cursor of a compatible, focused Windows text field. The result is a starting draft. You check every line against your approved notes, restore anything the AI blurred or added, and decide what enters the research record.

This article covers what the output should contain, the conditions to settle before you speak, a setup routine, a worked example with a before-and-after comparison, a reusable spoken template, a role-specific review checklist and a method for measuring time to reviewed output.

An interview synthesis is useful when a teammate can see what the participant did or said, what you infer from it, and what you still need to learn. Those are separate layers, and a draft that blends them is hard to review. Four fields keep them apart:

• Observation: a plain statement of behavior or response, tied to a session or participant code.
• Anonymized evidence: supporting detail from your approved notes, stripped of anything that identifies a person or organization.
• Hypothesis: your interpretation, labeled as unconfirmed.
• Next question: the open question that would test or refine the hypothesis in a later session or through another method.

A fifth item belongs in every draft: a list of missing facts. If the notes do not say what task the participant was attempting, or whether other sessions touched on the same theme, the draft should say so and leave the gap visible. Ask for missing facts in your spoken instruction and name any gaps you already know about, because the AI may not reliably notice what your notes leave out. Review the missing-facts list yourself against the approved notes.

Syping is SpeakLingo's term for speaking plus typing: you talk, and text appears where you would otherwise type. The concept is explained on the Syping page. For this task, where the supported cursor workflow fits, you may be able to avoid opening a separate AI window, pasting notes in, copying the result back and reformatting it, depending on your setup and target field. You speak the instruction and the verified inputs while the cursor sits in your document, repository entry or other compatible text field.

Three SpeakLingo capabilities matter here:

1. Online transcription in 99+ languages, which turns your speech into text.
2. AI contextual formatting, which can arrange that text into a structure such as labeled sections.
3. Spoken AI requests, where you say what you want drafted and text is produced at the focused, compatible Windows text field.

The workflow starts from notes you have already approved. It does not capture interviews as they happen.

These decide whether the workflow suits a given project.

Compatibility. SpeakLingo is not universally compatible. Output goes to a compatible, focused Windows text field. Speak a harmless sentence into your target field before relying on it for a real synthesis. If the field does not respond, draft in a field that does, then move the reviewed text yourself.

Connectivity and access. AI requests need an internet connection, an enabled service, your consent and the necessary access. If any of these is missing, the AI step will not run. Transcription has its own mode, setup and access requirements, so AI being unavailable does not show that transcription is available, and the reverse is also true.

What may leave your machine. Audio and text may be sent to remote services when you use online transcription or AI requests. If you opt in to screen context, what is visible on screen may be sent as well. Speak only content your team has approved for this kind of processing, and close unrelated windows before enabling screen context. Your organization's research-data rules and your participant consent terms determine what you may use. That decision stays with you and your team.

No live interview recording. The review boundary for this workflow excludes recording live interviews and inventing quotes. Any quote in the synthesis comes word for word from your approved notes.

Sending stays with you. The workflow places a draft at your cursor and does not take over your computer. Some setups include an optional behavior that presses Enter after text is delivered, and in some apps that can send a message or submit a form. The setup routine below turns it off for this task.

One boundary matters before you speak. Dictating alone does not enable AI. To get a synthesis draft, use the supported AI Task workflow and put the instruction and every fact it needs in that same request: the observation, the anonymized evidence, the hypothesis and the next question. Earlier dictations, text already in the field and whatever is on your screen are not automatically available to the AI. Screen context is a separate opt-in, and what is visible may be sent to remote services, so do not count on it to supply your notes.

Run through this short routine before the first spoken request.

1. Pick a safe target. Open a draft document or a scratch entry rather than a live chat, ticket or shared channel. Put the cursor in the field.
2. Turn off automatic Enter or send behavior. If your configuration has an option that presses Enter after delivery, switch it off for this task so the text cannot be submitted by accident.
3. Check the inputs. Keep the approved notes beside you. Write the four fields in short form if you want a script to read from.
4. Test the field. Speak one harmless sentence and confirm it lands where expected. Delete it.
5. Close what you do not need. If you have opted in to screen context, close unrelated windows and any material that is not approved for this processing.
6. Speak, then stop. Deliver the instruction and inputs, and read the draft before doing anything else with it.
7. Review before sending or saving. Use the checklist later in this article. Only after review do you save, paste elsewhere or send.

The following is a fictional study of a hypothetical meal-planning app. The participant code, notes and findings are invented to demonstrate the method. They are not real research data and do not describe any real product or participant.

Before: approved but unstructured notes

These are the researcher's notes for session P3, already approved for synthesis and already stripped of identifying details:

P3 – weekly planning task. Skipped “Saved” tab, went straight to search. Said “it felt like a junk drawer” (verbatim, approved). Mentioned a partner also cooks, unclear whether they share the account. Seemed frustrated? Maybe needs folders. Check others. Liked grocery list export. Didn't say whether they'd used the app before this study.

The problems are easy to spot. Observation, mood inference and feature idea run together. “Seemed frustrated” is an impression and has no support in the evidence. “Maybe needs folders” is a solution guess. The partner detail is ambiguous, and nobody has stated how often the pattern appears.

The spoken request

With the cursor in a compatible text field, the researcher speaks the instruction from the template below, filling in the fields:

“Using only these verified inputs, draft an interview synthesis from approved notes. Observation: P3 skipped the Saved tab and went straight to search during a weekly planning task. Anonymized evidence: P3 said, quote, it felt like a junk drawer, end quote, which is verbatim in the approved notes. P3 also mentioned a partner who cooks, and the notes do not say whether the account is shared. The notes do not say whether P3 had used the app before the study. Hypothesis: the Saved tab may lack an organizing structure that supports planning. Next question: how do other participants find previously saved recipes when planning a week? Use a clear professional structure. Flag missing facts; do not invent them.”

The researcher left two things out on purpose. The “seemed frustrated” impression is not in the approved evidence. The folders idea belongs in a later design discussion. The grocery list export comment is a different observation and would get its own entry.

After: a draft to review

A draft might come back along these lines. This is an illustration of plausible output, not observed output from a test, and real output will vary:

Interview synthesis: P3 (illustrative)

Observation During the weekly planning task, P3 skipped the Saved tab and went straight to search.

Anonymized evidence - P3 said “it felt like a junk drawer” (verbatim, from approved notes). - P3 mentioned a partner who also cooks. Whether the account is shared is not stated.

Hypothesis (unconfirmed) The Saved tab may lack an organizing structure that supports weekly planning.

Next question How do other participants find previously saved recipes when planning a week?

Missing facts - Whether P3 had used the app before the session is not recorded. - Whether the account is shared with the partner is not recorded. - It is not stated whether other sessions showed the same behavior.

What the researcher still does

Before the text goes anywhere, the researcher compares the quote to the notes character for character, including punctuation and quotation marks, since spoken quotes may need manual correction. They confirm the hypothesis reads as a possibility and carries no finding language, and check that no identifying detail slipped in. They also look for small wording drift, such as a verb that is stronger than the one in the notes. “Bypassed” in place of “skipped” would be one example. If the AI added a sentence the notes do not support, the researcher deletes it. Only then is the synthesis saved or shared, by the researcher's own action.

Adapt the wording to your own practice. Fill the brackets from your approved notes before you speak, or keep the notes beside you while you speak.

“Using only these verified inputs, draft an interview synthesis from approved notes. Inputs: Observation: [what the participant did or said, with session code]. Anonymized evidence: [approved detail, with any quote exactly as recorded]. Hypothesis: [your interpretation, as unconfirmed]. Next question: [open question for a later session]. Use a clear professional structure. Flag missing facts; do not invent them.”

Optional additions to speak when needed:

• “Keep observation and hypothesis in separate sections.”
• “Mark any statement that is not directly supported by the evidence.”
• “Use short bullet points for evidence.”
• “Do not add quotes beyond those I gave.”
• “List what the notes do not say.”

Treat these additions as requests. The AI may not follow all of them, which is why the review step carries the weight.

This table can guide both your spoken inputs and your review.

If a sentence in the draft fits two rows, split it.

Work through this before the draft leaves your document.

Evidence integrity - Every quote matches the approved notes exactly, including wording and punctuation. - No quote appears that you did not supply. - Paraphrases are not placed inside quotation marks. - Counts, frequencies and sample references come from your notes. If the draft states a number, verify it yourself.

Anonymization and permissions - No names, workplaces, locations or other identifying details appear. - The content you spoke was cleared for this kind of processing under your team's rules and participant consent. - If you opted in to screen context, nothing unapproved was visible.

Separation of layers - Observations describe what happened and leave out how it seemed to you. - The hypothesis is worded as a possibility. - The next question is open and does not steer the answer.

Completeness - The missing-facts list is accurate, and nothing the notes do contain is wrongly marked missing. - You fill gaps from your own records, citing the source notes. The AI does not fill them.

Fitness for the audience and delivery - The structure matches your repository or report conventions. - Wording is neutral enough for stakeholders who were not in the session. - Automatic Enter or send behavior was off, and nothing was submitted before you read the draft. - You have decided whether and where to send or store it.

Avoid claiming a speed benefit before you have your own evidence. Define the finish line as reviewed output: a synthesis you would be willing to file or share after checking it against the notes. A raw first draft does not meet that definition.

1. Choose a start point. For example, the moment your notes are approved for synthesis.
2. Choose an end point. The moment the reviewed synthesis is saved in its final location.
3. Log the stages separately. Note time spent preparing inputs, speaking the request, reviewing and correcting, and moving the text if needed. Include review time, because the finish line depends on it.
4. Compare like with like. Use sessions of similar length and complexity, and compare against how you normally write a synthesis.
5. Record the kinds of edits. Quotes fixed, claims removed, structure changed and gaps filled each show whether your inputs or your spoken instruction need adjusting.
6. Repeat over several sessions before drawing a conclusion, and keep the log as your own working record. A single session tells you little.

If the review stage grows because you are correcting many unsupported statements, tighten the inputs and the instruction before drawing conclusions about the workflow.

Online transcription supports 99+ languages, so you can speak in a supported language appropriate to you and your team. Transcription is not translation, and AI output is not guaranteed in every language. If your team writes syntheses in one language and your notes are in another, handle that step yourself and review the result closely. Run a short test in your language before using it for real material.

If the connection is interrupted, AI requests cannot run, so a structured draft would have to wait or be written by hand. Transcription has its own setup and access requirements, so AI being unavailable does not prove that transcription is available. Offline English transcription is only a fallback, and it works only if you have configured it beforehand. Plan for that before a deadline.