| UI or UX | UI + UX - Actionable queue for triaging many items that need human review | UI + UX - Routed decision workflow for requests that require authorized approval | UI + UX - Persisted named filter criteria applied to a list, table, board, or dashboard | UI + UX - Searchable and exportable record of system, user, or administrative events | UI + UX - Durable user-opened notification history and action drawer | UI + UX - Semantic row-and-column data comparison surface | UI + UX - Grouped filter control panel for narrowing a current result set |
| UI guidance | 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 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. | Place Save filter close to the active filter controls and show a criteria preview that names every stored field, operator, and value before users commit it. | 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. | Provide a persistent notification entry point, usually a bell or inbox control, with a count that represents new unseen notifications rather than every unread item forever. | Render a table with a specific caption or heading, visible column headers, optional row headers, aligned values, consistent row actions, and enough spacing for scanability. | Render filter categories as labelled form controls in a panel adjacent to the result set on wide layouts, with a visible result count and active-filter summary near the results. |
| UX guidance | 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. | Use approval workflow when a submitted request cannot proceed until an authorized person, group, threshold, sequence, or external policy gate explicitly approves or rejects it. | Use saved filter when users repeatedly apply the same filter values to a changing list and need to reuse those criteria across sessions or teams. | Use activity log when users need to investigate, audit, verify, or troubleshoot actions across accounts, objects, systems, settings, or security boundaries. | Use a notification center when users receive enough asynchronous system or collaboration updates that they need a durable place to review, triage, and act later. | Use tables when aligned columns help users compare records, find exceptions, audit values, or triage work faster than opening each item. | Use a filter panel to help users narrow the current list or search result set while preserving orientation, search query, sort order, pagination context, and selected values. |
| Good UI | A support queue shows New triage, SLA at risk, owner, customer, status, priority, age, preview text, assignment, and next actions without opening every ticket. | 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 case queue exposes saved filters named High priority benefits and My review queue, each with status, team, priority, and date chips before users apply them. | 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 bell opens a drawer with Unread and All filters, showing comment mentions, approval requests, export results, and background-job failures in newest-first order. | A payment review table has the caption June vendor payments, headers Vendor, Status, Due date, Amount, and Action, right-aligned amounts, and row actions labelled by vendor. | A desktop search page shows a left filter panel with Status, Type, and Date groups, while active chips and the result count sit above the results. |
| Bad UI | A review queue shows a flat list of titles with no reason, age, owner, status, priority, or action controls. | A request page says Waiting without naming the approver, required count, due date, or escalation path. | A star button saves the current table rows without showing which filters created them. | A page titled Activity shows vague entries such as Changed settings with no actor, target, timestamp, or source. | A red badge says 42 forever because opening the drawer, reading items, and viewing related work never update the count. | A div layout looks like columns but has no caption, table semantics, or header associations. | A filter drawer closes with no active count, leaving users unaware that filters are still hiding records. |
| Good UX | 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 requester submits a deployment, sees it is waiting for Release managers, cannot self-approve, receives a change request with a required comment, edits the change summary, and resubmits to the same route. | A benefits worker applies High priority benefits to the current appeal search; the query stays appeal while status, team, and priority filters change. | 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. | Opening the notification drawer clears the new-notification badge while unread items remain available for later triage. | A user sorts by Amount descending, filters to Pending, moves to page 2, and the table keeps its caption, active sort, active filter, row count, and selected payment context. | A user selects Status: Open and Type: Appeal, applies the batch, lands back at the result summary, and sees 12 records with both criteria removable. |
| Bad UX | Two reviewers open the same unclaimed item, both act, and the second decision overwrites the first with no stale-row warning. | The first approver clicks Approve and the system marks the whole request approved even though policy required everyone to approve. | Saving a filter freezes today's 14 rows, so tomorrow's newly urgent benefits cases never appear. | A user marks a notification read and the corresponding activity evidence disappears from the only log. | A payment failure that blocks the current checkout is only stored in the notification center and never appears in the task. | Filtering the table removes selected rows without explaining why or offering a clear-filter path. | Applying a filter silently resets the query, sort order, current page, and view density. |
| Best fit | A team or individual repeatedly reviews many independently queued items. | A submitted request needs authorized approval before a deployment, purchase, access grant, publication, content change, policy exception, financial action, or workflow step can proceed. | Users repeatedly need the same filter criteria on a list, table, board, queue, base view, or dashboard. | Users need to inspect recorded user, admin, system, security, or integration events. | Users receive multiple asynchronous updates across objects, jobs, collaborators, approvals, or reminders. | Records share comparable attributes that users need to scan in aligned columns. | Users need to narrow the current search results, browse results, table, card grid, or list by multiple criteria. |
| Avoid when | The task is a single request moving through a governed approval route. | The user only needs to check their own answers before submission. | Users only need to adjust filters for the current session. | The goal is only to show a readable milestone history for one case or process. | The product has only occasional current-action feedback that a toast or inline status can handle. | The content is layout, not data. | The result set is small enough that scanning is faster than filtering. |
| Required state | Queue loading and count state | Draft or submit-ready request handoff state | No saved filter selected while current filters are still visible and saveable. | Default log state with event records, result count, visible timezone, retention window, and permission scope. | Closed entry-point state with zero, new-unseen, and unread-but-seen counts. | Default table state with caption, visible headers, row values, and result count or context. | Default state with no user-applied filters and an explicit result count. |
| Accessibility burden | Use labelled queue name, count, filters, sort, group, row status, selection, preview, and action controls. | Use labelled request summary, approver, status, due date, decision, comment, and history regions. | Use labelled controls for saved-filter name, visibility, owner, criteria fields, operators, and values. | Use table or structured list semantics so actor, action, object, timestamp, result, and scope are perceivable together. | Give the entry-point control an accessible name that includes new or unread count without relying only on a red dot. | Use native table semantics for tabular data rather than div-only rows. | Use semantic form controls with fieldsets, legends, labels, and accessible names for filter categories and values. |
| Common misuse | Using an ordinary table with no review reason, urgency, ownership, or decision actions. | Showing a generic pending message without the approver, gate, rule, or due date. | Treating the visible table rows as the saved object instead of storing field, operator, and value conditions. | Calling a social feed or notification drawer an activity log without event evidence. | Treating the badge count, unread count, and total notification count as one number. | Using table markup to create page columns or layout spacing. | Hiding active filters inside a closed panel with no count, chips, or result-state summary. |