What a potato chip taught me about UI sound design

UI sound design for the web: why sites went silent, how sound feedback improves UX, the accessibility rules, and Web Audio API tips from a kiosk concept.

In 2004, two researchers at Oxford sat people in a booth, gave them headphones and a pile of potato chips, and asked a simple question: how crisp is this one?

The chips were all the same. The only thing that changed was what people heard while they bit. Massimiliano Zampini and Charles Spence picked up the crunch with a microphone and played it back in real time, sometimes louder, sometimes with the high frequencies boosted. When the crunch was louder or brighter, people rated the same chip as crisper and fresher. The paper went on to win an Ig Nobel Prize in 2008, the award for research that makes you laugh and then makes you think.

I think about those chips every time I hear that sound on a website is a gimmick.

Because an interface has a crunch too. Press a button and something has to tell you it worked. Designers call that feedback. On most websites, that something is purely visual. The colour shifts, a spinner turns, and your ear gets nothing. Then, for a school project, I designed a concept kiosk for the Meguro Parasitological Museum in Tokyo, and the ear turned out to be half the job.

Why the web went quiet

If you used the internet in the 2000s, you remember why websites stopped making noise. A music player that started on its own. An ad that shouted from a tab you couldn't find. Sound arrived without being asked for, so people learned to reach for the mute button first.

