Think Build Implement Repeat
London, UK +44 7367 067226
WhatsApp FOLLOW f in X
AI Apps

Designing the Screen Where Humans Correct the AI

Last updated:

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

  1. Source beside output. The original document or message, with the relevant region highlighted.
  2. Cursor on the first uncertain field, not at the top of the form.
  3. Keyboard-only completion. A reviewer should never need the mouse.
  4. Only show what needs attention. Confident fields collapsed, not competing for focus.
  5. 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.

Frequently asked questions

Can we use a spreadsheet for review?

For a pilot, sometimes. It fails at the source-beside-output rule, which is the one that makes review fast, so it does not survive production.

Who should do the review?

Someone who knows the domain well enough to spot a wrong answer instantly. Review by someone without that knowledge is a rubber stamp with extra steps.

How do we know reviewers are actually checking?

Sample their approvals against known-correct answers periodically. If accuracy on reviewed items is no better than unreviewed, the interface or the workload is wrong.

What share of the build is this?

Typically 15–25%. It is the second-largest line after the core pipeline and it is not optional.

Keep reading

Been quoted for an AI feature with no review screen?

Ask what happens when it is wrong. If the answer is thin, send us the proposal and we will tell you what is missing.

Book a free 30-minute call Get a project estimate WhatsApp us

Related services

What we build for problems like this one

AI AgentsCustom Software DevelopmentSaaS Development