Case study Audius

When the default pattern is the wrong pattern

Why search was the wrong default for Audius, and what we built instead.

When we launched Audius, search was a search bar. Type a query, get results. The pattern every music app uses. It worked well enough that nothing forced us to revisit it. Default patterns are sticky for a reason. They ship fast and they meet the expectations users walk in with.

The cost is that you don’t revisit them long after they’ve stopped being right.

Audius is a UGC music platform. The catalog is built by anyone who wants to upload, not licensed from labels. That distinction sounds small. It isn’t.

On Spotify or Apple Music, you usually know what you’re looking for. You type “Taylor Swift” because you want Taylor Swift. Search is a fast path to a known thing. The pattern works because intent is the default behavior.

On Audius, intent isn’t the default. Most of our catalog is artists you’ve never heard of. You don’t usually come to Audius knowing what you want to listen to. A lot of the time you come to find something new. Search still matters, and people use it that way. But search alone can’t carry discovery. What we needed alongside it was crate digging.

There were a lot of moving parts to this. Two of our existing surfaces, Explore and Search, weren’t pulling their weight on their own. Explore was a discovery page that wasn’t well optimized. Search was a lookup page. Two intents, two pages, neither working well enough. We folded them into one surface where the empty state is exploration and the active state is filtering.

Metadata was another challenge. On most platforms it’s clean because the labels supply it. On ours it’s whatever the artist filled in. To work around that we computed BPM and key automatically and backfilled the catalog, then autofilled on upload with an override if the artist disagreed. That gave the filters something reliable to stand on.

And then the filtering itself had to work for casual listeners and for producers and DJs in the same control.

The IC design work was led by Sammie Zonana, who I was managing at the time. I scoped the work, gave feedback along the way, and I’d been pushing for it for a long time, but she was the one who executed on the design. A couple of examples:

Adapting the filtering to mobile. Audius is desktop-first and the filter logic is dense: genres, moods, BPM, key, energy, length, and combinations of all of them. Desktop gives you room. Mobile doesn’t. Sammie kept the full complexity of the desktop model on mobile without making it feel like a database query screen.

BPM and key controls. The challenge wasn’t catering to musicians versus listeners. It was building one control that handled both casual and precise input. BPM has a Range mode with sensible buckets (Slow, Medium, Upbeat, Fast) and a custom min and max underneath. There’s also a Target mode for finding tracks near an exact BPM with ±5 or ±10 tolerance, which is how producers and DJs actually think. Key splits Major and Minor and exposes all twelve. Defaults that don’t require expertise, precision available when you want it.

We shipped progressively over about six months last year, finishing in October. The reframe held up. Filtering and surfacing recommendations are how discovery works. Crate digging, not search, is the mental model we design against now.