Pay for something with your phone and listen. The soft chime that confirms the payment does a job no pixel can do: it tells you the transaction went through while your eyes are already somewhere else. That is interface. Most apps ship without it, or worse, with sound nobody designed.
The interface you hear
Screens compete for one sense. Audio reaches a second one, and it works even when the user is not looking. A well-placed sound confirms an action, signals a failure before the user reads a single word, and gives an app a physical, finished feel that animation alone cannot reach.
The apps people describe as satisfying almost always have a sound layer they never consciously notice. The shutter click of a camera app. The gentle pop of a sent message. The rising two-note figure when a payment clears. None of these are decoration. Each one closes a feedback loop.
If a sound does not answer a question the user just asked, it is noise.
Why most app sound fails
When audio annoys people, the cause is usually one of four mistakes:
- It was never designed. A stock library ping dropped in during the last sprint carries no relationship to the brand, the visuals, or the moment.
- It plays too often. A sound on every tap turns feedback into a metronome. Frequency is the fastest way to get muted.
- It is too loud and too long. UI sound competes with music, podcasts and open-plan offices. Anything over roughly 400 milliseconds stops being feedback and starts being a jingle.
- It ignores context. Sound that interrupts the user's music, plays during a meeting, or fires with the mute switch on teaches people to switch it off permanently.
A working method: the sound palette
We treat app audio the way a design system treats color: a small palette, derived from one tonal family, mapped to a short list of moments. For most products, five sounds cover everything worth hearing.
The discipline is in the derivation. All five sounds should share a synth patch, an instrument, or a recording session, the same way every color in a palette shares a hue logic. When the success chime and the notification tone are cousins, the product sounds like one thing. When they come from different stock packs, it sounds like a flea market.
Rules that keep sound welcome
- Silence is the default. Add a sound only where feedback has value beyond the screen: confirmations, failures, and events that happen while the user is not looking.
- Design at phone-speaker volume. Mix on the actual device at arm's length, not on studio monitors. A sound that needs headphones to work does not work.
- Keep feedback under 400 ms. Longer sounds delay the next action and get old by the tenth hearing.
- Pair sound with haptics. On mobile, a light haptic plus a quiet tick reads as one physical event. Either alone feels thinner.
- Duck, never interrupt. Configure the audio session so UI sounds mix over the user's music at reduced level and never pause it.
- Respect the mute switch and accessibility settings. Honoring the ringer switch is not optional, and every audio cue needs a visual equivalent for users who cannot hear it.
When silence wins
Some products should stay quiet. Utilities people run twenty times a day, professional tools used in shared spaces, anything running alongside someone else's audio. The question is always the same: does this sound answer a question the user just asked? In a calculator, it does not. In a banking app confirming a transfer, it absolutely does.
Sound is the cheapest layer of craft most apps never add. It weighs a few hundred kilobytes, takes a fraction of the design budget, and it is often the detail people mention when they say an app feels finished. Design it with the same seriousness as the pixels, and nobody will ever reach for the mute switch.