# Overview then detail > The viewer needs to start wide and end narrow without losing their place. - Canonical: https://patterns.konigi.com/dashboards/overview-then-detail - Group: Structure - Level: context - Status: published - Updated: September 10, 2026 - Also called: landing overview, hierarchical navigation, fleet-to-node --- ## Problem Something is wrong somewhere in a system too large to display at once. The viewer has to narrow from everything to one thing, and at no point should they have to remember what they just saw in order to keep going. ## Solution Build the estate as levels. A top view that fits on one screen and says where to look, then a level per step of narrowing, each one carrying forward what the last one established. Shneiderman's mantra is the whole design in seven words: overview first, zoom and filter, then details on demand. The order is not a suggestion. Landing someone in a detail view without an overview means they are inspecting a thing they have no reason to believe is the right thing. The overview's job is to route the viewer to the right detail page, which is a different job from showing everything. It is to make the abnormal findable. That means it should show few enough things to scan and should encode state rather than magnitude, because at this level the question is where, not how much. Each level down should answer a question the level above raised, and should visibly be the same subject narrowed. The most common failure here is a level that changes subject: a fleet view of hosts leading to a page organised by service, so the viewer arrives somewhere that cannot answer what they came with. The other requirement is a way back that preserves state. NN/g's framing of progressive disclosure applies: the split has to be right, so that people only go deeper on the occasions they need to. If going back means re-entering the time range and the filters, viewers stop going deep, and the levels below the first become decoration. ## Use when The estate is large, has a natural hierarchy, and different roles enter at different levels. Fleet to node, org to team to service, region to store. ## Don't use when There are six things. A hierarchy over a small set is ceremony, and the flat view is faster. Also avoid it when there is no natural containment—forcing a hierarchy onto a graph makes one arbitrary path privileged and every other question hard. ## Trade-offs Levels are a claim about how the world is organised, and the claim is only true for some questions. Cost of traversal is real: three clicks each with a page load is a different experience from three clicks that filter in place. Overviews tend to grow, because every team wants their thing on the front page, and an overview that grew is no longer scannable and no longer does its one job. And people who live at the detail level bookmark it and never see the overview, which means the summary nobody reads gradually stops being maintained. ## Checklist - Does the overview fit one screen without scrolling, at the smallest viewport used? - Does it encode state rather than magnitude, so abnormal is findable? - Does each level answer a question the level above raised? - Is every level obviously the same subject, narrowed? - Does time range, filter and selection survive both directions of travel? - How many steps from landing to the thing someone acts on? - Can a viewer arrive mid-hierarchy from an alert and still orient? - Is there a visible indication of where you are in the hierarchy? - What does the overview do when everything is healthy—does it still earn its place? - Who maintains the overview, given that most daily users skip it? ## Compare **Datadog** runs the pattern across products rather than within one dashboard: host map to host to process to trace, each hop carrying tags forward so the scope narrows rather than resetting. **Sentry** makes the hierarchy the data model—project, issue, event, trace—so the levels are objects with URLs rather than dashboards someone assembled, and the back button behaves. **Netdata** goes fleet overview to node to chart, with the node level being the same dashboard scoped, which keeps the vocabulary identical at every level. **Grafana** has no built-in hierarchy at all: levels are separate dashboards wired together by data links, which is fully flexible and means the coherence of the path is entirely a matter of whether one person thought it through. **Cloudflare Radar** uses it as an index rather than a drill. Each panel summarises a different topic and its arrow opens that topic's own page, so the second level is a new subject rather than a narrowed view of the first. The overview becomes a table of contents, which only works because no scope is being carried down. ## Related Drill-down is the mechanism this structure is made of. Host map is a common top level. Sidebar and canvas is how the levels stay reachable without a full traversal. Ranked list is often the overview that actually works. Multi-page dashboard is the flatter alternative when the levels are parallel rather than nested. ## Examples ### Cloudflare Radar (Cloudflare) A public dashboard with no account, no filters worth the name, and an audience of journalists. Designed for people who will read one number and leave. **Worldwide Overview** — captured September 11, 2026, Public site, signed out; no version string exposed. public, medium density, light theme, desktop-web. Radar is a dashboard for people who did not come to use a dashboard. The audience is journalists, researchers and the merely curious, nobody has an account, and the design follows from that in two ways worth copying. Two controls scope the whole page—where, and when—and neither is a filter in the sense the rest of this gallery means it; the only other selector on the page sits inside the traffic panel. Everything else that looks like a control is a link. Each panel is a standing summary of a section that has its own full page behind the arrow in its heading, so the overview works as a table of contents rather than a filtered view of one dataset. And almost every value is printed as text above the chart that encodes it: "Bot 57.9%, Human 42.1%" sits over the bar rather than inside it. You can read the number without reading the chart, which is the right trade when most of your readers will take one figure and leave. Hotspots in this capture: - [Multi-page dashboard](https://patterns.konigi.com/dashboards/multi-page-dashboard) — Eleven sections behind one rail, with the open one expanded in place. Radar is a site of dashboards, not a dashboard. - [Compare periods](https://patterns.konigi.com/dashboards/compare-periods) — The dotted series is the previous seven days, drawn on the same axis rather than beside it. - [Overview then detail](https://patterns.konigi.com/dashboards/overview-then-detail) *(this pattern)* — Two summaries and an arrow each. The panel exists to tell you whether the full page is worth opening. - [Ratio and rate](https://patterns.konigi.com/dashboards/ratio-and-rate) — Shares only, never counts, and both sides of the split are named so the denominator is never in doubt. - [Stacked composition](https://patterns.konigi.com/dashboards/stacked-composition) — Four mitigation techniques to 100%. The bar is almost redundant next to the printed figures, which is the point. - [Ranked list](https://patterns.konigi.com/dashboards/ranked-list) — A top ten with no magnitudes at all. The rank is the whole finding. - [Delta indicator](https://patterns.konigi.com/dashboards/delta-indicator) — Eight shares with their change under them, all of them fractions of a point, which tells you how still this data is. ### Honeycomb Query-first; heatmaps and BubbleUp replace the dashboard-of-panels model with draw-a-region cross-filtering. **Trace / cart checkout** — captured September 11, 2026, Honeycomb sandbox, public dataset (signed out). analytical, dense density, light theme, desktop-web. Seventy-one spans over 3.288 seconds for one checkout, and the shape gives the answer away before you read a single duration. Two thirds of the way down, getDiscounts runs for 2.576s—more than three quarters of the whole request —and underneath it nine visible SELECT spans step down and to the right in a staircase, each starting after the last one finished. The badge on the parent says 19. Nineteen queries in a loop, run one at a time, and the waterfall says so by its outline rather than by any number. That is the shape worth learning: siblings overlapping means concurrency, siblings in a staircase means something that should have been one query. The panel top right is the other good idea here—it plots the distribution of this span's duration across the whole dataset and marks where this particular trace fell, so you can see whether you are looking at a normal request or the tail before you start optimising. Hotspots in this capture: - [Trace waterfall](https://patterns.konigi.com/dashboards/trace-waterfall) — Indentation is causality, length is duration, horizontal position is when it started. Six levels deep here. - [Trace waterfall](https://patterns.konigi.com/dashboards/trace-waterfall) — The staircase: nineteen SELECTs one after another inside getDiscounts. Batch the query, don't add a machine. - [Percentile summary](https://patterns.konigi.com/dashboards/percentile-summary) — This span's duration against the whole distribution, with this trace marked—so you know if you're looking at the tail. - [Detail on demand](https://patterns.konigi.com/dashboards/detail-on-demand) — Selecting a span fills the right pane with its fields. The waterfall never moves while you read. - [Overview then detail](https://patterns.konigi.com/dashboards/overview-then-detail) *(this pattern)* — A minimap of all 71 spans above the list, so the shape of the whole trace is visible before you scroll it. - [Categorical series palette](https://patterns.konigi.com/dashboards/categorical-series-palette) — Five services, five hues, and the name in a column beside every one. Colour is never carrying it alone. ### Netdata Per-second charts, hundreds per node, with a per-chart anomaly ribbon instead of a band on the series. **Metrics / System › Compute › CPU** — captured September 10, 2026, Netdata Agent (public registry node, signed out). operational, dense density, dark theme, desktop-web. Further down the same generated page, and the section nesting is the thing to look at: "− Compute", then "−− CPU", then "−− Pressure Stall Information (PSI)", then "−−− CPU", then "−−−− Some Pressure". Four levels, each collapsible, each named by the collector rather than by a person, and the depth is signalled with leading dashes because there was no design pass to give them a hierarchy in type. It is consistent and completely unedited. Every chart also carries its own query builder in the header—group by, aggregation, node count, dimension count, sample interval—so a panel here is a live query you can re-scope in place rather than a saved configuration. Worth noting what is not in this shot: the sidebar has an Anomaly Rate toggle, switched off, and Netdata's answer to the anomaly problem is a separate derived rate per chart rather than a band drawn around the series. This capture shows the control, not the thing it draws. Hotspots in this capture: - [Collapsible row](https://patterns.konigi.com/dashboards/collapsible-row) — Four levels of section, depth carried by leading dashes. Generated by the collector, and never edited. - [Gauge and dial](https://patterns.konigi.com/dashboards/gauge) — Six arcs. Two are percentages where the endpoints mean something; four are rates in KiB/s and kbit/s on an invented maximum. - [Legend and series toggle](https://patterns.konigi.com/dashboards/legend-and-series-toggle) — The legend is a value table: steal 0.1, softirq 0, user 1.5113, system 0.9, iowait 0.1, each with its own bar. - [Dashboard builder](https://patterns.konigi.com/dashboards/dashboard-builder) — A query builder in every chart header, so the panel is a live query rather than a saved configuration. - [Overview then detail](https://patterns.konigi.com/dashboards/overview-then-detail) *(this pattern)* — System › Compute › CPU. The breadcrumb is the only thing telling you where in 720 charts you are. ### Plausible Analytics (Plausible Insights) One column, top to bottom, where the metric row doubles as the chart's control. The clearest working argument that a dashboard can have exactly one interaction. **Live demo / plausible.io** — captured September 10, 2026, Plausible live demo, plausible.io's own stats (signed out). public, medium density, light theme, desktop-web. My single-column-narrative entry names Plausible as the reference implementation and says the trick is that the metric row doubles as the chart's control. Here it is doing exactly that: six tiles across the top, the first one boxed because it's selected, and the chart underneath plotting that metric and no other. Click a different tile and the chart follows. The page therefore has one interaction, and it is the same gesture as paying attention. Everything below reads as a single column in argument order—headline, then the shape behind it, then what it decomposes into, then goals. Two things it doesn't do. The ranked lists carry a count and a bar and no share of total, so Direct at 271k against Google at 25.1k tells you the ordering and not whether the top row is most of the traffic. And the choropleth is so pale that outside the United States almost every country is the same near-white, which is the encoding spending a whole panel to say "mostly America". Hotspots in this capture: - [Single-column narrative](https://patterns.konigi.com/dashboards/single-column-narrative) — One column, top to bottom, no panel arrangement and nothing to configure before reading starts. - [Header KPI strip](https://patterns.konigi.com/dashboards/header-kpi-strip) — Six tiles sharing one anatomy, each with a delta. The boxed one is selected, and the chart below plots it. - [Ratio and rate](https://patterns.konigi.com/dashboards/ratio-and-rate) — Bounce rate 43%, with the denominator two tiles away and the window only in the header. - [Overview then detail](https://patterns.konigi.com/dashboards/overview-then-detail) *(this pattern)* — The decomposition: sources, pages, geography, browsers, goals. Same subject, narrowed, no navigation. - [Ranked list](https://patterns.konigi.com/dashboards/ranked-list) — Sorted with an in-row bar, no share of total and no other row. Direct 271k versus Google 25.1k, out of what? - [Geo map with markers](https://patterns.konigi.com/dashboards/geo-map) — A choropleth pale enough that every country but one reads as the same white. Raw counts, unnormalised. - [Tabs as genres](https://patterns.konigi.com/dashboards/tabs-as-genres) — Tabs inside the panel—channels, sources, campaigns—so one card answers three questions in one slot. ## Related patterns - [Drill-down](https://patterns.konigi.com/dashboards/drill-down) — The overview shows that something is wrong; the viewer needs to get to what, in one click. - [Host map](https://patterns.konigi.com/dashboards/host-map) — Hundreds of hosts; the viewer needs to spot the hot ones without a table of hundreds of rows. - [Sidebar and canvas](https://patterns.konigi.com/dashboards/sidebar-and-canvas) — Navigation between many dashboards needs to be persistent without stealing the canvas. - [Ranked list](https://patterns.konigi.com/dashboards/ranked-list) — The viewer needs to know which few items dominate, not the distribution of all of them. - [Multi-page dashboard](https://patterns.konigi.com/dashboards/multi-page-dashboard) — One page can't hold it and the sections have different audiences. ## Sources - [Shneiderman, The Eyes Have It—A Task by Data Type Taxonomy](https://www.cs.umd.edu/~ben/papers/Shneiderman1996eyes.pdf) - [Nielsen Norman Group, Progressive Disclosure](https://www.nngroup.com/articles/progressive-disclosure/) - [Bach et al., Dashboard Design Patterns](https://dashboarddesignpatterns.github.io/patterns.html) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.