How to present a lot
of data well.
A working field guide to information design — the craft of turning many sources, surfaces, and numbers into something a person understands at a glance and can drill into for truth. Each idea below has a name, an authority behind it, a demo you can feel, and a note on how it lands on your dashboard.
There isn't one name for this field — that's the first thing to know. Information design is the umbrella (make information clear). Data visualization is the chart-craft inside it. Information architecture is how the many surfaces are organized and navigated. Dashboard / analytics UX is the slice that's specifically your job. "Information engineering" is a different, older thing (enterprise data modeling) — don't use it.
The good news: each layer has a small number of load-bearing ideas, and once you can feel them you stop choosing chart types from a menu and start reasoning from principles. Scroll.
Overview first, zoom and filter, then details on demand.
This is Shneiderman's mantra (1996) and it's almost word-for-word your stated purpose: glance → drill deep → spot anomalies → get insights. Most dashboards fail by collapsing all three levels onto one screen — everything always-on, so nothing is glanceable and nothing is deep. Treat it as the structure of every surface.
Your /overview is level 1 and should stay ruthless — one north-star answer, "is it normal" in 5s. /growth/acquisition, /money/geo are level 2 (zoom/filter). The single drillable row / tooltip is level 3. When a page tries to be two levels at once, split it.
The eye finds some things instantly — design with those.
Preattentive attributes (color, intensity, position, motion, size) are processed in <250ms, before conscious attention. Everything else — reading, comparing shapes — is slow serial work. The whole game of "glanceable" is encoding the one thing that matters in a preattentive channel.
This is why a red KPI delta works and a wall of equally-weighted numbers doesn't. Reserve your strongest preattentive channels (color, weight) for exceptions and the headline. If everything is bold and colored, nothing is — you've spent the budget on noise.
Not all encodings are read equally well.
Cleveland & McGill ranked how accurately people decode quantity from each visual channel. Position beats length beats angle beats area beats color. This single ranking resolves most "which chart?" arguments: a bar (position/length) beats a pie (angle/area) beats a bubble (area) beats a heatmap cell (color) — for reading magnitude.
Task: rank these five from largest to smallest. Easy in one panel, a guess in the others.
The ranking, in order
- 1Position on a common scalescatter, dot plot, bar baseline
- 2Lengthbar charts
- 3Angle / slopeline slopes, pie (meh)
- 4Areabubbles, treemap
- 5Color saturation / densityheatmaps, choropleth
- 6Color hue / volume3D, hue-coded value
This ranks magnitude accuracy. Lower channels are fine for category, geography, or rough patterns — just not for "exactly how much."
Your geo page uses color on a map/table — correct for "where," but pair it with a sorted bar/number for "how much," because no one reads $ accurately off a shade. Kill any pie charts. A treemap is acceptable only when part-to-whole + many categories beats a long bar list.
"Compared to what?"
A number alone cannot be anomalous. Tufte's question is the whole basis of spotting anomalies: a value only carries meaning against a baseline, target, prior period, or forecast band. Watch a bare metric become a decision.
You already do the hard version right — your latest commit compares deltas to same-day, same-hour prior, not naive yesterday. That's the seasonality-aware baseline most teams get wrong. Extend it: every headline number on every surface should ship with its "compared to what." A KPI with no comparison is a bug, not a panel.
Maximize data-ink. Delete the rest.
Tufte's data-ink ratio: every pixel that isn't carrying data is a tax on comprehension — gridlines, 3D, gradients, drop shadows, redundant legends, axis chrome. The discipline: remove non-data ink until something breaks, then add back the one thing you needed.
Your DESIGN.md already says "numbers do the work / restraint is the brand" — this is the theory behind it. Audit any chart for: heavy gridlines, gradient fills, shadows on bars, legends that repeat the axis, two-decimal precision no one acts on. Each is removable.
Many small charts beat one crowded one.
When you have one pattern across many categories (channels, countries, providers), overlaying them makes a spaghetti hairball. Small multiples — the same chart repeated small, same axes — let the eye scan for the odd one out. This is also why a node-edge "graph of everything" usually fails: it's spaghetti in 2D.
For per-provider revenue, per-country sessions, per-channel ROAS — reach for small multiples before a multi-series line. And it settles the page-2 plan: the data inventory should be a structured catalog, with a simple lineage view layered on — not a force-directed blob.
The eye groups things — use it instead of fighting it.
Gestalt principles describe how we auto-group visual elements. The two you'll use daily: proximity (near = related) and enclosure / common region (a shared background = a unit). Most "this layout feels cluttered" problems are Gestalt problems — you're drawing borders the eye doesn't need.
Your nav groups (Overview / Money / Growth / Engineering…) should read as groups visually too — spacing and a shared surface, not boxes-in-boxes. Before adding a divider line or a card border, try adding space first.
Three palette types — pick by data type, not taste.
- Sequential — one hue, light→dark, for ordered/quantitative data (low→high sessions).
- Diverging — two hues from a neutral midpoint, for data with a meaningful center (above/below target, +/− delta).
- Categorical — distinct hues for unordered categories (providers, channels). Cap it at ~6 or they stop being distinguishable.
Your deltas are diverging (good/bad) — keep an icon or sign alongside the hue for colorblind safety. Provider/channel series are categorical — keep the same color for the same provider everywhere (a color that means "Polar" on one page and "Kaspi" on another is a lie).
Strategic, analytical, operational.
Stephen Few's taxonomy. The senior move is to stop designing every page in one uniform style and instead design each in the register its job demands. Your nav already splits this way — name it and lean in.
Strategic
High-level, low interactivity, "are we on track." Sparse, big numbers, vs-goal. Looked at for seconds.
Analytical
Dense, comparison-rich, filter & drill. Built for "why did this move." Looked at for minutes.
Operational
Real-time, threshold & alert driven, anomaly-first. Glance for "is anything on fire."
When you add a surface, first decide which of the three it is — that dictates density, refresh, interactivity, and how much color/alerting it earns. A strategic page with operational density, or vice versa, is the most common structural mistake.
Permission ≠ relevance.
Your RBAC twist. Can-see and should-see-first are different questions. A leader allowed to see margins, geo, and velocity shouldn't get all three dumped equally — design each landing around a persona's decision, and let the rest be a drill-away. Otherwise RBAC just gates a data dump per role.
The throughline
Every panel should be a decision in disguise: a number, encoded in a channel the eye reads accurately, against a baseline that makes it judgeable, at the level of zoom its viewer is at, with color spent only on the exception. If a panel doesn't drive a decision for someone, it's a candidate for deletion — not a smaller font.
Where to go deeper
Curated, not a dump. Read in this order.
Next: the data inventory — a structured catalog of every source × metric × role × decision, auto-drafted from your codebase, with a lineage view layered on top. Then we brainstorm from decisions, not data.