One list system for the whole platform

Slow lists, rebuilt for every screen

A backend team started fixing slow endpoints. We saw the chance to rethink what the lists could do, not just how fast they loaded.

Research with the people closest to the problem

Seven clusters of needs

Five decisions, five trade-offs

01

One row of views, a full-width table

Navigation was first designed while folders and fixed default views were in scope. Of four layouts, it came down to two.

We chose

One row above the list

Compact, and continues the familiar tabs.

We rejected

Sidebar on the left

Holds many views and feels like Gmail, but takes horizontal space away from the table. Once folders left scope, nothing justified it.

Trade-off we accepted

Limited length. Overflow collapses into “+N more”, views reorder by drag and drop, and actions appear on hover since the platform has no right-click menus.

02

Sticky controls for wide tables

With auto-fill, one column stretches: the table looks empty with 2–3 columns, squeezed with 6 or more, and users can’t adjust anything.

We chose

Fixed structure

Resizable columns, and room for new ones.

We rejected

Auto-fill width

No horizontal scroll, but unreadable at both extremes and not adjustable.

Trade-off we accepted

Horizontal scroll. Checkboxes and row menus could drift out of view, so the header and checkbox column are sticky, and the row menu appears on hover with a subtle animation.

TipScroll sideways, select rows, open a row menu. Toggle “Highlight sticky areas” to see what stays pinned.

03

Infinite scroll instead of pages

Pagination gives fixed positions, campaign A is always on page 8, but it’s dated and the page switcher costs vertical space.

We chose

Infinite scroll

More vertical space for data, in a continuous flow.

We rejected

Pagination

Filters, sorting and optimistic updates remove the need to remember positions.

Trade-off we accepted

Position is lost after a reload, and new rows must be inserted without reloading. Loading and failures happen inline, without blocking the table.

04

Simple for 99%, not powerful for 1%

Filters exist to find a campaign quickly, not to write queries. Marketers ignore complex interfaces.

We chose

Flat filters

Fast and familiar. Each filter narrows results on its own, and each group shows a count with a quick reset.

We rejected

Condition builder

Any query with logic and formulas, but high complexity: server load and a long tail of edge cases.

Trade-off we accepted

Less flexible. Where AND/OR genuinely matters, a match all / match any toggle appears locally. The backend also shaped the filters: some were dropped, and metrics can’t be sorted.

Designed for loading, empty and error states

Part of the time a list isn’t showing data: it’s loading, recovering or empty. Every one of these moments was designed, with one rule: tell the user what’s happening, and block as little as possible.