Browsers took the hint. Since 2018, Chrome only lets a page play sound once the visitor has interacted with it, and since Chrome 71 that rule covers the Web Audio API as well (Chrome's autoplay policy). Users kept muting anyway. In 2016, publishers told Digiday that up to 85% of their Facebook video views happened with the sound off.

Therefore the industry drew a conclusion: people hate sound on the web.

But read those stories again. People hated sound they didn't ask for, at a volume they didn't choose, with no way to turn it off. That's a complaint about behaviour. The medium itself got blamed by accident, and UI sound design has been paying for it ever since.

What UI sound does that pixels can't

For UX, sound has two things going for it: it's fast, and it doesn't need your eyes. You can be looking at the wrong corner of the screen and still know the file was sent. That alone would be enough, but there are three more things I've seen it do in practice.

It confirms without asking for attention. In 1986, researcher William Gaver proposed auditory icons: interface sounds built as caricatures of real-world sounds, so a file landing in a folder sounds a bit like something landing. You don't have to learn what they mean. Your ears already know. Three years later, Meera Blattner and her colleagues described the other family, earcons: short abstract tones you learn, like the chime of a sent message. Most UI sound design today mixes the two.

It gives things a material. This is the chip lesson. A drag that ends with a soft thud feels heavier than the same drag in silence. Same pixels, same animation, different object.

It makes motion feel finished. Game designers have a word for this: juice. In their 2012 talk Juice it or lose it, Martin Jonasson and Petri Purho took a bare Breakout clone and kept adding feedback until it felt alive, and sound was on that list. The trick is timing. Your brain glues a sound to a movement when they land together, and it's more forgiving when the image comes slightly before the sound than the other way round (Vroomen & Keetels, 2010). So trigger the sound at the moment of contact, never at the start of the animation.

The museum problem

The Meguro Parasitological Museum is real, and it's the only museum in the world dedicated entirely to parasites. My kiosk isn't: it's a school project, a concept the museum never commissioned. The exercise was to imagine an interactive layer in front of its display cases: four exhibits, a mini-game in each, and draggable specimens that visitors would collect into a virtual box. The brief aimed at kids, without losing the specialists in the same room.

Even on paper, that room is the whole problem. A kiosk isn't a phone in your pocket. In a gallery like this one, other visitors would stand a metre away reading in silence, so anything loud or arcade-like was ruled out before it was ever a design choice. The sound had to make the kiosk feel like a game without sounding like one.

The obvious idea was squelchy creature sounds on every grab. With a parasite museum, that joke writes itself. That's also why I dropped it: it would get old by the second specimen, and it would make fun of the museum's subject. I went with organic textures instead, tactile enough to feel like handling something real, and kept them pleasant rather than gross.

Here's what that system taught me.

Start with a bed, not with effects

In the prototype, the system starts with a calm, looping ambient track made from underwater tones, running under the whole kiosk at low volume. With it, every effect has something to sit on. Without it, each click lands in an empty room and sounds louder than it is.

One button, one sound

Every navigation tap uses the same low, calm click, in the sidebar and everywhere else. Material Design's own guidance says sound usually isn't suitable for actions people perform often, and in principle I agree. On a touchscreen, though, a finger gets nothing back from the glass, and a soft click is the only proof the tap registered. So I kept it, made it quiet, and made it identical every time, so it reads as part of the button instead of an event.

Don't punish a mistake

The mini-games play a light cue on success and a soft tone on a miss. A wrong answer in front of your parents is already embarrassing enough. The kiosk doesn't need to buzz about it.

Save the loud moment for once

There's exactly one cue in the whole system that isn't calm. When the specimen box is complete, a small fanfare plays while a paper strip tears away to reveal the museum coupon, with sound and motion tearing together. It would happen once per visit, which is why it's allowed to be big. Material calls these hero sounds and recommends keeping them rare and consistent. I'd say it more bluntly: if everything celebrates, nothing does. The same rule holds for rewards in general, as I explain in what gamification really is.

The code is the easy part

The technical side is lighter than people expect. The background track is a plain <audio> element at 35% volume, and the music on the final screen plays at 20%. Effects go through the Web Audio API, with a few details worth stealing:

let ctx: AudioContext | null = null
const cache = new Map<string, AudioBuffer>()

function getCtx() {
  if (!ctx) ctx = new AudioContext()        // created on the first gesture
  if (ctx.state === "suspended") ctx.resume()
  return ctx
}

export async function play(src: string, gain = 2.5) {
  const c = getCtx()
  let buf = cache.get(src)
  if (!buf) {
    buf = await c.decodeAudioData(await (await fetch(src)).arrayBuffer())
    cache.set(src, buf)                     // fetched and decoded once
  }
  const source = c.createBufferSource()
  const volume = c.createGain()
  source.buffer = buf
  volume.gain.value = gain                  // above 1 to cut through the music
  source.connect(volume).connect(c.destination)
  source.start()
}

The context is created lazily, because one created before any interaction starts suspended under the autoplay rules. Decoded sounds are cached, so a second grab plays instantly. And the gain goes above 1.0 so short effects stay audible over the ambient bed. If you do that, listen to your loudest file at full volume first: past 1.0, a sample that's already hot will distort.

Sound design rules I'd give anyone starting out

None of this needs a sound designer on staff. It needs a few rules you don't break.

• Never start sound on load. Wait for a click or a tap. The browser will make you anyway, and it's the polite thing to do.
• Give people a way out. If anything plays automatically for more than three seconds, WCAG, the web's accessibility guidelines, asks for a way to pause it or a volume control of its own (success criterion 1.4.2). A visible mute toggle that remembers its state covers it.
• Never let sound carry information alone. The WHO estimates that 1.5 billion people live with some degree of hearing loss, and plenty more browse with their phone on silent. For accessibility, every cue needs a visual twin.
• Pick a family and stay in it. Gaver's auditory icons worked because related events sounded related. At Meguro, everything is organic or underwater. One stray arcade beep would break that.
• Turn it down until you barely hear it. Then test the interface in a real setting, with real people around.

The same chip

The Meguro case study, the full school project, goes deeper into the collection loop, the bilingual content and the build. You can read it here.

But if I had to keep one thing from that project, it would be the chips. Nobody in that Oxford booth ate a different chip. They heard a different one, and that was enough to change what they tasted.

Your interface works the same way. People won't remember your button sound. They'll remember that the thing felt solid.