Five UX Lessons from Building a Browser-Based Dubbing Game

Building a browser-based dubbing game sounds straightforward: play a scene, open the microphone, record a line, and export the result.

The difficult part is not getting audio into the browser. It is helping someone move from “I want to try this” to a finished performance without making the experience feel like audio-editing software.

While building ChoicerVoicer.games, I kept running into UX problems that were specific to voice recording. Here are five lessons that shaped the product.

1. Ask for microphone access at the moment of intent

A permission prompt shown during page load has no context. The visitor has not chosen a scene, read a line, or decided to perform yet, so the request feels suspicious.

A better sequence is:

1. Let the visitor browse scenes first.
2. Show exactly what the recording step will do.
3. Request microphone access only after the visitor presses a clear recording action.
4. Explain how to recover if permission is denied.

This does not remove browser friction, but it gives the prompt a reason. The user understands why the browser is asking.

The denial state also needs to be a real product state. “Microphone unavailable” is not enough. It should explain whether the user needs to change a browser permission, select another input device, or reload after granting access.

2. Treat every line as a small, reversible task

Recording an entire scene in one take creates pressure. One mistake near the end can make the user feel that all earlier work was wasted.

Line-by-line recording changes the mental model. Each line becomes a small task with a clear beginning and end:

• listen to the reference,
• prepare,
• record,
• review,
• keep or retry,
• continue.

The important part is reversibility. A retry should replace only the current take, not reset the rest of the performance. Completed lines should remain visibly completed.

This pattern is useful beyond dubbing. Any creative workflow involving performance, narration, language practice, or repeated capture benefits from dividing a large commitment into recoverable steps.

3. Make review part of recording, not a separate editing mode

Creators often want to hear a take immediately. Moving them into a separate editor after every line interrupts the flow, but skipping review removes confidence.

The compromise is a lightweight review loop:

• play the recorded take immediately,
• keep the retry action close,
• show which take is currently selected,
• avoid presenting a full timeline unless the task really needs one.

The goal is not to recreate professional audio software. It is to answer one simple question quickly: “Do I want to keep this take?”

A focused review loop also works better on mobile, where dense editing controls quickly become difficult to use.

4. Design recovery before designing the happy path

Browser media workflows fail in more ways than a normal form:

• permission is denied,
• no input device is available,
• the active microphone changes,
• a recording is empty,
• the tab loses focus,
• a mobile browser interrupts capture,
• a user refreshes halfway through a scene.

These cases should not all collapse into one generic error.

It helps to classify failures by what the user can do next. Can they retry the current line? Change a permission? Select another device? Continue with previous takes? Start the scene again?

Recovery copy should describe the next useful action instead of exposing implementation details. Users do not need to know which internal stage failed. They need to know whether their work is safe and how to continue.

5. A finished result is part of the onboarding

In a creative tool, the first finished artifact teaches the product better than a long tutorial.

That changes what “onboarding” means. The product should minimize the distance between selecting a scene and seeing a playable result. Optional settings, accounts, advanced editing, and export choices can wait until they are relevant.

A useful first-session path is:

1. choose a short scene,
2. record a small number of lines,
3. review the combined performance,
4. download or share the result.

Once someone has completed that loop, more advanced features make sense because the user understands the reward.

What I would do differently

If I were starting the interaction design again, I would prototype denial, retry, refresh, and mobile interruption states at the same time as the main recording flow.

Media products often look complete in a happy-path demo while still feeling fragile in real use. The recovery states are not polish added at the end; they are part of the core experience.

You can try the current browser experience at ChoicerVoicer.games. It is an independently developed web project, separate from the similarly named downloadable itch.io game.

I would be interested to hear how other developers handle microphone permissions, retakes, and interrupted recording sessions in browser-based creative tools.