The most cut and least replaceable component
Clients routinely ask to cut the review interface to save budget. It is the component that determines whether the system saves time or merely relocates it.
Done well, a person confirms twenty documents in the time it took to key one. Done badly, review is slower than the original task and people abandon it.
Five design rules
- Source beside output. The original document or message, with the relevant region highlighted.
- Cursor on the first uncertain field, not at the top of the form.
- Keyboard-only completion. A reviewer should never need the mouse.
- Only show what needs attention. Confident fields collapsed, not competing for focus.
- Capture the correction so the same case is never queried twice.
What happens when it is slow
People start approving without looking, at which point you have automated the appearance of checking. That is worse than no review, because it produces false confidence and a clean audit trail of a process nobody performed.
We watch time-per-review as a first-class metric for exactly this reason.
Design for the queue, not just the item
- Sorted by consequence, not arrival — highest value first
- A visible count, so the reviewer knows whether they are winning
- Bulk actions for obviously-correct batches
- A way to skip and return, because some items need a colleague
- Age visible, so nothing sits for a week unnoticed
Corrections are the training signal
Every correction is data: which field, what the model said, what it should have said. Aggregated, that shows exactly where the system is weak and which fixes would help most.
Systems that discard corrections repeat the same errors forever, and users notice within a fortnight.