{"slug":"review-queue","meta":{"title":"Review Queue","slug":"review-queue","kind":"pattern","summary":"A single ordered worklist that hands one person the next item to judge, with the decision available in the same view — built so the queue empties rather than so it can be browsed.","problem":"Work that needs a human decision is spread across a list everyone can see and nobody owns. Two people open the same item, older items sink, and \"how much is waiting\" is a question nobody can answer without counting.","family":["act","workflow"],"data_shape":["collection"],"principles":["surface-dont-bury","friction","orientation"],"interaction":["selection","decision"],"density":"medium","complexity":"medium","status":"stable","visibility":"public","use_when":["Items need a human judgment before work continues, and the judgment is repeatable.","The order matters — oldest first, or by risk — and should not be left to whoever looks.","Several people work the same pool and must not collide."],"avoid_when":["Each item needs a different investigation with no common decision. That is casework, not a queue.","Only one person ever does it and volume is low. A filtered list is enough.","The decision cannot be made from the information shown, so every item becomes a research project."],"alternatives":[{"slug":"dense-operational-table","when":"People need to compare items across the set rather than judge them one at a time."},{"slug":"linear-workflow","when":"The interesting question is the sequence of stages, not the throughput of one of them."}],"ask_leo":"Build this as a review queue, not as a list.\n\n- Order the queue explicitly — oldest first by default — and say what the\n  order is. Never leave it to insertion order.\n- Show the count of items waiting, and the age of the oldest one, at the top.\n  Those two numbers are what tell someone whether the queue is healthy.\n- Show one item at a time with everything needed to decide it in the same\n  view. If someone must open another screen to judge an item, bring that\n  information into the queue instead.\n- Put the decision actions directly in the item view, with the primary\n  decision emphasised and a distinct action for \"reject\", which must capture\n  a reason.\n- Support keyboard operation for the whole loop: move to next, approve,\n  reject. People work queues for an hour at a time.\n- Advance automatically to the next item after a decision, and say what just\n  happened with an undo for the last action.\n- Prevent collisions: mark an item as being worked when someone opens it, and\n  release it if they leave. Two people must not decide the same item.\n- Give the queue a real empty state that reads as success, not as an error.\n","related":[{"title":"Linear Workflow","url":"/patterns/linear-workflow","summary":"The topology a queue usually sits inside — a queue is one stage of it."},{"title":"Confirmation vs Undo","url":"/patterns/confirmation-vs-undo","summary":"Why a queue should use undo rather than confirm on every decision."}]},"body":"## Anatomy\n\n```\n┌────────────────────────────────────────────────────┐\n│ 14 waiting · oldest 6 days          ⌨ j/k a r      │\n├────────────────────────────────────────────────────┤\n│ Expense #4471 — Priya Nandi            waiting 6d  │\n│ $184.00 · Client dinner · 3 attendees              │\n│ [receipt thumbnail]  policy limit $150             │\n│                                                    │\n│         [ Approve ]   [ Reject with reason ]       │\n└────────────────────────────────────────────────────┘\n      ↑ everything needed to decide, in one view\n```\n\nThe properties that make it a queue rather than a list:\n\n- **An explicit order**, stated on screen.\n- **A depth and an age**, so the health of the queue is visible without counting.\n- **The decision in the same view as the evidence.** This is the one that\n  decides whether the pattern works at all.\n- **Auto-advance**, so the loop is decide-decide-decide rather than\n  decide-navigate-decide.\n- **A claim**, so two people cannot judge the same item.\n\n## Why it works\n\nA queue optimises for **throughput of decisions**, which is a different goal from\na list optimising for *finding a record*. Nearly every design choice follows\nfrom that: one item at a time because attention is the bottleneck, auto-advance\nbecause navigation between items is pure overhead, keyboard control because the\nloop repeats for an hour.\n\nThe depth and age numbers are what make it manageable rather than merely usable.\nA list can hide a backlog indefinitely; a queue that says \"oldest is 6 days\"\nturns a quiet accumulation into a visible fact, which is usually the first time\nanyone notices the process is under-staffed.\n\n## The information test\n\nBefore building the queue, check that **the decision can actually be made from\nwhat the queue can show**. If a reviewer has to open the customer, then the\ncontract, then last month's report, it is not a queue — it is casework wearing a\nqueue's interface, and the auto-advance will make it worse by removing the\ncontext between items.\n\nThe fix is usually to bring the missing evidence into the item, not to abandon\nthe pattern. That is often the most valuable thing the exercise produces:\ndiscovering exactly which three facts a decision really depends on.\n\n## Getting it wrong\n\n- **Confirm dialogs on every decision.** In a queue this is catastrophic — it\n  doubles the clicks on the one action people repeat hundreds of times. Use\n  [undo](/patterns/confirmation-vs-undo) instead.\n- **Reject with no reason.** The reason is the entire feedback loop; without it,\n  the same bad submissions arrive forever.\n- **No claim.** Two reviewers, one item, two different decisions.\n- **An empty state that looks broken.** Finishing a queue is the goal; the\n  screen should say so.\n- **Mouse-only.** Fine for ten items a week, unusable for two hundred a day.\n\n## Exemplars\n\n**Gmail's archive loop** is the pattern at its most refined: one item, keyboard\ncontrol, auto-advance, and undo instead of confirmation on the destructive\naction. It is worth studying precisely because the decision is trivial and the\nvolume is huge, which is the regime queues exist for.\n\n**Stripe Radar's review queue** shows the information test passed properly —\neach flagged payment arrives with the specific signals that flagged it, so the\nreviewer is judging rather than investigating.\n\n**Content moderation tools** across the industry converge on the same shape,\nwhich is a strong signal: one item, fixed order, decision in view, reason on\nreject.\n\nThe extractable rule: **a queue is designed to be emptied, and a list is\ndesigned to be browsed.** If your queue has filters, sorting and pagination, ask\nwhether you built a list and called it a queue.\n"}