The system at a glance
Three actions. All shelf-native. All reversible. No settings menus, no buried toggles.
Problem & Constraints
I noticed a gap in one of Spotify's highest-traffic surfaces. The Recently Played shelf sits at the top of every user's Home feed, updates automatically based on listening history, and offers no meaningful controls. No way to remove an item. No way to pin a favorite. No way to pause the feed from logging activity. The shelf is always visible, on your screen and on anyone else's. One user put it plainly: “I don't want my partner's eyes to catch my home screen.” That's not a UX complaint. That's a shelf with consequences.
Before. The shelf records every play and orders by recency. That's the entire interaction model. A track played by accident sits there. Music played for someone else logs the same as anything else. The only way to push a favorite to the top is to play it for one second and force-quit, then repeat. Community forums document users doing exactly that. The workaround is the evidence the shelf is missing controls.
After. Three controls, all native to the shelf, each completing in 1–2 taps. Pin to surface a favorite. Remove to hide a track from the shelf without deleting it from the library. Pause to stop the shelf from logging for a time-boxed session. Reversible by default. No buried settings, no global toggles, no breaking the recommendation engine.
Constraints. The rules every decision had to honor:
- Don't break discovery. The shelf exists to surface what users want. Any control that weakens that signal is out of scope.
- ML training signal integrity. Permanent pause was ruled out. Time-boxing is what survived.
- Per-device, not global. Remove on one device shouldn't propagate. Privacy at the device boundary.
- Reversible only. No destructive deletes. Every action has an undo.
- Shelf-native. No settings menus. The control lives where the problem occurs.
These came from mapping stakeholder priorities (Product, ML, Privacy/Legal, Engineering) before any visual design happened. They turned the obvious first idea, global history clearing, into a non-starter and pointed toward the three controls that survived validation.
What users said
Research & Discovery
No live users, no internal data, no brief. I built the research layer from public signals: Spotify community complaint threads, App Store reviews, UX forum posts, and a competitive audit across seven platforms. I used AI-assisted synthesis to cluster behavioral themes from 200+ community posts. It cut the analysis time significantly, but the judgment calls were still mine.
Spotify Personas
These three personas come from Spotify's own UX research. I used them as the lens for every design decision because they represent the real behavioral range of Recently Played users. The tension between them is what made the design hard: Melanie needs social curation, Dave needs fast access under time pressure, and Stephen tells you where the feature boundary is.
Melodic Melanie
Primary Persona“Why pay for it when it’s free?”
Goals
Inexpensive access to music for herself and for sharing with friends.
Pain point
Recently Played surfaces embarrassing or accidental plays when she shares her screen. No way to clean it up before someone sees it.
What they need from this design
Pin to surface favorites she’d actually share. Remove to clear plays she wouldn’t.
Design tension: Melanie is the social pressure case. If the shelf feels curated, she’s comfortable sharing. If it doesn’t, she stops showing her phone.
Show 2 more personas (Secondary & Negative)
Ranger Dave
Secondary Persona“You should pay for music to support the artists.”
Goals
Supporting music creatives. Listening without interruption from ads.
Pain point
The shelf is noisy from commute listening and his son’s music. He can’t quickly get back to what he actually wants to hear.
What they need from this design
Pin for fast access to go-to albums. Pause to protect recommendations during his son’s listening sessions.
Design tension: Dave is the time-pressure case. He has 45 minutes on BART. Every tap matters. If the control takes more than two steps, he won’t use it.
Stephen Tan
Negative Persona“I stream my music to hear it first before committing to buy the ones I like.”
Goals
Listen to a small set of favorite songs. Keep hassle to a minimum.
Pain point
None related to Recently Played. He doesn’t engage with the shelf or discovery surfaces.
What they need from this design
Nothing from this feature set. Stephen defines the boundary.
Design tension: Stephen is the person these controls are not for. He validates the scope: if the design started trying to serve Stephen, it would mean the feature was too broad.
Competitive Audit
I audited seven platforms. YouTube Music is the closest competitor with three of the four controls. Nobody offers on-shelf pinning.
Point of Reference
User Journey Map
The gap between seeing a control and trusting it.
Mapping Ranger Dave’s 7-stage journey surfaced the highest-friction moment: Stage 3 to Stage 4, from spotting a long-press affordance to committing to an action. No visual cue that the gesture existed. The shelf gave no signal that anything was interactive. That gap drove the decision to design for immediate discoverability, not power-user access patterns.
Design Decisions
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 survivor passed one test: don't break discovery.
Mid-project pivot
I originally led with Pin, the differentiation play. Mapping stakeholder priorities revealed that Remove was the higher-urgency fix. Real users weren't asking for curation. They were asking for relief. That re-sequencing changed the entire build order.
Feature Details
Each control earned its place by surviving the filter above. Here's the reasoning behind the specific decisions that shaped Pin, Remove, and Pause.
Three controls, one surface
Every control lives behind the same long-press gesture on the Recently Played shelf. No settings menus, no buried toggles. Each action completes in 1–2 taps and every destructive action includes an Undo safety net.
Pin
Lock a favorite to the front of the shelf. No competitor offers on-shelf pinning. The item moves to position one and stays there until unpinned.
Long-press any item on the shelf. The action sheet surfaces all controls in one place.
Select Pin on top. Microcopy clarifies: removing hides it from this shelf, not from your library.
The Roses moves to position one with a pin indicator. The rest of the shelf shifts to accommodate.
Long-press hold (500ms) · Prevents accidental triggers. Tap opens the item. Hold reveals controls.
Remove
Hide an item from the shelf without deleting it from your library. Device-scoped, not global. The Undo toast is the safety net that made a trash layer unnecessary.
One surface, three controls.
Long-press reveals Pin, Pause, and Remove in a single iOS-native action sheet. Same entry point for every interaction.
Undo safety net. Device-scoped, not global.
The item is hidden, not deleted. Removal is scoped to this device. The toast makes the action reversible for 3–4 seconds. No trash layer needed.
Loops every 18 seconds
Same entry point. Long-press surfaces the same action sheet as Pin.
Select Remove from Recently Played. The item is hidden from the shelf, not deleted from your library.
Item gone. Shelf reflows immediately. The Undo toast sits above the Now Playing bar: reversible by default.
Auto-dismiss completes the removal · No second confirmation. Inaction is consent. The Undo toast is the entire safety net.
Pause
Stop the shelf from logging activity without leaving the app. Time-boxed to protect ML training signal. One toggle, same action sheet, instant feedback.
Same entry point again. All three controls share one gesture and one surface.
Pause listening history toggle in its default off state. The toggle sits inline with the other controls.
Toggle flipped. History pauses immediately. Time-boxed: resumes automatically to protect recommendation quality.
Time-boxed auto-revert · Protects ML recommendation signal. The user doesn't have to remember to turn it back on.
Every state is reachable and reversible
One entry point, three branches, and every path returns to Default. The dashed node is the only terminal state, and it takes deliberate inaction to reach it.
Constraints & Trade-offs
Every project has a perimeter. These defined the shape of the solution. The reasoning behind each decision matters as much as the decision itself.
Editing global listening history
This touches a different surface (Settings → Privacy) and a different stakeholder group. Scoping it here would expand the project beyond one sprint and dilute focus.
Changing ranking algorithms
Recommendation logic is owned by a separate team. Any ranking changes would require cross-team alignment that's out of scope for a shelf-level UX feature.
Profile privacy redesign
The privacy complaints are real, but they're systemic. Not solvable by a shelf control. Addressing this here would be a band-aid on a bigger problem.
History Trash
The research included a 'History Trash' concept: a secondary space holding 30 days of removed items. It was cut. The Undo toast accomplishes the same goal with less cognitive load and no additional surface to manage. A trash layer introduces a mental model question (is this gone, or just hidden?) that the current design avoids entirely. Undo is the answer. Trash is scope creep.
Pause must be time-boxed
Recommendations & ML: permanent pause degrades training signal quality over time. Time-boxing was the negotiated middle ground.
Remove is device-scoped only
Privacy/Legal: global history deletion requires explicit user confirmation flows and different data handling. Device-scoped remove is a much lighter lift with the same UX benefit for the target use case.
Pin cap at 4
Engineering: a lightweight chip-based sync model breaks down past 4 items. Keeps the feature fast and avoids overbuilding into playlist territory.
Validation Plan
This is a concept project. No live data exists. Instead of reporting numbers I don't have, I built the evaluation framework I'd use to gate a launch decision: a moderated usability test with specific acceptance criteria per feature.
Test Protocol
Moderated usability test. 6 participants across the four archetypes (Social Curator, Commuter, Parent on shared device, Explorer). Each participant completes three task scenarios: pin a specific item, remove an embarrassing play, and pause history before handing the phone to a friend. Sessions recorded. Think-aloud protocol. 45 minutes per session.
Decision Criteria
All feature-specific thresholds must pass for that feature to ship. If error rate or CSAT fails on a single feature, that feature gets a redesign cycle before re-test. UMUX-Lite is a directional signal, not a gate: if task metrics pass but UMUX-Lite is flat, the features ship and the team investigates perception gap in follow-up research.
Reflection
The hardest part of this project wasn't the UI. It was saying no. Every promising idea (global history delete, recommendation tuning, private mode) pulled toward a much larger 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.
The pivot from Pin-first to Remove-first (documented in Section 03) was the most consequential decision in the project. It came from mapping the full constraint picture. What I'd add now: 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.
Prefer the narrative version?
View the slide deckNext Case Study
Men's Sole Revival