Designing for the service exception

 Today we’re diving into something most people don’t think about—until it’s too late - Designing for the service exception  What happens at that moment in a customer journey when… something goes wrong.  The "Happy Path" trap   If you’ve ever worked on a digital service—for example, applying for a passport, filing your taxes, or scheduling a medical appointment—you know the joy of building a smooth, intuitive journey for your customer.  That’s the happy path.  It’s the version of the journey where everything goes right. The customer has all the right documents. They click all the right buttons. No weird edge cases. No unexpected behavior.  Most journeys don’t live entirely on the happy path.  What happens: When a customer can’t upload a required document?  Their payment fails?  Their name doesn’t match your records because of a data issue from 1998?  That’s where the service exception lives, and if you don’t design for it, you’re not designing a service. You’re designing a fantasy.   ️What is a Service Exception A service exception is any moment in the customer  journey where something breaks—technically, logically, emotionally.  Maybe a system is down. Maybe a rule isn't met. Maybe the user is confused.  These exceptions can be rare, but they’re critical because these are the moments when your users are most vulnerable and frustrated. This is the time they most likely to abandon your service—or worse, call support, file a complaint, or post about it online.  The good news? These moments are designable. You can’t prevent every error. But we can absolutely design what happens next.   Principles for designing exceptions  How do you design for these messy, real-world moments?  1. Anticipate the edge cases. During journey mapping, don’t just sketch the ideal flow. Ask: what could go wrong here? What inputs might fail? What systems might not talk to each other?  2. Design graceful failure. When something breaks, the message should be clear, kind, and constructive. No blame. No jargon. Just: “Here’s what went wrong. Here’s what you can do next.”  3. Provide a human path. Not every issue can be resolved digitally. Build in escape hatches—call lines, chat support, or email fallbacks—for when automation hits a wall.  4. Use real language, not system speak. No user wants to see: “Error 504: Gateway Timeout.” They want to know: “We’re having trouble connecting to the server. Try again in a few minutes or contact us if it keeps happening.”  5. Learn from the data. Track where exceptions happen. If a large number of users get stuck at the same point, it’s not a user error—it’s a design opportunity.  The bottom line  Service exceptions are like stress tests for your design. They show you where the real friction is—and where the real empathy needs to be.  When you design with these moments in mind, you’re not just making a better service -- you’re making a more inclusive, resilient one.