Unifying "Dismissed" vs "Not Interested," and the Settings row that repeated its own section header
A design review of Deep Cut Atlas turned up something small but annoying: the app called the same feature three different things depending on which screen you were looking at. Settings had a row labeled “Dismissed releases.” The screen it opened was titled “Not Interested.” The empty state on that screen said “No Dismissed Releases.” And the confirmation dialog for clearing everything said “Clear all Not Interested?”
Four names, one concept. None of them wrong exactly, just inconsistent in a way that makes an app feel like it was stitched together by four different people who never talked to each other (which, to be fair, is sort of what happens when features get added one ticket at a time over months).
The fix looked trivial: pick “Not Interested” since that’s the label people actually tap, and change the other three to match. Four string edits, done in twenty minutes.
Except when I went to change the Settings row, I found it lived inside a Section already titled “Not Interested.” So if I just renamed the row to match, I’d get a section header reading “Not Interested” immediately followed by a row also reading “Not Interested.” Fixing the inconsistency would have introduced a new one, just one level up.
This is the annoying thing about copy-consistency tickets: the obvious fix and the correct fix aren’t always the same fix. I checked the actual rendered screen before locking anything in, since this kind of redundancy is obvious once you see the real UI and easy to miss staring at source strings. Apple’s own Settings app never repeats a section header inside a row. Section(“Notifications”) never contains a row that also says “Notifications.” The header sets context once, and the row underneath describes the action or the sub-detail, not the topic. So the row became “Manage,” with the count as its trailing value. Header sets the “what,” row describes the “what do I do here.”
The one place that instinct doesn’t apply: the destructive “Clear all Not Interested” button, sitting in that same section, also technically repeats the header. Left it alone. Destructive actions get an exception. Safari’s Settings says “Clear History and Website Data,” not just “Clear,” because when you’re about to permanently delete something, restating what you’re deleting is worth the redundancy. Consistency-for-its-own-sake would have shortened that button too; the better call was recognizing that one repetition is a bug and the other is a safety feature.
Small ticket, but it’s a decent reminder that “make it consistent” and “make it match what I first assumed” aren’t the same instruction, and the ten seconds it takes to look at the actual rendered screen before locking in a string change is usually worth it.
Related reading
When the same icon means two different things, and why the fix wasn't just a label swap
Two thumbs-down buttons, same red styling - one permanent, one harmless. The visual language was making a promise the code wasn't keeping, and the method name was part of the bug.
A UX decision I got wrong on the first try
The add-to-playlist action matched its sibling gesture on the same card - and fought the rest of the app. Picking the wrong reference point for "consistent."
The setting that worked perfectly and felt completely broken
A filter default that only applied on relaunch, because a TabView keeps view models alive and state seeded at construction is frozen. The fix deleted a concept.