A game UI sound and an onboarding sound are both short interface cues, and it is tempting to treat them as the same problem with a different visual style. They are not. The difference is not aesthetic. It is structural, and it changes what a sound is allowed to do before a single waveform is chosen.
A game UI is a system the player will interact with thousands of times. The first menu click is a new sound; the hundredth is a reflex. The sound can afford to be quiet, subtle, or even slightly unusual, because the player will learn it. An onboarding flow plays once. There is no hundredth interaction, no mastery, no learning curve. The sound has one chance to carry its meaning, and if it is not immediately legible, the user does not get a second encounter to figure it out.
That is the first of three structural differences, and it is the one that most often gets missed when a team ports game UI instincts into an app’s first-run experience. The sections below work through each difference and what it changes about the sound.
Difference 1: Onboarding Has No Second Play. The Sound Must Be Self-Explanatory.
Google’s app sound design guidance includes a decision tree for whether an interaction should make a sound at all. The first branch is whether the result of a user action is visible on screen. If the result is visible and obvious, the guidance says sound is optional and often should be skipped; if the result is visible but subtle, sound helps as a gentle confirmation; if the result is not visible (a background process), sound is recommended . The logic assumes a visual channel that is already doing most of the work.
In onboarding, the visual channel is often the thing being taught. A tutorial step that asks the user to “swipe left to archive” has a visible result once they do it, but the sound is not confirming a known action — it is confirming that they performed the right action for the first time. The sound is part of the explanation, not a redundant acknowledgement of it.
This changes the duration budget. A game UI confirmation can be 100–300 ms because the player already knows what the click means and does not need the sound to carry information . An onboarding confirmation may need to be slightly longer or more distinctive, because it is the only time the user will hear it and it has to register as “this is what success feels like in this app.” That does not mean it should be louder or more musical. It means the sound’s identity has to be legible on first listen, not on the tenth.
A practical consequence: if an onboarding sound requires the user to have heard it before to understand it, it is the wrong sound. A rising two-note interval reads as “correct” on first listen because the contour is a near-universal success signal. A subtle timbral shift that only becomes meaningful after repetition is a game UI sound, not an onboarding sound. The game UI sound design guide covers the hierarchy of confirm, cancel, and error for a system that will be learned; the onboarding case removes the learning, so the hierarchy has to be carried by the sounds themselves rather than by the player’s accumulated context.
Difference 2: The User Did Not Opt Into a Game. The Default Is Silence.
Material Design’s guidance on applying sound to UI is direct about when not to use it: sound is usually unsuitable for “UIs that require privacy or discretion,” “users who have requested no interruptions,” and “actions that are performed frequently” . An onboarding flow is performed frequently by nobody — it happens once — but the first two conditions are often true of the context in which it happens.
A user opening a banking app, a health app, or a workplace tool for the first time may be in a quiet office, on public transport, or next to a sleeping child. They did not launch a game; they launched a utility. The default expectation is silence, and a sound that arrives without being expected is not a confirmation — it is an interruption.
The platform rules make this concrete. Apple’s HIG requires that an app respect the physical silent switch: if mute is on, app sounds stop, except for media playback . This is not a suggestion. An onboarding flow that plays a welcome chime on a muted phone has already broken the platform contract, and the user experiences it as the app ignoring a setting they deliberately enabled.
The working rule for onboarding is therefore not “add sounds to make it feel polished.” It is silence as the baseline, sound as a deliberate exception. The sounds that survive that test are the ones that carry information the visual flow cannot carry alone: a confirmation when the visual feedback is subtle or delayed, an error when the user’s action did not register, a transition marker when the flow moves between contexts. The mobile app versus game UI sound guide covers the platform-expectation gap in more detail; the onboarding-specific point is that the user’s first impression of the app’s audio is also their first impression of whether the app respects their context.
There is a second layer to the same rule. Google’s guidance says UI sounds should be quieter than media and that the default state should be silent for most interactions . An onboarding flow is not media. A welcome sound that is mixed at media level — the level the user expects from music or a video — will feel disproportionately loud in a quiet room, because the user’s volume is set for a different kind of content. The onboarding sound has to be mixed against the app’s own silence, not against a hypothetical media baseline.
Difference 3: The Flow Can Be Skipped, and the Sound Has to Survive That.
Apple’s interaction guidance says onboarding should be brief — three screens maximum — and should let users skip . That constraint has an audio consequence that game UI does not: the sound design has to work for a user who sees one screen and leaves, and for a user who skips immediately, and for a user who reads every word.
A game UI can assume the player will encounter the full set of interface sounds over time. An onboarding flow cannot. If a “skip” button has no sound, the user who skips has heard nothing from the app. If the skip button has a sound but the next screen does not, the skip sound becomes the app’s entire audio identity for that user. Neither outcome is automatically wrong, but both have to be decided rather than inherited from a game UI palette.
The practical implication is that the onboarding sound set should be smaller and more consistent than a game UI set, not a subset of it. A game UI can afford category-specific sounds for hover, select, confirm, cancel, error, and transition, because each will be heard in its own context many times. An onboarding flow that uses six different sounds across three screens gives the user no chance to learn the mapping. A smaller set — one confirm timbre, one error timbre, one transition — is more legible on a single pass, because the user hears the same cue in the same role rather than a new sound at every step.
The consistency requirement is documented in the opposite direction for game UI: the game UI guide describes how confirm and cancel should be distinguishable, and how hover should be lighter than confirmation. Those distinctions matter when the player will encounter them repeatedly. In onboarding, the question is not “are these distinguishable” but “can a first-time user infer the mapping from one encounter.” That is a higher bar, and it argues for fewer sounds, not more.
What Actually Changes in the Sound Itself
The three structural differences translate into a small set of concrete parameter decisions. The table below is not a spec; it is the set of decisions that flip when the context changes from a learned game UI to a one-pass onboarding flow.
| Decision | Game UI default | Onboarding adjustment |
|---|---|---|
| Default state | Sound on for most interactions | Silence unless the sound carries information the visual flow cannot |
| Identity requirement | Learnable over repetition | Legible on first listen; no learned mapping |
| Set size | Category-complete (hover, select, confirm, cancel, error, transition) | Minimal set, often two or three cues total |
| Level reference | Mixed against a game soundtrack and effects bed | Mixed against app silence; quieter than media |
| Silent switch | Respected, but the player opted into a game | Respected as a hard constraint; the user did not opt into audio |
| Failure mode | Sound becomes tiring on the hundredth play | Sound is startling, confusing, or breaks the silent switch on the first play |
The table’s last row is the one that matters most for production. A game UI sound that is slightly too loud or slightly too long will become annoying after repeated exposure. An onboarding sound that is slightly too loud is annoying immediately, because the user has no accumulated context to absorb it. The tolerance is lower, not because the user is less forgiving, but because there is no repetition to dilute the first impression.
Where Sound Is Actually Doing Work in an Onboarding Flow
The sounds that survive the silence baseline are the ones that carry information the visual channel cannot carry cleanly. The list is short.
Confirmation where the visual result is subtle or delayed. Google’s decision tree says sound is optional when the result is obvious and helpful when the result is subtle . In onboarding, “subtle” includes actions whose effect is not immediately visible — a permission granted, a preference saved, an account created. A short confirmation cue tells the user the action landed without requiring them to interpret a spinner or a checkmark.
Error where the user’s action did not register. A validation error is the clearest case for sound in onboarding, because the visual error state may appear below the fold, or the user may be looking at the keyboard rather than the form. The sound carries the information that something went wrong. The mobile app UI sound guide covers the error-cue vocabulary; the onboarding point is that error is the one category where sound is almost always justified, because the cost of missing it is a user who thinks the app is broken.
Transition between contexts. A whoosh or a soft tap that marks moving from one tutorial step to the next can help the user understand that the screen changed intentionally rather than failing to load. The duration guidance for transitions is short — roughly 50–150 ms for a subtle whoosh or tap — which fits the onboarding use case: the sound is marking a boundary, not carrying a message.
A welcome or brand moment, if the app has one. Material Design separates “hero sounds” from notifications and describes them as representations of a product or brand that highlight an important moment, including “welcome users to a new app or experience” . A hero sound is the one case where an onboarding flow can legitimately use a longer, more musical cue, because it is meant to be memorable and it occurs once. The same guidance says hero sounds occur infrequently and should be applied consistently . The onboarding welcome is the canonical occasion for one.
Everything else — hover, select, toggle, decorative transitions — is a candidate for omission. Not because those sounds are bad, but because the onboarding flow does not give the user enough encounters to learn them, and an unlearned sound is either noise or confusion.
A Test That Fits the One-Pass Constraint
The test below is designed for the condition that defines onboarding: the user will not hear the flow twice. It is not a substitute for a full accessibility audit; it is the minimum check that the sound design has not assumed a learning curve that does not exist.
- Play the flow with sound off, then with sound on, as a first-time user. If the flow is harder to understand with sound on — because the sound competes with the narration, or because it draws attention away from the text — the sound is not doing work. If the flow is easier with sound on, identify which cue made the difference. That cue is the set.
- Skip the flow from the first screen and check what the user heard. If the answer is “nothing,” decide whether that is acceptable. If the answer is “a transition whoosh and nothing else,” that whoosh is now the app’s entire audio identity for that user, and it should be chosen deliberately rather than as an afterthought.
- Mute the device and run the flow again. If any sound plays, the app has broken the silent-switch contract. Apple’s HIG requires app sounds to stop when the silent switch is on, with media playback as the narrow exception . An onboarding flow is not media playback.
- Cover the screen and listen to the sounds in sequence. If the sounds alone do not suggest a coherent progression — confirm, error, transition — the mapping is not legible on one pass. A user who is looking at the screen will have more context, but the sound set should not depend entirely on the visual to be interpretable.
The output of this test is not a polished sound design. It is a defensible one: a small set of cues that are justified by information the visual flow cannot carry, mixed against silence rather than against a game soundtrack, and compatible with the platform’s silent-switch contract. A game UI can be more elaborate because the player will learn it. An onboarding flow cannot, because the user will not.