Error Handling
Error handling is crucial to any platform or technical offering, but certainly the consequences drastically differ depending on the level of private information they hold. In products like Slack, Uber, and banking apps, the way a system fails is a reflection of what the company values most and what is most important to their offering, ranging from retention, completion, or trust.
For example, in Slack, if there is an error such as a message-send failure, this will not only cause a UX glitch, but can lead to workplace disturbance and thus workplace retention risk. Because of this, whenever Slack has an error, it will respond with reassuring “we’re working on it” modals that mimic a responsible colleague’s tone. Since Slack’s business cost is measured in churn, if communication fails too often, whole organisations may migrate back to Teams or email.
Another example is how Uber handles errors. For Uber, most errors are failed payments, driver cancellations etc, each threatening a completed ride. The largest consequence of these errors is that it removes the reliability of Uber as an app, which is essential when thinking of someone wanting to enter a car that is not theirs, driven by someone they don’t even know. To fix this, Uber really tries to drive you back to completion so that you don’t leave after that negative experience.
Finally, banking apps treat errors like moral breaches, which can lead to a lost lifetime customer. Every recovery flow is wrapped in security theater ranging from MFA prompts, time stamped messages, “for your protection” phrasing to remind users that the system still deserves their trust.
Thus, error handling varies a lot from app to app but it always links back to whatever it is that the platform values the most: Slack guards belonging, Uber guards throughput, banks guard credibility. In all three, resilience isn’t just about code; it’s the business logic of recovery.
