UI Sound Design

Design sound as part of the interaction, not as decoration added at the end. Make each cue useful, causal, harmonious with the interface, restrained under repetition, and expressive enough to belong to the product.

Read references/design-principles.md before creating a sound direction or system. Read references/platform-playback.md before specifying playback behavior. Read references/evaluation.md before evaluating candidates or approving a cue. Use references/sample-listening.md when citing existing UI sounds or looking for listening references.

Ground rules

• Let silence win when sound adds no information, confidence, tangibility, emotion, or sense of place.
• Make the trigger and source obvious. The person should understand what caused the sound.
• Make sight, sound, and touch tell one story. Match event, timing, weight, material, energy, direction, and spatial origin.
• Design frequent UI sounds below the prominence of notifications and rare celebrations.
• Never make sound the only carrier of essential information.
• Respect system audio behavior and provide controls for optional UI sound. Do not force sound through silent modes by default.
• Evaluate effects inside the final interaction and on target devices. A sound that works alone or in studio headphones is not yet approved.
• Do not claim to have heard an asset unless it was actually auditioned. When files or playback tools are unavailable, review the brief and mark listening-dependent findings as pending.
• Cite the primary source when referencing an existing product sound. Link to the listening page rather than copying or redistributing audio whose license is unknown.
• Treat exact levels, frequencies, durations, latency budgets, and pass thresholds as starting hypotheses unless product requirements or measurements support them. Label them for tuning instead of presenting them as universal facts.
• Treat delight as a valid goal, but keep decorative or playful cues optional and proportionate to frequency.