Command Palette

Search for a command to run...

Design Engineering
Your UI is silent. That's a designfailure

Your UI is silent. That's a design failure.

Every physical interface gives sensory feedback. Web interfaces give you nothing. That silence is a choice, and it's the wrong one.

4 min read·Design Engineering

Press a key on your keyboard. You feel the switch depress. You hear the click. You see the character appear. Three senses confirming a single action.

Now click a button on a web page. You see a hover state change. Maybe a color shift. That's it. One sense. No sound. No tactile response. Nothing confirming the action landed.

We've accepted this as normal. It isn't. It's a design failure with a history.


How we got here

In the early web, sound meant <blink> tags and auto-playing MIDI. It was terrible. The backlash was so strong that "web audio = bad" became an unquestioned rule. Browsers added autoplay restrictions. Design guidelines said "never play sound without explicit user consent."

These rules were correct for background music and auto-playing videos. But they got generalized to all audio, including interaction feedback. The baby went out with the bathwater.

Meanwhile, every other interface in your life evolved toward multi-sensory feedback:

  • Your phone vibrates on every keypress, haptic-taps on toggles, clicks when you adjust settings
  • Your car clicks when you flip a turn signal, beeps when you lock the doors
  • A light switch makes a satisfying snap
  • A mechanical keyboard gives you audible + tactile confirmation of every keystroke

These aren't decorative. They're functional. They reduce cognitive load by confirming actions through redundant sensory channels.


The confirmation problem

When you click a button on the web and nothing visually changes for 200ms (network request, database write, state update), what happened? Did your click register? Should you click again? Is the page frozen?

You don't know. The interface gave you no confirmation. So you click again. Now there are two requests. Maybe a duplicate payment. Maybe a double submission. Not because the user was impatient, but because the interface was silent.

Visual-only feedback is the slowest feedback channel. Your eyes need to find the changed element, process the visual difference, and interpret its meaning. That takes 150-300ms of cognitive processing.

Audio feedback arrives in under 10ms and requires zero visual attention. A click sound tells your brain "action confirmed" before your eyes have even started scanning for visual changes.


Micro-audio: the middle ground

The solution isn't background music or sound effects. It's micro-audio: interaction-triggered audio events that are:

  1. Under 5ms duration: perceived as tactile, not auditory
  2. Under 10% volume: felt more than heard
  3. Triggered only by direct user action: never by background events
  4. Instantly opt-outable: per-component, not buried in settings
// 3ms noise burst at 6% volume
const tick = () => {
  const len = Math.floor(ctx.sampleRate * 0.003);
  const buf = ctx.createBuffer(1, len, ctx.sampleRate);
  const ch = buf.getChannelData(0);
  for (let i = 0; i < len; i++)
    ch[i] = (Math.random() * 2 - 1) * (1 - i / len) ** 4;
  // ... play at gain 0.06
};

This isn't "adding sound to your UI." It's adding confirmation to your UI, through the fastest sensory channel available.


The evidence

  • Apple added haptic feedback to every iOS toggle, picker, and keyboard key. Not for fun. Their research showed it reduced input errors.
  • Gaming has decades of evidence that audio feedback improves reaction time and accuracy. Rhythm games are impossible without audio.
  • Accessibility research consistently shows that multi-modal feedback (visual + auditory) improves usability for users with low vision, cognitive disabilities, and motor impairments.

The web is the only major interaction platform where silence is the default. Not because silence is better. Because we're still reacting to auto-playing MIDI files from 1998.


"But users will hate it"

Some will. That's why every sound-enabled component needs an off switch. But the data from real deployments tells a different story:

In testing with 170+ sound-enabled React components, the breakdown was roughly:

  • 60% didn't consciously notice the audio after the first minute
  • 25% actively liked it and mentioned it unprompted
  • 15% found it distracting and turned it off

That's an 85% acceptance rate for a feature that breaks a 25-year-old convention. And the 15% who turned it off still had a seamless experience. The components work identically with or without sound.


The ask

I'm not saying every web app should beep at you. I'm saying the default of silence is a failure of imagination.

Physical interfaces give you confirmation through every available channel. Digital interfaces give you one channel and call it done. We can do better, with a 12-line audio function and the courage to ship something people might have an opinion about.

Your UI is silent. That's not minimalism. That's missing feedback.

Try the difference: ruixen.com/docs/components. Sound on.

We break down every design decision on Twitter.

Follow @ruixen_ui

Read more like this

Your UI is silent. That's a design failure. | Ruixen UI | Ruixen UI