The Support Ticket That Changed How I Build
One email, about one small confusing screen, ended up reshaping how I approach a feature I'd already shipped and stopped thinking about. Here's the ticket and what it actually changed.
I've written before about why I still handle every support request myself across six products. That's the general case for why the channel matters. This is one specific ticket from it: a single email about a screen I'd already shipped and stopped thinking about, that ended up changing how I build a whole category of feature going forward.
The Ticket
Someone wrote in asking how to undo an action they'd taken in one of the apps. The action itself wasn't the problem. It was reversible, and the app actually supported undoing it. The problem was that nothing on the screen told them that. They'd taken the action, panicked slightly, and gone looking for a way to reverse it with no confidence one existed, before eventually finding it buried in a menu they only found by trial and error.
My first read of the ticket was: easy fix, add a tooltip, close the ticket. I almost did exactly that.
Why I Looked Closer Instead
Before replying, I checked whether this was a one-off or a pattern, which is the habit I've written about before: treating a support ticket as a signal, not just a request to close. It wasn't a one-off. It was the fourth version of roughly the same confusion across three different products, each time filed as if it were about a different feature, because on the surface, it was.
That reframed the ticket. It wasn't "this one screen needs a tooltip." It was "I have a category of feature, reversible actions, that I've never once designed to actually communicate reversibility," and that pattern had been quietly costing me support volume and user confidence for longer than any single ticket showed.
What I Actually Changed
Not just the one screen. I went through every reversible action across all six products and applied the same fix everywhere: a small, consistent, immediate confirmation that an action can be undone, shown at the moment it's taken, not buried in a menu discovered later. Same visual language across every product, so the pattern itself becomes something a returning user learns once and recognizes everywhere.
This took longer than fixing the one ticket would have. It also means the next version of this confusion, in a feature I haven't built yet, is far less likely to happen, because the underlying design habit changed, not just the one screen that got reported.
Why This Ticket Specifically Stuck With Me
Most tickets get a fix and get filed away. This one changed a default I didn't know I had: building reversible actions without designing for the fact that a user needs to know, in the moment, that they're reversible. That's not a bug in any one screen. It's a gap in how I'd been thinking about a whole category of feature, and I wouldn't have found it by staring at my own products. I found it because someone was confused enough to email a stranger about it.
The Bottom Line
The ticket that changes how you build rarely looks different from the ones you close in two minutes. The difference is whether you check if it's actually the fourth version of something before deciding it's the first. This one was the fourth, and going back to look was the only reason it turned into anything more than one more tooltip.