Spotify users often multitask while they listen: commuting, exercising, getting through the day’s tasks. Yet the core playback controls still need the screen. In early interviews, people kept asking why they needed the phone at all when they were already wearing headphones.

Together with management, I designed and validated a proof of concept to reduce reliance on the screen and increase hands-free use.

Survey: a closer look at music controls

Core actions matter more than feature breadth.

People don’t need full hands-free control. They need reliable access to a small set of high-intent actions: downloading songs, adding to playlists, liking tracks and asking for specific music.

Nearly half stream daily while their hands are busy (commuting, chores, workouts), yet the interaction still depends on the screen. The opportunity was easy access to the core actions, not more features.

It confirmed that hands-free interaction answers a real, recurring need. And music isn’t isolated playback: it goes with cooking, commuting, working out and winding down. People wanted it to respond to their routines.

• Rule-based voice commands couldn’t deliver that level of understanding.
• Wake word plus one word felt mechanical where it needed to feel effortless.
• The Spotify API didn’t expose “like”, the most requested action.
• I should have checked what the API allows earlier, not during prototyping.

The earpiece had 71 acoustic events: beeps that overlapped, a separate confirmation for every variant, and voice prompts on top.

I set up a system, owned by UX, that decides which events deserve a sound, a voice prompt or silence, using a reusable pattern library.

For each moment, participants rated clarity, importance, overload and confidence.

People want to feel an input acknowledged, but reject sound on actions that already explain themselves.

I classified all 71 events by six trigger sources, nine event types, pairing class and repetition profile. Then, in a workshop with the design team, we regrouped every firmware event by behaviour instead of by feature.

Four behaviours remained, ranked by how much attention they ask of the listener:

Triage

Every new event goes through triage before it reaches sound design. The designer walks it through the decision tree, and most proposals end right there, with silence or with a pattern that already exists. To make this part of everyday work, I turned the system into the Acoustic UI coach, a Claude skill that answers YES or NO and names the pattern and its pair. Try a few events below.

The pattern library

Every acoustic event the system allows belongs to one of eight patterns. A new feature reuses a pattern before anyone designs a new sound: ON cues come with their OFF, a tap family is one pattern counted differently, and every mode shares a single OFF.

UX owns whether an event fires, when, and which pattern it belongs to. Sound design owns what it sounds like.

The next version needs to ensure user's engagement and seamless onboarding.

We have already been shipping a custom voice assistant to our audio brands. "Beat" (let's call him that) is the next generation: a companion backed by a LLM with enabled evals to achieve consistent and honest response, data-driven agent behaviour specifications and most importantly - continuous user onboarding.