click.mp3, reused
- The same tone for success, error, and a toggle
- No way to tell an outcome apart without looking
- Feels bolted on instead of designed in
- Gets muted the first time it grates
blip
a good ui sound
is heard, not noticed.
Most interfaces either skip sound entirely or bolt on one generic click. Neither is a design decision — it is the absence of one. A UI sound is feedback, and feedback follows the same rules as any other signal: purposeful, brief, consistent, and used only where it earns its place.
- 300 ms, typical ceiling
- 4 functions a sound serves
- 1 voice across every state
roomywarmsharpdry
purposea sound has to do
a sound has to do
something, first.
Before direction, length, or character, decide which of these four jobs the sound is actually doing. A cue with no job is the first thing a user learns to tune out.
confirm
Tells someone an action landed — a tap, a save, a toggle — without making them check the screen to be sure.
signal
Marks success or failure clearly enough that the outcome reads before any animation has finished.
notify
Draws attention to something outside the current view — a message, an alert — without a pop-up breaking the flow.
indicate
Marks that something is still in progress, or gives a transition — a swipe, a panel opening — physical weight.
principlesfour rules that hold up
four rules that hold up
at the fiftieth play.
A sound only has to impress once. It has to not annoy hundreds of times. These four principles are what separate the two.
brief
Under 300 milliseconds for anything that repeats often. Long enough to register, short enough to never be the thing someone is waiting on.
consistent
One voice across every state. A success tone and an error tone should sound like they came from the same instrument, not two different apps.
restrained
Calibrated to sit under the interface, not over it — noticeable at a glance, never loud enough to need a warning.
purposeful
Reserved for moments that need it. Silence is a legitimate choice for anything frequent or low-stakes — sound is a tool, not a requirement.
a sound only has to impress once.
it has to not annoy hundreds of times.
one generic click, or a voice per state?
A single click sound answers one question — did something happen — and stops there. It cannot tell anyone whether that something worked. Most interfaces genuinely need a handful of distinct reads: a sound for each UI state covers exactly how to build them from one consistent voice instead of five unrelated ones.
five cues, one character
- Success rises, error falls, a toggle pairs up and down
- The outcome reads before the eye catches up
- Built from one base voice, so it still feels like one product
- Worth leaving on
go deeperthe principles,
the principles,
applied.
Once the rules are clear, what is left is execution — and that splits by state, by platform, and by which tool actually makes the sound.
state by state See the four principles turn into an actual spec — pitch, length, character — for success, error, toggle, and notification. Read the breakdown →
platform code Carry the same recipe into the API your product already uses — see the Web Audio, Swift, and Kotlin patterns.
picking a tool A sample library, an AI prompt, and a synthesis recipe solve this differently — compare the three, or see why a tunable set beats a downloaded pack.
faq
the useful details.
Does every interaction need its own sound?
No. Reserve sound for moments that need a signal beyond what is already visible — a completed action, an error, an alert arriving. A sound on every hover or keystroke stops being feedback and starts being noise.
Why does brevity matter more than character?
Most interface sounds play dozens of times in a session, so their cost compounds fast — something charming once becomes tiring on the fiftieth play. Staying under 300 ms keeps a cue quick enough to never delay the next action, and plain enough to survive repetition.
Should people be able to turn UI sounds off?
Yes. Treat sound as an enhancement layered on top of a fully readable interface, never the only channel carrying information, and always leave a mute control within reach.
Do I need a sound designer to do this well?
Not for interface feedback specifically. Most of the result comes from a handful of structural rules — brevity, one consistent voice, sounds that map to real states — which a small tunable palette handles without specialized training. Save a dedicated sound designer for brand moments that need to be memorable rather than merely clear.
principles are free.
the studio is too.
Open Blip Blip and put the four rules into practice on a real sound.