Designing the approval experience

Every request for approval spends a limited resource: the user’s attention. Spend it on trivia and there is none left for the item that mattered, which is the mechanism by which oversight quietly stops existing.

So the design question is not "what should we ask about" but "what is worth the budget". A system asking about everything is not more careful; it is less, because it has trained the user not to look.

Batching spends the budget better than interrupting. A daily queue arrives when someone is in a reviewing frame of mind, where a notification per application arrives mid-task and trains them to dismiss notifications — which is a habit that then applies to the one that mattered.

Classify each pending action by consequence and confidence, and treat the tiers differently. An application to a role the candidate has explicitly approved the shape of, with a tailored CV containing no novel claims, is genuinely low risk.

An application with a generated free-text answer, a low match score, or a claim the system cannot trace to the source profile is not. Those deserve prominence and detail; the rest deserve a fast path.

Order the queue by risk rather than by arrival. The item with an untraceable claim should meet the freshest attention, and the routine ones belong at the bottom where a faster pass is genuinely appropriate.

• Auto-approve: high score, no novel claims, employer type already approved
• Quick review: routine, shown as a diff, approvable in one action
• Full review: novel free-text, low score, untraceable claim, unusual employer
• Never automatic: declarations, salary commitments, anything irreversible

Trust should accumulate from evidence. A candidate who has approved thirty applications without editing any of them has demonstrated something, and the system can reasonably propose widening the auto-approve band for that shape of application.

Make it explicit and reversible: tell the user what the system noticed, ask whether to stop reviewing that category, and make it one action to resume reviewing. Silently expanding autonomy because the user kept clicking approve is how trust gets abused.

Let it contract as well as expand. A run of rejections, a corrected claim or a long absence are all reasons to narrow the band again and say so, and a system that only ever grants itself more latitude is not calibrating trust but accumulating it.

Most interfaces optimise the approve button because that is the common case. The valuable interaction is the rejection, because it carries information nothing else provides.

Make rejecting one action, with an optional reason from a short list — wrong location, wrong seniority, not interested in this employer, claim is inaccurate. Feed those straight back into scoring. A queue that produces the same rejection every week is not learning, and the user will eventually stop bothering to correct it.

Make editing as cheap as rejecting. Most items are not wrong so much as slightly off, and a reviewer who can fix one sentence and approve produces a better application than one whose only options are accept as written or discard.

Items will sit unanswered, because people are busy and job hunting is not their full-time occupation. Deciding what happens to those is part of the design, and submitting them after a delay is the wrong answer however reasonable the automation argument sounds.

Let them expire, and say why. A posting that closed while awaiting approval is real information about the candidate’s own pace, and far better than an application sent without the review the product promised.

A deadline should promote an item rather than bypass the gate. A role closing tomorrow belongs at the top of the queue with the date stated, which gives the candidate the chance to act instead of having the decision made for them.

You can tell the difference between review and rubber-stamping from behaviour. Time spent before approving, whether the detail view was opened, the edit rate and the rejection rate all indicate whether anyone is reading.

If approvals are instant and rejections have stopped, the gate has become decorative. That is a signal to reduce what you ask about rather than to add warnings — warnings are what people learn to click past.

Cap the queue length for the same reason. Thirty pending items produce a scroll and a bulk action; six produce six decisions, and a queue that is routinely longer is telling you the upstream filtering is too permissive rather than that the review needs redesigning.