Notes from the Reversible Queue

Every enterprise product I’ve worked on eventually grows a queue — alerts to triage, recommendations to act on, leads to qualify, tickets to resolve. And every one of them, left alone, ends up with the same bugs. The user can’t tell what they’ve already touched. The wrong action is destructive. “Done” means seven different things depending on who you ask. Items that leave the active list might as well have been deleted, because nobody knows how to find them again.

I used to draw a fresh state model each time, like it was a new problem. It isn’t. The same four states — Active, Snoozed, Completed, Dismissed — keep being the right shape, and the same one rule keeps being the one I have to defend in review: every state-change is reversible for at least eight seconds.

That rule is the one engineers and PMs quietly try to cut for scope. We can ship without Undo and add it later. In my experience, “later” is never. And without Undo, the queue becomes a place users approach carefully — hovering, second-guessing, asking a teammate. With Undo, they move. The speed difference is not subtle.

So I wrote it down: The Reversible Queue Playbook. The state machine, the four interaction rules, the card anatomy, and the Undo argument in a form I can hand to the next team without re-deriving it from scratch.

The version I’m most proud of isn’t a clever interaction. It’s the rule that says the detail panel does not steal the queue. Click View details, the side panel opens, the queue stays visible. Resolve from the panel, the panel closes, focus moves to the next active item — not the one you just finished. Small change, and the entire feel of the surface shifts from a list you drill into to a stack you work through.

That’s the move I’d want to teach if I could only teach one.