Design
Exceptions are the process
Software designed for the happy path pushes every exception into email. Designing for the exceptions first is how a platform earns trust.
Avantduo4 min read
Ask someone to describe a process and you'll hear the happy path: the request comes in, it's approved, it's done. Ask them what took up their week and you'll hear about everything else: the request that was missing a quote, the approver on leave, the customer who changed their mind after sign-off.
Most software is built from the first description. Most work is the second.
Why the happy path isn't enough
When software only handles the common case, exceptions don't disappear. They move into inboxes, phone calls and side spreadsheets, where they're invisible to reporting and unprotected by any rule. The system's numbers look clean precisely because the messy work happens elsewhere.
That's also why adoption stalls. People trust a system that handles their hardest day. If it only handles their easiest one, they keep the workaround, and soon the workaround is the system.
Designing for exceptions first
- Collect real cases, not hypotheticals: the last ten that needed someone to step in.
- Name each exception as a state or a rule, not a free-text note: 'Waiting on quote', 'Approver away, delegated'.
- Decide who can resolve each one, and make that a permission rather than a convention.
- Keep the decision on record: who made the call, when, and on what basis.
The payoff
Once exceptions live in the platform, they become measurable. You can see how often requests stall for a missing quote, which approvals wait longest, and where a rule change would remove a whole category of rework. The exceptions stop being noise and start being the most useful data you have.