Use change review when users inspect proposed edits or diffs and decide whether to accept, reject, apply, batch, or request changes; use review before submit for a user's final answer check, approval workflow for routed authorization, and review queue for triaging many items.
Use change review when users inspect proposed edits or diffs and decide whether to accept, reject, apply, batch, or request changes; use review before submit for a user's final answer check, approval workflow for routed authorization, and review queue for triaging many items.
Practice the judgment: Imagine this situation: Accepting a proposed change applies stale content after the underlying file, paragraph, or branch changed. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Change review | Review before submit | Approval workflow | Review queue | Comments | Compare view | Version history | Activity log | Permission denied state |
|---|---|---|---|---|---|---|---|---|---|
| UI or UX | UI + UX - Review surface for proposed edits, diffs, tracked changes, or suggestions before they become accepted content | UI + UX - Final editable answer summary before committing a transaction | UI + UX - Routed decision workflow for requests that require authorized approval | UI + UX - Actionable queue for triaging many items that need human review | UI + UX - Object-attached comment composer and comment list with authorship, replies, state, permissions, and moderation | UI + UX - Selected side-by-side attribute comparison of peer items | UI + UX - Durable snapshot browser for previous document, file, page, object, or configuration versions | UI + UX - Searchable and exportable record of system, user, or administrative events | UI + UX - Authorization and access-boundary state |
| UI guidance | Render change review around a concrete proposed change with base content, proposed content, changed scope, author, timestamp, reviewer progress, pending comment state, accept, reject, apply, batch, and submit-review actions. | Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action. | Render approval workflow as a routed request record with requester, object, requested action, approver eligibility, required rule, current gate, due date, decision controls, comment history, and outcome consequences. | Render review queue as an actionable worklist with queue scope, counts, filters, sort order, row reason, owner, priority, age or SLA, status, preview context, selection, and row actions. | Render comments as anchored contributions with author identity, timestamp, body, optional attachment or selection context, edited state, reply target, and state labels such as open, resolved, hidden, deleted, or assigned. | Render compared items as a bounded side-by-side matrix with item identity, thumbnail or icon when useful, price or status, remove controls, action controls, grouped attribute rows, row labels, consistent units, missing-value notation, and difference indicators. | Render version history as a durable snapshot browser with the current version, previous version list, author, timestamp, named version labels, autosaved version labels, changed summary, retention status, compare affordance, preview, and restore action. | Render activity logs as evidence-oriented records with event time, actor, action, object, source system, scope, result, and technical context such as IP address or location when available. | Show the blocked object or action, current account, permission level, required role, owner, and request path when revealing that information is allowed. |
| UX guidance | Use change review when users need to inspect edits from another person or tool, understand impact, discuss or suggest fixes, and decide whether changes are accepted, rejected, requested, batched, or sent back for revision. | Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed. | Make the approval route understandable over time: who has the request, what decision is needed, what happens on approval or rejection, what blocks self-review, and where the requester can revise or withdraw. | Use review queue when a team repeatedly processes a changing set of tickets, comments, pull requests, content items, cases, requests, or records that require human inspection and action. | Preserve comment drafts, anchors, authorship, notifications, edit history, deletion outcomes, and resolved or hidden states so conversation context remains trustworthy across reloads, permissions, moderation, and return visits. | Use Compare view when users have selected a small set of similar items and need to weigh several meaningful attributes together before choosing, saving, buying, applying, or discarding options. | Make recovery consequences explicit: what becomes current after restore, what happens to current edits or drafts, whether a restored version creates a new version, which comments or metadata carry forward, and which older versions are hidden by retention or permissions. | Use activity log when users need to investigate, audit, verify, or troubleshoot actions across accounts, objects, systems, settings, or security boundaries. | Use permission denied state when the system knows the user is authenticated but their role, group, share, license, policy, or approval status blocks a specific object or action. |
| Good UI | A document review pane highlights one suggested sentence, shows original and proposed text, author, comment, Accept, Reject, Previous, Next, and Preview accepted controls. | A claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address. | A production deployment request shows requester, service, environment, change summary, required reviewer group, self-review restriction, wait timer, Approve and Reject with reason controls, and a timeline of route changes. | A moderation queue has Held, Likely spam, Reported, and Escalated tabs, row evidence, policy reason, reviewer claim state, approve/remove/escalate actions, and bulk-action preview. | A document margin comment shows the selected paragraph, author, timestamp, body text, Reply, Resolve, Assign, and Copy link actions with the composer focused on that selection. | A laptop compare view shows three selected models as columns, grouped rows for performance, display, portability, and support, a sticky model header with price, and a differences-only switch. | A document side panel marks v42 as Current, lists v41, v38 named Pre-launch copy, and v35 autosaved, and opens a compare preview before Restore this version. | An organization audit log table shows timestamp, actor, action, target object, app, IP address, result, and a Details drawer with before and after fields. | A report page says Quarterly revenue report requires Finance viewer access, shows the current account, names the report owner, and offers Request access and Switch account. |
| Bad UI | A reviewer accepts every hidden suggestion while intending to accept one visible edit. | Change links lack context, so assistive technology users hear a list of identical Change links. | A stale email approval applies to a request version that has changed. | The most urgent or oldest item is buried by default sort. | A Notes textarea sits under a record and calls itself comments even though every user overwrites the same field. | A side-by-side card layout repeats marketing copy but omits shared row labels, units, missing-value marks, and difference highlighting. | The current version disappears from context while browsing older versions. | An export button downloads a different date range and timezone than the on-screen filtered log. | A denial page says Something went wrong and shows Retry even though the user lacks a required group. |
| Good UX | A reviewer moves through tracked changes one by one, accepts a terminology fix, rejects a risky deletion with a reason, sees the next unresolved change, and submits the review summary. | A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved. | A finance approval requires both manager and controller approval; the first approval advances the sequence, a rejection stops downstream processing, and the requester sees the exact rejection reason and revise action. | A reviewer claims the oldest SLA-at-risk ticket, opens a preview, assigns it to Billing, returns to the queue with the row removed, and lands on the next oldest item. | A reviewer comments on a selected line, adds an action item for Dana, receives a reply, resolves the comment, and can reopen it from the resolved filter. | A shopper selects three laptops, opens comparison, hides identical specs, highlights battery and memory differences, removes the weakest option, and returns to the same shortlist in the product grid. | A designer names the last approved file version, compares it against the current version, confirms restore, and sees that the restore created v43 while keeping v42 available. | An admin filters to failed SSO events, expands one entry, copies the event ID, exports the filtered range, and sees that records older than 180 days require a different archive. | A user opens a restricted report, sees which account is signed in, requests viewer access with a reason, then sees that the request is pending with the owner. |
| Bad UX | A user applies a suggestion after new commits changed the same lines, and the product silently creates an incorrect patch. | A user selects Change address, edits one field, then has to repeat every later page before finding the review page again. | The first approver clicks Approve and the system marks the whole request approved even though policy required everyone to approve. | A reviewer marks a pull request reviewed from an old queue row after the author pushed new commits and re-requested review. | A user writes a long comment, loses network connection, and the draft disappears when the page reloads. | A compare view resets the selected items after sorting or returning to browse, so the user must rebuild the shortlist from memory. | The current version disappears from context while browsing older versions. | A user marks a notification read and the corresponding activity evidence disappears from the only log. | Every workspace control is disabled after one missing permission, including safe navigation and read-only tasks. |
| Best fit | Users inspect and decide on proposed edits, tracked changes, code suggestions, file diffs, or document redlines. | A user has provided multiple answers and should verify them before a consequential submit action. | A submitted request needs authorized approval before a deployment, purchase, access grant, publication, content change, policy exception, financial action, or workflow step can proceed. | A team or individual repeatedly reviews many independently queued items. | Feedback must preserve author, timestamp, reply, resolution, assignment, or moderation context. | Users need to choose among similar offerings using multiple comparable attributes. | Users edit documents, files, pages, design files, records, configurations, or published content over time. | Users need to inspect recorded user, admin, system, security, or integration events. | A signed-in user lacks permission to view, edit, publish, export, delete, approve, share, administer, or configure a resource. |
| Avoid when | The user only checks their own answers before a transaction. | The task is a single low-risk field with clear inline validation and an obvious submit action. | The user only needs to check their own answers before submission. | The task is a single request moving through a governed approval route. | The user is simply entering a long answer into a form field. | Items are unique, nonexclusive, too simple, too cheap, or mostly aesthetic. | The task is only immediate recovery from one recent action. | The goal is only to show a readable milestone history for one case or process. | The operation failed for network, server, validation, data, or timeout reasons after permission was granted. |
| Required state | Default change review state with original and proposed content visible. | Initial review state with grouped captured answers, relevant sections, and explicit submit action. | Draft or submit-ready request handoff state | Queue loading and count state | Empty comment list and first-comment composer. | One compared item state that explains another item is needed for meaningful comparison. | Default state with current version, previous version list, author, timestamp, and change summary. | Default log state with event records, result count, visible timezone, retention window, and permission scope. | Whole-object access denied state. |
| Accessibility burden | Give accept, reject, apply, batch, mark viewed, comment, approve, and request-change controls accessible names that include the affected change or scope. | Use headings that make the review task explicit, such as Check your answers before sending your application. | Use labelled request summary, approver, status, due date, decision, comment, and history regions. | Use labelled queue name, count, filters, sort, group, row status, selection, preview, and action controls. | Label the comments region with the object or selection being discussed. | Expose comparison title, selected item count, maximum item count, item names, row labels, group headings, units, and missing-value meanings as text. | Use structured list, table, or tab semantics so version number, current status, author, timestamp, and label are read together. | Use table or structured list semantics so actor, action, object, timestamp, result, and scope are perceivable together. | Move focus to the permission message when it replaces page content or blocks a workflow. |
| Common misuse | Calling a review queue change review when reviewers are only choosing which item to open next. | Labelling the final commit button Continue. | Treating the first approval as final when the rule requires more approvers. | Treating review queue as approval workflow and hiding many-item workload controls. | Using one shared Notes field as a comment system and overwriting prior contributors. | Allowing too many compared items so columns become unreadable. | Using a timeline of milestones as a substitute for previewable or restorable versions. | Using vague activity labels that omit actor, action, object, timestamp, or result. | Treating authorization denial as a generic retryable error. |