Designing Error States That Reduce Support Tickets

When we audited support ticket volume for a subscription fitness app client, one category stood out: nearly 18% of tickets in a given month were users reporting that 'the app isn't working' after a form submission failed silently or showed a generic error. Looking at the actual error copy, almost every one of those failures was a specific, knowable condition, an expired card, a duplicate email, a network timeout, that the interface had simply flattened into 'Something went wrong.'

We rewrote the error taxonomy from the ground up, cataloging every distinct failure the backend could actually return and writing a specific message and next action for each one. 'Something went wrong' became, for an expired card specifically, 'Your card ending in 4242 was declined. Update your payment method to keep your subscription active,' with a direct link to the billing page rather than a dead end.

The harder design problem wasn't copy, it was making sure the interface had the information to be specific in the first place. That meant going back to engineering to make sure error codes from the API were granular enough to map to distinct messages, which we hadn't originally scoped as a design task but turned out to be the actual bottleneck. Good error design is often blocked on backend specificity, not on writing better sentences for what you're given.

We also stopped hiding errors behind toasts that disappeared after three seconds for anything the user needed to act on. A toast is fine for 'link copied,' it's wrong for 'your payment failed,' because a user who glances away for a moment loses the message and the context entirely. Persistent inline errors, placed next to the field or action that caused them, replaced toasts for anything requiring a response.

Ticket volume in that error-related category dropped by more than a third in the two months following the redesign, without any change to the underlying reliability of the payment system. The failures were the same, users just finally understood what happened and what to do about it, which is most of what a support ticket is asking for anyway.