Wispr Flow: keep control of the words after you speak
Wispr Flow turns speech into text where you are writing, then handles formatting and clear corrections. It helps people move from an idea to a readable draft while keeping a way to retrieve the original transcript.
Form your own approach first, then explore the reasoning to check trade-offs and validation you may have missed. There is no single right answer.
How can users recover meaning without losing later edits?
Scenario
Design your own voice-input tool. A user dictates “Meet on Tuesday—no, make that Wednesday. Please read the agenda first and bring the budget.” The cleaned-up result gets the date right but omits the budget request. The user has already pasted it into an email and manually added the recipient’s name. Help them recover the missing meaning while preserving those later edits; you do not need to reproduce Flow.
Known material and constraints
- The tool retains the raw transcript and the cleaned-up version of this dictation. The raw transcript can also contain recognition errors; it is not an infallible record of the audio. You cannot automatically determine the user’s true intent.
- The tool can display and copy either version but has no permission to read or modify the current external email. Do not promise that Restore automatically replaces it, or lose the recipient’s name added afterward.
- Users may compare versions, retrieve the raw transcript and return to the cleaned-up version. States must explain what is displayed, what has been copied and what remains for the user to fix in the email.
- Keep ordinary short sentences low-interruption, while making changes to dates, quantities or negation more noticeable. Do not turn every dictation into an extended review session.
Check these examples
Example A is the message with the missing budget request. Example B is “Actually, I prefer the first version,” where “actually” is ordinary expression, not an instruction to delete prior text. Explain comparison and recovery. Also consider a raw transcript that mishears “budget” as “proposal.”
Deliverables
Sketch four states: cleanup complete, comparison, raw text copied and return to the external email. Write version labels and copy feedback. Compare mandatory confirmation of everything with prompts for key changes and comparison on demand. Propose two observation tasks: recovering the omitted request, and fixing the email while keeping the recipient’s name. Describe the study; do not invent completion rates.
Explore the reasoning
- Separate three objects. The raw transcript, cleaned-up text and external email are distinct. The tool controls the first two, not subsequent manual edits in the email. Make that permission boundary clear in the interface.
- Make changes easy to locate. Highlight dates, quantities, negatives and whole-clause changes, with a full comparison available on demand. Key-change prompts are a design hypothesis to test, not proof that the system knows the intended meaning.
- Recover a version, not a fact. Retrieving the raw text can restore a deleted budget request. If it already says “proposal,” manual correction or checking the audio is still necessary. Use example B to reject mechanical keyword-based deletion.
- Explain external repair. After copying, identify the copied version and direct the user back to the email for a local correction. Avoid encouraging a full replacement that erases the added name. Switching back to cleaned-up text should not erase feedback about what was copied.
- Observe interruption costs. Test recovery of omitted meaning and preservation of external edits, then use ordinary short sentences to observe unnecessary interruptions. Record confusion by object and action before comparing the two designs.