# Silence is the default

> Decide whether a moment in your interface should make a sound at all, using how often it happens, what it is for and the 100th-use test.

Module: Sound · Level: beginner · 6 min · https://school.agents.org.in/media/sound/silence-is-the-default

Press the button below. With sound off, nothing happens to your ears, and the button still feels fine. Now turn sound on and press it again.

*[Interactive demo: A 50 ms tick, made in code. Sound starts off, and the switch is right there.]*

That tiny tick is pleasant once. Imagine it on every button in an app you use all day. By lunch you would be hunting for the mute switch, and you would remember the product as the noisy one.

That is the whole problem with interface sound. **A bad sound is worse than no sound, and people remember it.** So this module starts with the question most teams skip: should this make a sound at all?

## Why sound has to work harder than motion

You can look away from an animation. You cannot un-hear a chime. And while operating systems have a setting that turns motion down (the reduced-motion preference), there is no setting that turns *your* sounds off. Your product has to do that job itself.

So the default is silence. A sound has to earn its place, and the bar is higher than it is for animation.

> **In plain words.** A **UI sound** is any noise an interface makes when you do something: a click, a whoosh, a chime. This module is about deciding which moments deserve one, designing a small set that belong together, and playing them at the exact right moment.

## Question one: how often?

Frequency decides most cases before anything else. The more often a person hears a sound, the faster it goes from charming to grating.

| How often | Example | Sound? |
|---|---|---|
| Constantly | Typing, scrolling, hovering | Never |
| Many times an hour | Pressing a button, picking an option | No, unless the product is built to feel physical |
| A few times a day | Message sent, file saved | Maybe: one short sound, and only if the person opts in |
| Rarely | First payment, setup finished | Yes. This is where the sound budget goes |

The keyboard never gets sound. Hover never gets sound. A plain button press already has motion and, on phones, a buzz; adding a click there makes the product feel like a toy.

## Question two: what is it for?

Apple's sound designers put it as one word: utility. A sound is worth adding only when it tells you something your eyes might miss. Four reasons pass:

- **Your attention is elsewhere.** You hit send and are already typing the next message. A soft tone confirms it went.
- **Something changed with nothing to see.** A timer ended in a tab you are not looking at. An upload finished in the background.
- **The product is physical by design.** A wallet card snapping into place, a game piece landing.
- **It is a brand moment.** A launch film or an onboarding hero, where sound is part of the medium. The last lesson covers that.

Four reasons fail: decoration, "the animation felt quiet", filling the wait during a slow request, and copying a competitor's ping.

*[Interactive demo: Pick a moment. Most of them stay silent; the ones that pass let you hear their sound.]*

## Question three: does it survive the 100th time?

This is the test Apple's team uses. Picture the sound the first time you hear it. Now picture the hundredth time. If the hundredth makes you reach for mute, cut the sound or make it smaller.

The 100th-use test (Imagine a sound the first time you hear it, then the hundredth. If the hundredth makes you want to mute it, cut the sound or make it smaller) is lopsided in a useful way. A sound that is a little too loud or a little too long is annoying by the tenth time. A sound that is a little too quiet or too short is never noticed as a flaw. So when you are unsure: halve the length and turn it down a notch.

*(Halve it, then drop it 3 dB. You will almost never regret it.)*

## Question four: is there a visual twin?

A sound may back something up. It must never be the only signal. Most people use their devices muted, in an office, on a train, or with a screen reader that is already talking. If the sound carries information nothing else shows, the design is broken for all of them.

Every sound in this module has a visual twin: the toast, the checkmark, the shake.

## Question five: can people turn it off?

Product sound ships **off**, with a switch people can find and reach by keyboard, and the choice is remembered. People who turn sound on often love it. People who cannot turn it off uninstall.

  **Before (avoid):**

A soft click on every button, a whoosh on every page change, a chime on load. No setting to turn it off.

  **After (do this):**

Silent by default. One short tone when a message sends, for people who turn sound on in settings. A three-note figure the day the first payment lands.

## Two surfaces, opposite defaults

Everything above is about the **product**: the app people use every day. There, sound is opt-in, rare and tiny.

A **launch film** flips it. In a short video that introduces the product, sound is the emotional layer and silence is something you place on purpose. Same skill, opposite default, so keep them apart in your head. The film side gets its own lesson at the end of this module.

## Getting your agent to ask the question

Agents love adding sound once you mention it. Give them the decision first, and let them say no.

**Decide before adding any sound (paste into your agent):**

```text
Before adding any sound to this UI, go through every moment that might get one and make a table: moment, how often a person hears it, what it is for, does it survive the 100th use, and its visual twin.
Default to silence. Typing, scrolling, hover and ordinary button presses get no sound.
Only moments that confirm something while attention is elsewhere, signal a change with nothing to see, or mark a rare milestone may pass.
Sound ships off by default behind a visible, keyboard-reachable setting that persists.
Show me the table and wait before generating or wiring any audio.
```

**Check yourself:** A team wants a soft click on every button press in their project-management app. What is the best answer?

- [ ] Yes, a click makes it feel responsive
- [ ] Yes, but make it quieter
- [x] No: presses are frequent, already have visual feedback, and the click would fail the 100th-use test
- [ ] Yes, as long as it is under 300 ms

*Why:* Frequency comes first. A press happens many times an hour and already answers with motion, so sound there reads as a toy and gets muted. Save the sound budget for rare or attention-elsewhere moments.

## In the skill

- https://school.agents.org.in/skill/sound/sound-decision-framework.md
- https://school.agents.org.in/skill/sound/MOC-sound.md