Write Clear Acceptance Criteria Faster with Voice Dictation

“Let people save a draft” sounds straightforward until someone asks what happens when the title is empty or whether saving also publishes the page. You may be able to explain the intended behavior aloud while the task description remains unwritten.

Voice dictation gives that explanation a place to start. Speak through one scenario, then edit the text into acceptance criteria: the observable results required to accept the work. See Atlassian’s acceptance criteria overview for the underlying concept. The voice-first drafting routine below is a practical way to put it into writing.

1. Open the task before you start speaking

On your Mac, place the task description beside the relevant design or agreed notes. Choose one small behavior, not the entire feature. For example, describe saving a draft manually; leave scheduling, publishing, and automatic saving for separate discussions unless they are already in scope.

Write a short goal first: “An editor can save unfinished work and return to it later.” This keeps the spoken draft focused on the person using the feature.

2. Dictate a walkthrough with five prompts

Imagine showing a colleague what should happen. Pause between these questions:

• Who: Which person or role is using the feature?
• Starting point: What is already true before they act?
• Action: What do they do?
• Result: What should they be able to observe afterward?
• Exception: What should happen in one relevant unsuccessful case?

Say “open question” before anything the team has not decided. You can move those statements into a separate section during editing, without accidentally turning a possibility into a requirement.

3. Turn the spoken draft into checkable statements

Here is a fictional example, not a description of TypeFree functionality:

The editor has an unpublished article with a title and some text. They save the draft and see a confirmation. When they reopen it, the title and text are still there. It should not show up publicly. If the title is blank, ask them to add one and do not save. We have not decided about automatic saving.

After dictating, organize that into a proposed review checklist:

1. An editor saving an unpublished article with a nonempty title sees confirmation when the save succeeds.
2. Reopening the saved draft restores the title and body from that save.
3. Saving the draft does not make the article publicly visible.
4. Attempting to save with an empty title shows a message requesting a title and does not save changes.

Keep “Should automatic saving be included?” under Open questions, outside the agreed criteria. These example rules are proposals for the fictional feature; your team should choose its own behavior.

4. Review meaning before polishing wording

Check words such as “not,” “only,” “empty,” and “unpublished” against the intended behavior. A missed negation can reverse a requirement. Copy exact button labels from the design rather than relying on their transcription.

Then read each item as a reviewer: what would I do, and what would show that it passed? If you wrote “saves quickly,” ask which timing and conditions the team actually needs. Do not invent a threshold to make the sentence look precise.

Separate implementation ideas from user-visible outcomes. If your spoken draft wandered into storage choices or internal naming, move that material into technical notes for discussion.

5. Resolve the questions with the team

Share the criteria as a draft, with the unresolved decisions visible. Ask the people building and reviewing the feature to check the scenarios before treating the list as agreed scope. Dictation captures your explanation; it does not establish agreement or prove that the feature works.

For adjacent writing tasks, try drafting project briefs by voice and writing clearer bug reports.

TypeFree is a simple way to turn speech into editable text and write faster. Start with one feature scenario, speak the expected behavior, and review the resulting text before adding it to your task.