Add Voice to App Prototypes Before Your API Exists

The first version of a voice experience is usually silent. Product teams leave the spoken moments for later because the API is not chosen, the backend does not exist, or nobody wants to guess at runtime behavior.

That is sensible for infrastructure. It is a poor reason to postpone the experience. A silent prototype cannot tell you whether a confirmation feels reassuring, whether an error message talks over the next task, or whether users understand that a voice cue is optional. It only tests the screen around the voice.

The useful middle ground is a rendered-asset prototype: a small, named set of audio files that play at intentional points in a prototype. Vois gives the product team a local place to generate, revise, and export those reviewed assets while the app's runtime remains deliberately undecided. You test language, timing, state coverage, and interruption now without pretending that the prototype has live speech generation.

Prototype the experience, not a fictional integration

A voice prototype needs one clear boundary. It is testing the behavior around an audio asset, not proving that the final product can synthesize speech at runtime.

Vois is a desktop-local voice production app. Use it to render and export the audio participants hear while the source script and generation work stay on the desktop. It is not a runtime SDK for your application, and a prototype click that plays a pre-rendered file is not an API integration.

The prototype captures wording, cue placement, mute and replay behavior, and rendered assets. Engineering later chooses the runtime and playback design. If a flow only feels good with a hand-operated soundtrack, write that gap in the prototype notes.

Start with state coverage, not a list of nice phrases

A welcome line is easy to imagine. The difficult and valuable moments are the ones where the user is waiting, blocked, interrupted, or unsure whether their action worked.

Make a state map before you generate a file. Start with the task a participant must complete, then list the changes that alter their next action. A small checkout or onboarding flow might look like this:

State	What the user needs to know	Stable prompt ID	Audio decision
Entry	What this step is for	onboarding.start	Optional spoken orientation on request
Waiting	The action is still in progress	profile.save_pending	Usually silent or a brief, non-blocking cue
Success	The action completed and what happens next	profile.save_complete	Short confirmation, never the only confirmation
Empty result	There is nothing to select and a next step exists	search.no_results	Explain the next useful action if testing shows it helps
Validation error	What failed and how to correct it	payment.card_invalid	Optional replayable detail after visible error text
Permission choice	Why a permission is requested	location.permission_explainer	Play only after an intentional user action
Interrupted task	What was saved, lost, or can be resumed	upload.interrupted	Clear recovery information, not a vague apology

The point is not to generate speech for every row. Voice should earn its place. A sound cue may be better for a low-stakes confirmation. Silence may be better while a user is concentrating. The prototype should make those choices visible enough to test.

For each selected line, write the visible UI text, the prototype's spoken copy, and the assistive-technology requirement separately. They may overlap, but they are not interchangeable. "Your settings were saved" can be visible text and a programmatic status message. A spoken version might be optional, shorter, or absent entirely.

Give every line a stable prompt ID

A prompt ID is a semantic handle for a moment in the product. It should stay stable when punctuation changes, a designer revises the wording, or a new audio revision is exported. It is not the filename and it is not the final sentence.

Use an ID that describes the product state, such as billing.invoice_ready or auth.code_invalid. Avoid audio_17, new_new_final, or an ID based on the exact copy. Those names become useless as soon as the prototype grows.

Then use deterministic asset names built from the ID:

{prompt-id}.{locale}.{voice-label}.v{revision}.{extension}

profile.save_complete.en-US.voice-01.v03.wav
payment.card_invalid.en-US.voice-01.v02.wav

Keep a manifest next to the assets. It needs the prompt ID, source copy, state and trigger, visible fallback, audio behavior, output file, revision, and owner. That record turns a batch of audio into a handoff artifact and prevents a stale line from being tested after visible copy changes.

Generate locally, then listen in context

Generate selected lines locally into the prototype's asset folder, then review them in the actual task on the device participants will use. Use one primary voice unless a speaker change carries meaning, and record its label in the manifest. A cloned voice needs a clear 10 to 15 second sample and permission. This local production step does not choose the shipped app's runtime or playback path.

Time speech around user intent

Most bad prototype audio is not bad because of the voice. It is bad because the product plays it at the wrong moment.

Before testing, write timing rules for the start trigger, cancellation, priority when prompts collide, replay, and a muted fallback. A cue must yield to typing, navigation, or a new task. Do not queue celebratory messages or use sound as proof that an action succeeded.

For web experiences, WCAG 2.2 Success Criterion 1.4.2 says audio that starts automatically for more than three seconds needs a way to pause, stop, or control volume independently. Avoid unsolicited audio, let people initiate it when possible, and always leave a clear way out.

Design accessibility states on a separate channel

A voice cue is not a screen-reader announcement. A screen-reader announcement is not a caption. A visible status message is not automatically a useful spoken prompt. Treat each channel deliberately.

When an app's state changes, give users an equivalent path that does not depend on hearing a file. That usually means visible text, programmatically communicated status information where appropriate, and controls that work with keyboard and assistive technology. W3C's guidance on status messages explains why a waiting state, progress update, error, or success message must be available to assistive technologies even when it does not take focus.

In the prototype, test these questions:

• Can someone understand the result with audio muted?
• Can someone stop, mute, or replay the audio without losing the task?
• Does the visible copy remain understandable if the spoken line is skipped?
• Does the prototype avoid talking over a screen reader or another assistive technology?
• Are voice and sound cues optional rather than the only signal for an error, permission, or completed action?

See our accessible audio content guide for the same distinction in media. Keep prototype voice optional and secondary to the information the interface must provide.

Tell participants what is real and what is rendered

A prototype can use a stand-in without misleading participants. Say before a session: "Some voice moments are prerecorded examples. The app is not calling a live voice service. We are testing wording, timing, and controls." This lets people flag awkward behavior instead of judging a service the prototype does not run.

Test again after meaningful changes with people who use the relevant tasks and assistive technology. Do not turn one participant's preference into a universal rule.

Hand product engineering an asset package, not a recording folder

When the prototype is ready to leave design, package the decisions that engineering needs:

1. The manifest with prompt IDs, copy, triggers, files, revisions, and owners.
2. The rendered assets in their deterministic names, plus a single source folder for approved exports.
3. Timing rules for start, cancellation, priority, replay, and muted fallback.
4. State coverage showing which states intentionally have no voice.
5. Accessibility requirements for visible status, programmatic announcements, controls, and non-audio alternatives.
6. Research findings that distinguish a tested behavior from an open question.
7. Prototype disclosure stating that the audio was pre-rendered and no runtime integration was demonstrated.

In the handoff, walk through the flow and let engineering ask about failure, interruption, a permanent mute choice, localization, and what the prototype actually validated. The result should preserve the user-facing decisions while leaving technical choices open for implementation.

Sources

• W3C WCAG 2.2: Understanding Audio Control
• W3C WCAG 2.2: Understanding Status Messages
• W3C WAI: Media Players
• W3C WAI: Involving Users in Evaluating Web Accessibility

A rendered-asset prototype can be honest about its limits and still teach the team what the finished interaction needs to feel like. Get started with Vois when you are ready to turn the approved state map and copy into local prototype assets.

The Vois Team