Map exceptions before designing the happy path

A workflow diagram often moves cleanly from submission to approval to completion. Real work also includes withdrawn requests, missing attachments, absent approvers, and updates that arrive too late. Discovery should expose these cases before a polished normal path makes unresolved operating rules look settled.

Start with failure stories

Ask operational staff for recent cases that required a phone call, spreadsheet correction, or supervisor decision. GOV.UK interview guidance recommends stories and real examples rather than descriptions of how work should happen.[2] Use those accounts to build an exception list.

For each case, identify the last trustworthy state. Record what triggered uncertainty and which person held the missing information. Avoid grouping everything under error handling. A rejected request, an unavailable service, and a duplicate submission require different business decisions.

Model recovery, not only rejection

Describe what users see after the exception and which actions remain available. Decide whether work can pause, resume, reverse, or move to manual handling. Specify who can make that choice and how the next person discovers it.

When recovery changes access, include authorization explicitly. OWASP recommends checking permissions on every request.[6] A hidden override button is not a substitute for permission checks. Keep the business rule separate from the interface so the rule also covers alternate entry points.

Hypothetical example: a venue reservation

A hypothetical training venue accepts a room request while an organizer seeks approval. Before approval arrives, another organizer requests the same room. The discovery team compares holding the room, expiring the hold, and allowing a supervised conflict decision.

The example exposes an unresolved question: does a provisional request create a reservation? The team records the policy owner and tests the wording with staff. It does not assume that a faster confirmation screen can solve a disagreement about allocation rights.

Check the exception map

Use the map to inspect one complete recovery journey at a time. Include the customer and the employee who must resolve the problem.

• Name the event that makes the normal path invalid.
• Identify the last confirmed state and any uncertain data.
• Define the permitted recovery actions and their decision owner.
• Specify what happens if nobody acts before the business deadline.
• Test whether repeated recovery attempts create duplicate work.

Choose a proportionate coverage level

Do not design elaborate automation for every imaginable event. Start with frequent exceptions and rare cases that have serious consequences. Record unsupported cases and a workable escalation route rather than implying complete coverage.

Exception mapping can expand scope because it reveals decisions the original diagram omitted. Use that visibility to narrow the initial workflow honestly. A smaller process with clear recovery is often a better trial than a broad process that quietly transfers uncertainty to support staff.