When the same icon means two different things, and why the fix wasn't just a label swap

A design review flagged this one, and it’s a good example of a bug that only exists because two features grew up in different parts of the app without ever being compared side by side.

In Deep Cut Atlas, a Discover or History screen has a “Not Interested” button. Thumbs-down icon, red destructive styling. Tap it, and the release gets recorded as dismissed. It won’t come back. That’s a real, permanent decision, and the icon and color communicate that weight correctly.

The Playlist tab has an almost identical-looking button on its album detail sheet. Same thumbs-down icon. Same red destructive styling. It’s labeled “Ignore.” Except tapping it doesn’t dismiss anything. It just takes the album out of the current playlist. The album is still sitting in the user’s library. Nothing permanent happened.

So a user who’s learned “thumbs-down means never show me this again” from Discover would reasonably assume the same thing in Playlist, and be wrong. The visual language was making a promise the code wasn’t keeping.

The fix itself was small: change the label to “Remove from Playlist,” swap the icon to minus.circle (not trash, since nothing’s being deleted, just delisted from one playlist), reserve thumbs-down exclusively for the two screens where it’s actually permanent.

What made this more than a five-minute string change was the method behind the button. It was called ignore(), with a property named ignoreError. Once the visible label changes to “Remove from Playlist,” a method still called ignore() becomes its own small trap: the next person reading this code sees a button that says one thing and a function that says another, and has to stop and confirm they’re the same action. So the method became removeFromPlaylist() and the property became removeError. That name wasn’t arbitrary either. The parent view model already had a method with that exact name for the same underlying operation one layer down, so the rename lined up with a naming convention that already existed instead of inventing a new one.

The smaller habit worth naming: before locking in a UI string change, look at the rendered screen, not just the source line. A design review can tell you “these two things are named differently,” but it takes an actual screenshot to catch that the fix you’re about to ship would just move the confusion somewhere else.