Designing an approval UI you can decide in under five seconds

The approver is almost never the developer. It is a finance lead, an ops manager, a marketing director, a legal reviewer — someone who got pinged, opened the page mid-interruption, and has maybe twelve seconds of patience before context-switching costs more than the decision itself.

Most approval tools solve the developer's problem and leave the reviewer with whatever falls out. You can see that tradeoff in the two things teams reach for today.

A no-code form builder is not the play

Drag a few fields onto a canvas, publish, send a link to finance. The reviewer sees a grid of labeled inputs — amount, customer id, reason — and the grid looks identical whether the customer is a first-timer with one complaint or a six-year regular who has never asked for a refund before.

The reviewer can technically decide from this. They also can't, really. No history, no evidence, no shape. Finance shrugs and approves, because denying without context feels worse than approving without it. The form produces decisions, not reviews.

A Slack message is not the play either

An agent posts to a channel, two buttons appear inline. It works when the approver is an engineer reviewing an engineering action — same medium, shared vocabulary, already in the tool.

It falls apart the moment the approver is not an engineer. A finance lead is not on Slack between meetings. The message arrives, gets pushed up by forty others, and the agent is still waiting three hours later. Slack approvals look free until you look at the pattern of which ones never get decided.

A rich UI is the play

The title says, in plain terms, what is about to happen. Below it, the surfaces the decision actually turns on — who the customer is, what they bought, what went wrong, what the agent has already checked, how similar requests resolved recently, what the money breaks down into. The reviewer reads once and decides.

A form asks the reviewer to assemble a decision from parts. A rich UI assembles the decision for them and asks only yes or no. The shape changes per use case — refund approvals look like refund approvals, deploy approvals look like deploy approvals — because the review surface is generated from a skill integration, not dragged onto a canvas.

Approve and Deny

Two buttons, bottom-right of the card, same place every time. Approve is filled orange. Deny is outlined. No confirmation modal on Approve — the click was the confirmation. A second modal is a tax on a decision the approver already made.

Denial is a sentence, not a dropdown

Click Deny, a one-line input appears, you type the reason in your own words, enter sends it.

Dropdowns give clean analytics. Real denial reasons are almost never one of five things. They are "refund as store credit instead", or "customer already replied, skip this one", or "check with finance before pushing again". The agent's logs should carry those sentences back, not labels borrowed from someone else's taxonomy.

Keyboard

a approves. d denies. j and k move through the queue. The shortcuts match what people guess from Gmail and Vim, which is why we do not ship a cheat sheet.

What we left out

No filters. No bulk select. No tags or custom card fields. Each has been requested. Each would slow the loop.

Bulk approve is the one I think about most. The moment bulk exists, bulk becomes the default, and the gate turns into a rubber stamp. If forty requests really should share one decision, that is a batching call at the submission layer — send one approval for the batch, with a preview that summarizes it.

The tradeoff

Optimizing for speed means the review surface is shallow. Long-term success rates, comment threads, cross-approval comparisons live in the audit log. The audit log is where you investigate. The review surface is where you decide.

Five seconds is not a marketing number. It is what the interruption gives you before the cost of the decision passes the value of the decision itself. The card fits inside that budget, or the gate collapses into a rubber stamp.