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.