Make approval handovers clear

“Pending” with whom?

An approval screen can look simple while hiding real confusion about responsibility. A request says “pending”. But pending with whom? The person who submitted it might be waiting for a reviewer. The reviewer might be waiting for more information from the submitter. One label, two completely different situations, and both people think the other one is holding things up.

So before choosing status labels, write down the responsibilities. At each stage: who can act, what can they decide, and what does everyone else need to see? A status should describe a situation a person understands, not expose whatever the database happens to call it.

Keep the context with the request

The person receiving the work needs enough information to act without detective work: why the request exists, the supporting evidence, what’s changed and any earlier decisions. When something comes back for a second review, show what’s different. Don’t make the reviewer compare two full records from memory.

Think about a purchasing request where the amount goes up after a first approval. That change might mean a different person now needs to approve it. The interface should spell that out. Otherwise someone will assume the earlier approval still stands when the decision underneath it has changed.

Submitted, approved and done are different things

A submitted request isn’t an approved one, and an approved request isn’t necessarily fulfilled. Make those stages visible wherever the difference matters to the user. Show what’s happened and what happens next, without promising an outcome the system can’t guarantee.

The GOV.UK confirmation page pattern is a good reference for this. Its core idea works just as well inside internal tools: after every meaningful handover, people should understand the result of what they just did and what’s still left to do, and by whom.

Design the way back

Approvals rarely move in one direction. A reviewer asks for clarification, a colleague takes over while someone’s on leave, a requester withdraws the item. Treat these as part of the workflow, not as edge cases to sort out later.

Check that a returned request keeps its earlier information and comments. Be clear about whether editing creates a new version, resets approvals or changes the deadline. If reassignment is allowed, show the new owner. If it isn’t, point people to someone who can help.

Be selective with notifications

A notification should help someone act, or tell them about a change that matters. An email for every small update buries the important ones. Decide which events need immediate attention and which can wait in a summary inside the product.

For each notification, define who gets it, why, what context it includes and where it takes them. The link should land on the specific item, in the right state. And think about what happens if the person’s access has expired or the item’s already been dealt with. A broken link at that moment undoes a lot of good design.

Check the whole handover

These questions are worth running through with your team:

• Can everyone tell who owns the item right now?
• Does the person receiving it have what they need to decide?
• Are changes and earlier decisions visible?
• Can people see why an action isn’t available to them?
• Does sending work back, or reassigning it, keep the context?
• Is the next step clear after every important action?

On a supervision platform for a global investment bank, much of the redesign came down to exactly this: separating personal and team views, organising work by urgency, and making the path from review to action clear for each role. You can read the supervisory controls case study, or look at Complex Workflow Design if you have a process that needs the same treatment.