Do’s and Don’ts of Sound in UX
Practical guidelines on when and how to use sound in your designs.
Sound in app design is like pepper in cooking. You can probably do without it; but adding a little gets you that subtle, unique flavour. Overdo it, and you can certainly throw your food away!
Think of the last 5 apps you used on your phone, and the sounds, if any, that were part of your experience. I will list down mine.
- Medium (duh!) — I have never come across any sound-based notification on the Medium app, except when I choose to use the reader to listen to a story. A minimalist reading app like Medium does well to keep things simple.
- Google News — no sound. Again largely a reading app that aggregates posts.
- YouTube — given the purpose of apps like YouTube or Netflix, sound is integral. However, there are nuances within. As an example, when I open YouTube, the first recommended video on my feed starts auto-playing, but in a mute mode. That’s not abrupt, it’s by design.
- Chess — Nice feedback sounds on playing a move, which mimic the movement of wooden pieces on a chessboard. Personally, I love it, especially the sound when you take down your opponent’s piece! My experience feels incomplete without these subtle, background sounds.
- WhatsApp — I have turned off all notification sounds (due to the frequency with which I use it).
Recall other apps you use and think of the functions where sound is critical, and how it enhances your experience.
- There are apps which complete critical tasks and use sound to keep you informed. Maybe the notification on a payment app after a payment is completed?
- There are other apps where you probably never need a sound.
- And then there are those where it all boils down to personal preference. Maybe the shutter sound on your phone camera?
- Think of people who have visual impairments — and how sound plays a role in their life and experiences. Food for thought.
Sound is probably one of the most nuanced and often-neglected aspects of app design. It’s a key element of multi-sensory product design, along with haptic (touch) and visuals. It adds a realistic touch to the experience and makes it complete. But the key is to not overdo it. In fact, not getting it wrong is perhaps more important than getting it right!
Most UX designers do not consider sound when designing the final prototypes; and that’s okay. The aim of this story is not to emphasise that sound is super-important, but rather try and ensure that when we do use it, we use it correctly.
Why sound?
Broadly, sound serves three kinds of purpose in apps
- Provide feedback to users for interactions, e.g. tapping on a button.
- Inform users and draw their attention to something critical e.g. the notification sound when a payment is completed.
- Decoration, e.g. the intro music playing on the first interface of a mobile game.
Of these, the first two are more about utility or function. They are more or less critical to the user flow and are expected to inform the user and/or trigger some action from the user.
The last one is more about aesthetics. While it helps improve the app’s aesthetics and also conveys the brand tone and personality, it is relatively less critical to the user flow in most cases. More importantly, these sounds are not expected to trigger any response from the user.
When to use sound?
Sounds should be used judiciously and each sound should justify its place in the overall design. A safe bet is to use sounds only for feedback, and avoid using them for decoration unless it’s really critical to the experience. As with most things in design, less is more.
Sound should elevate the visual experience rather than detract from it.
To identify where sound cues can be most effective or impactful, look at the user flow and consider all situations where an audible feedback to an interaction could enhance and complete the experience.
Some common instances are
- A notification — like a text message in a chat, or a reply to one of your comments on a thread. Here, it’s important to strike a balance between criticality of task and frequency of occurrence. Make sounds too often and you risk annoying users to the point where they turn all notifications off for the next decade.
- When a non-instantaneous action is completed, e.g. a download, an installation, maybe an OS update. By non-instantaneous, I mean the user has initiated the action but they expect it to take some time so they aren’t actively looking at the screen.
- When something has failed unexpectedly, e.g. an error message. Informing the users will make them want to look into why it has failed and to repeat the task or take corrective actions.
- When something time-bound is stuck mid-way and needs user’s input to go forward, e.g. entering an OTP to complete a transaction, or accepting an invite for a multi-player game. If the user is not informed, they may not look at it until much after and realise that it has timed-out, causing frustration.
When NOT to use it?
Sounds can be easily detracting. Think of how often we multi-task on our phones, and how sounds impact the overall experience (not just the experience of your app).
There are some non-critical apps I use while commuting, but I am also likely to be listening to a podcast during my commute. In this scenario, frequent notifications from these apps might interrupt my podcast’s flow repeatedly, which can be extremely irritating. Where and how your users are using your product is critical to how you incorporate sound.
In many scenarios, sound isn’t needed. In fact, it might even be detrimental to the user’s comfort and focus. We are able to focus more in silence. Think of negative space and how the absence of visual clutter help us focus on the most critical elements on the screen. The absence of frequent, distracting sounds plays a similar role and helps users focus on the core tasks.
Avoid sounds in these instances
- If the sound accompanies actions that are performed too frequently. Frequency can be subjective and user-dependent, so it’s important to give users the options to mute. I use WhatsApp so frequently that I keep ‘Conversation tones’ turned off. As another example, imagine a notification sound every time one of your contacts posts something on Instagram. Urghh!
- If the app usage requires privacy or discretion, e.g. an app that helps users track their ovulation cycle.
- If users have explicitly chosen not to be interrupted (I would definitely be in this camp!)
What kinds of sounds to use?
There are two broad styles when it comes to sound:
- Skeuomorphic sounds, which are based on sounds we come across while performing similar tasks in the real world. When you move items to trash on MacOS, it makes a sound identical to the crumbling of a paper — this is something users already experience in the real world. Another example is the sounds on the Chess app discussed above.
- Abstract sounds, which try to digitally mimic and evoke specific emotions that are experienced during an interaction. Users can associate with an abstract sound and recognize it because it feels close to the emotions they experience, e.g. surprise, relief (on a task being completed), lightheartedness, excitement etc. Check this example.
Check out the examples of skeuomorphic and abstract sounds on Google’s Material Design page.
There is no right or wrong answer on which kind to use, and a lot depends on the context. But typically, it’s a safer bet to go with abstract or metaphorical sounds, as they are more about the emotions the task evokes rather than the sound of a (non-digital) version of the task itself.
How frequently should users hear a sound?
Here’s the thing:
We get bored easily, even with sounds we really like.
Remember that once-favourite song you loved so much that you heard it 200 times in the first 2 weeks and not once for the next 3 months?
Yeah. There’s a term for that. It’s called (and rightly so) repetitive tolerance. What it basically means is that there’s a limit to how often we can hear the same freaking sound over and over. And the more elaborate the sound, the lower our threshold to bear it for long. Our tendency to notice a sound also diminishes as it becomes more frequent.
Every time I come across a podcast that starts each episode with the same 10-second intro, it makes me want to kill myself. I zone out. It’s boring, it’s unimaginative, and it’s torturous to users. And that’s why we should reiterate this — do NOT use sound for the sake of using it. Use it only when it’s necessary.
7 Practical Sound Tips for Designers
- Keep it Short: A feedback sound should be just short enough to be perceived by the user. A rule of thumb is to keep it within 0.3 seconds (longer) than the associated micro-animation.
- Go for subtlety, not complexity: The best sounds that are used in apps are very short in duration and subtle. Elaborate sounds that persist for too long are a strict no no. Check the preview of sounds on this page to see how subtle they are, and check this well-known Samsung whistle sound that is just too long and elaborate.
- Maintain consistency in vibe: Avoid sounds that are too dissimilar in the same app. Try to see if you can find more sounds within the same genre — they should be slightly different but not too different. The identity and tone that the app conveys shouldn’t be all over the place.
- Document your sounds: All the sounds used in your app should be included in your style guide or design kit, to ensure consistency in user experience.
- Test it on target devices: Use sounds that sound good when heard from a phone or laptop, which is where most of your users will be interacting with your app. Test your sounds on a target device before finalizing. This is not an issue if you’re picking sounds from an existing open-source design system. Using sounds with good mid-range is usually a safe and logical choice. If the sound seems muffled, tone down the lower frequencies and boost the mids and highs. If the sound seems too shrill or squeaky, do the opposite.
- Mute mode: Always give users the option to mute sounds if they want to. Check both mute and unmute modes during testing to confirm functionality.
- Check accessibility: Your sound design should ensure that users with hearing-impairment don’t miss out on any critical information. A sound shouldn’t be the only element communicating something, it should be supplementary to visual or other (e.g. vibration) cues.
Great, where do I get the sounds from?
No need to reinvent the wheel. Use these resources to download sound kits and use in your apps.
You can check this out as well: 20 Best UI Sound & Music Stock Websites — Bashooka
There are a lot of nuances to using sound in the final prototyping phase. As far as I am aware, Figma still doesn’t support this natively (there’s this Anima plugin), but Adobe XD does. You can watch this video to learn more.
Enjoyed this post? If yes, please show some appreciation by clicking on the “clap” button. Fun trivia — you can hit it up to 50 times! It helps the content reach out to more like-minded people.
If you love my work and want to support my efforts, you can buy me a coffee with ko-fi. Thank you for your kindness and generosity!
Please share your thoughts and feedback in the comments below. This will help me improve and also inspire me to create more.
I try to publish regularly on Medium. Follow this account to receive similar content in future, and click here to get each post directly in your email. You can find me on Linkedin and Twitter as well.
