Skip to main content

Work

How to Write an Approval Step That People Actually Read

Approval screens get clicked through without reading. Wording and layout rules that fix it: show the change, put the risky field first, force a real choice.

Written by Sicherhaven

You put a human approval step in front of an automated action, and within a fortnight people are approving without reading. The step is still there. The safety it was meant to provide is gone.

The fix is in the design of the screen, not in reminding people to be careful. Show the change rather than the reasoning, put the riskiest field at the top, and make the person choose instead of confirming a default. Those three rules cover most of it.

Show the change, not the reasoning

The most common mistake is filling the approval screen with an explanation of why the agent did what it did. It reads well and it is the wrong content.

An approver is not auditing the logic. They are checking the result against what they know. What they need is the concrete change: this field was X, it will become Y. This message will go to these three people. This date moves from Tuesday to Thursday.

Reasoning belongs in an expandable section for the rare case where the change looks odd and someone wants to know why. Put it above the change and it becomes wallpaper that people scroll past, taking the change with it.

A before and after, side by side or stacked, is almost always the right layout. If a change cannot be shown as before and after, that is a sign it is too big to be one approval, and splitting it into draft, review and send usually helps.

Put the risky field first

Approval screens usually list fields in the order the system stores them. That order is meaningless to the person reading.

Order by consequence instead. Whatever is hardest to undo goes at the top: the recipient list, the money amount, the deletion, the external send. The cosmetic fields go at the bottom or behind a toggle.

People read the top of a screen carefully and the bottom loosely. That is not a flaw to design around. It is a fact to design with.

Force a choice

A screen with a highlighted Approve button and a small grey Cancel is not asking a question. It is telling the person what to do and offering an escape.

Better patterns:

  • Two buttons of equal visual weight, with plain labels that name the outcome. "Send to client" and "Do not send" beat "Confirm" and "Cancel".
  • No preselected option on anything consequential.
  • For higher risk actions, require a small deliberate act: typing a word, ticking the specific field being changed, choosing from a short list of reasons.

The friction is the point, but only for the things that deserve it. Add friction everywhere and people build habits to get past it, which is exactly what you were trying to prevent.

Say who is accountable

Approval screens often hide the fact that clicking makes the approver responsible. Say it plainly on the screen: this will be recorded as approved by you.

This sounds like a small wording change and it measurably changes how long people spend on the screen. Anonymous approvals get clicked. Attributed ones get read.

It also matters afterwards. When something goes wrong, the record should show who approved what and when, without anyone having to reconstruct it.

Keep them rare

The real reason people stop reading approvals is volume. Nobody reads the fortieth one of the day with the attention they gave the first, which is where approving turns into rubber stamping.

So batch what can be batched, and stop asking about things you do not actually want to review. If an agent is filling in a routine field and no approval has ever been rejected, that step is theatre. Remove it and spend the attention on the steps where a rejection is plausible. An agent that says it does not know rather than guessing keeps the queue shorter too.

A good test: if you cannot remember the last time someone said no to a particular approval type, either the step is unnecessary or people have stopped reading it. Both are worth fixing.

Where this fits

SicherOne is built so a human approves agent output before it ships. Agents work from shared project and HR records, so their drafts have real context behind them, and the approval step is where a person confirms that context matched reality.

That step only means something if the screen is designed for a tired person on a Thursday afternoon. Show the change. Put the dangerous thing first. Make them choose. Name them on the record. And ask far less often than you are tempted to.

The one line version

An approval step works when the approver can see, in five seconds, exactly what will be different afterwards, and when saying no is as easy as saying yes.

← All posts

We're building the future of community events and financial wellness

See how Eventify and WealthWise change the way people find events and manage money.

Get Started