Recently Played Controls

Spotify's Recently Played shelf sits at the top of every user's Home feed — one of the highest-visibility surfaces in the app. It surfaces content automatically based on listening history, but offers no meaningful controls to users who want to manage what appears there. No way to remove an item. No way to pin a favorite. No way to temporarily pause the feed from logging activity.

This matters because the shelf is always visible — on your own screen and on anyone else's. Shared devices, embarrassing listening sessions, and binge sessions that skew recommendations all create real friction with no available resolution. Spotify once surfaced a remove control; it was deprecated, and the community requests never stopped.

"Recently Played is highly visible on Home; users want fast, reversible control over what appears there — without harming discovery."

Spotify surfaces what you've played — but gives you no way to shape what stays. The shelf fills itself. A shared device exposes your listening history. A binge session rewrites your recommendations. There's no way to intervene.

Three friction points emerged, each pointing to a different kind of control:

Without live access to users, I built a structured proxy research layer: behavioral archetypes synthesized from Spotify community complaint threads, UX forum posts, and App Store reviews; a competitive audit across four platforms; and constraint interviews modeled on what Product, ML, Privacy/Legal, and Engineering typically surface in discovery. The goal was to make decisions that would survive real cross-functional scrutiny — not just design-plausible assumptions.

User Archetypes

Competitive Audit

I audited YouTube Music, Apple Music, and Amazon Music against the four controls in scope. Spotify currently offers none of them on-shelf. Remove and Pause bring it to parity; Pin is the differentiator no competitor has touched.

Takeaway: Ship Remove + Pause to reach parity. Add Pin to differentiate.

Point of Reference

Pin, Remove, and Pause weren't the first ideas — they were what survived the filter. Early directions included global history clearing, a private listening mode, and surfacing controls from Settings. Each was ruled out: too broad in scope, too deep in the navigation stack, or too likely to degrade recommendation signals. What remained were three actions that could live on the shelf, complete in 1–2 steps, and reverse without permanent consequence.

Every decision was then filtered through one core constraint: don't break discovery. The shelf exists to surface content users want — any control that weakens that signal is out of scope.

Every project has a perimeter. These defined the shape of the solution — and the reasoning behind each decision matters as much as the decision itself.

These weren't decorative values — they were active filters. Every interaction decision got checked against these four constraints before it moved forward.

This is a concept project — there were no live metrics to report. What I defined instead was a validation plan: specific, measurable acceptance criteria for each feature, structured around a moderated usability test. These are the thresholds I'd use to gate a launch decision.

Proxy metrics: no live data. These thresholds were validated against task-completion benchmarks from published Spotify usability research and competitive analysis of similar shelf-level controls.

The most interesting design challenge here wasn't the UI — it was the scope constraint. Every promising idea (global history delete, recommendation tuning, private mode) pulled toward a much larger, more complex system. The discipline of asking "can this be done on-shelf, in 1–2 steps?" killed more bad ideas than any critique.

Mapping stakeholder priorities did real work. Understanding what Product, ML, Privacy/Legal, and Engineering each cared about meant Remove and Pause were designed with the right constraints from the start — not retrofitted after pushback. Device-scoping Remove and time-boxing Pause weren't compromises; they were the correct decisions once the full system was visible.

In retrospect, I led with Pin — the differentiation play — when Remove was the higher-urgency fix. Real users filing complaints weren't asking for curation; they were asking for relief. I would re-sequence: ship Remove in sprint one, observe what users actually do with it, then build Pin on validated behavior rather than assumed need. That sequencing change is a judgment call, not a scope call — and it took mapping the full constraint picture to see it clearly.

If I had more time