Dashboard & Data Table Design That Survives Real Data

Refunds Queue

Answers the question: what do I work on next, and can I clear a batch of it at once?
Users: support agents, all day, every day. Power users — density and keyboard matter more than polish.
Data reality: 2k pending / 40k total · email up to 50+ chars · reason often empty · assigned_agent null ~60% · status cardinality 4
Next action: approve or reject, individually or in bulk.

This is an operational worklist, not an analytics dashboard. That decides almost everything below: density over beauty, the queue is the page, and metrics at the top are navigation rather than decoration.

Layout

┌──────────────────────────────────────────────────────┐
│ Refunds                              [Export] [⚙]    │
├──────────────────────────────────────────────────────┤
│ [Unassigned 1,204] [Mine 87] [Pending 2,041] [Failed 12]│  ← filter tabs, not stat tiles
├──────────────────────────────────────────────────────┤
│ 🔍 search      Status ▾  Assignee ▾  Date ▾   ⚙ 25▾  │
│ Status: Pending ×   Assignee: Unassigned ×  Clear all │
├──────────────────────────────────────────────────────┤
│ ☐ │ Requested │ Customer │ Order │ Amount │ Status │⋯│
│ ...                                                   │
├──────────────────────────────────────────────────────┤
│ Showing 1–50 of 1,204            ‹ 1 2 3 … 25 ›      │
└──────────────────────────────────────────────────────┘

Focal point: the table. It gets everything below the filter bar.

The counts are tabs, not tiles. An agent doesn't want to know there are 1,204 unassigned — they want to work on them. Making the count clickable collapses "read a number" and "apply a filter" into one action, and removes a whole row of decorative tiles from a screen where vertical space is the scarcest resource.

Failed gets a red dot when > 0. It's the only one that's an alarm rather than a queue.

Columns

7 visible. Everything else behind the column picker.

Hidden by default: Refund ID, Reason, Currency code, Payment method, Order total, Customer since

Middle-ellipsis on email, not end-ellipsis. jonathan.mcallister@… tells you nothing; jonathan.m…@acmecorp.com keeps the domain, which is what agents actually scan for. This is the single highest-value detail in the spec for this particular table.

Mixed currency means no column-level unit. Symbol goes in the cell (€42.00), and sorting by Amount must sort by a normalised value or it's nonsense — flag to engineering.

reason stays hidden. Free text that's usually empty is the worst possible default column: it's mostly whitespace and occasionally 400 characters. It belongs in the row expansion.

Default sort: Requested, descending. Tiebreak: refund id, ascending.

Density

Default: compact, 36px rows. Agents live here; 50 rows on screen beats 25 comfortable ones. Offer the density control in the toolbar and persist per user.

Cell padding-x 12px, first/last 16px. 1px bottom border, no zebra striping — 7 columns doesn't need it.

Filters & search

• Active filters as removable chips, always visible. Clear all at 2+.

Filter state in the URL. Agents paste these links to each other constantly — "can you take this batch". Non-negotiable in a support tool.

• Count: Showing 1–50 of 1,204
• Spinner goes in the search field, never over the table.

Pagination

Pagination, not infinite scroll. Agents process systematically and need to know where they are; infinite scroll also breaks the bulk-action bar. Page sizes 25 / 50 / 100, default 50. First/last jumps.

Selection & bulk actions

• Header checkbox selects the page.
• Full page selected + more matching → All 50 on this page selected. [Select all 1,204 matching]
• Bulk bar pins to the bottom on selection: 3 selected · Approve · Reject · Assign to me · Clear

Confirmation names the count and the money: Approve 1,204 refunds totalling €48,210.55? — the amount is the number that stops a mistake.

• Bulk reject requires a reason (select + optional note). Approve doesn't.
• Progress past 2s: Approving 340 of 1,204…
• Partial failure: 1,198 approved, 6 failed. [View failures] — never report "Done" when some failed.
• Selection survives sort. Clears on filter change, with a toast saying so.

Row actions

Approve and Reject as inline buttons — they're 95% of the work, so they don't go in an overflow menu. Overflow (⋯) holds View order · Assign · Copy refund ID · View customer.

Row click expands inline (reason, payment method, customer history), rather than navigating away. Agents lose their place otherwise.

States

The "all clear" empty state matters more than it looks. It's the only moment of the day the agent gets to feel finished. Acknowledge it.

Responsive

Agents are on desktop, so optimise there — but support tablet for on-call.

Keyboard

Daily-use tool, so this earns its place:

a and r need a 3-second undo toast, since they're single-keypress and destructive-ish.

Performance

• Server-side sort, filter and paginate — 40k rows, non-negotiable.
• No virtualisation needed at 50 rows/page.
• Poll 60s, paused while rows are selected or a row is expanded.
• Target p95 < 400ms for the filtered query; the search index needs to cover email and order id.

Accessibility

• Real <table>, <th scope="col">, <caption class="sr-only">Refund requests</caption> ✅
• aria-sort on the sorted header; sort control is a <button> inside the <th> ✅
• Sticky header with an explicit background ✅
• Showing 1–50 of 1,204 in an aria-live="polite" region ✅
• Approve/Reject reachable by keyboard, never hover-only ✅
• Status badge = colour + label (failed vs rejected must not rely on red vs grey) ✅
• Bulk bar announced on appearance; count updates announced politely ✅

Open decisions

• DECISION NEEDED: does approving assign the refund to the acting agent automatically? Recommend

yes — it's an audit trail agents shouldn't have to maintain by hand.

• DECISION NEEDED: should failed refunds sit in this queue or their own? Recommend

own view — they need investigation, not approval, and they pollute the working count.