# Semantic grouping > Panels belong together by meaning, and the layout should say so. - Canonical: https://patterns.konigi.com/dashboards/semantic-grouping - Group: Structure - Level: context - Status: published - Updated: September 10, 2026 - Also called: grouped by service, grouped by team --- ## Problem A dashboard has twenty panels arranged in the order somebody added them. Two panels that describe the same subsystem sit six rows apart, and a panel about payments sits next to one about disk latency because both were built on a Tuesday. ## Solution Group panels by what they mean, label the groups, and let adjacency carry information. Everything about one service together; everything about one stage of a pipeline together; everything one role cares about together. The reason this matters more on a dashboard than on most pages is that people do not read dashboards, they scan them. Scanning uses proximity: things near each other are assumed related, whether or not anyone intended it. That assumption is made before any label is read, which means an ungrouped layout is not neutral. It is actively making false claims. The hard part is choosing the axis, because there are usually three defensible ones and they conflict. **By subsystem**—database, cache, queue, web—suits people who own components and matches how incidents are usually scoped. **By signal type**—traffic, errors, latency, saturation—suits people diagnosing, and puts comparable panels next to each other so a shared shape is visible. **By audience**—what the on-call needs, what the product owner needs—suits pages read by more than one role, and tends to produce duplication. Picking one and applying it consistently beats a page that groups by subsystem at the top and signal type further down, which is the state most mature dashboards drift into as different people add sections. Group labels are the visible output and they get written last, which is why they are so often nouns with no information: "Metrics", "Other", "Misc". A group called "Misc" is a confession that the grouping is unfinished. ## Use when The panel count is beyond a handful, the content has real structure, and viewers scan rather than read top to bottom. ## Don't use when There are six panels. Grouping six things into three groups adds ceremony and reduces the information density of every label. ## Trade-offs Any grouping privileges one question over the others, so the page is fast for the question it was arranged around and slower for every other. Groups resist change: once a section exists, panels get added to whichever one looks closest rather than prompting a rethink. Consistency across a dashboard estate is nearly impossible to maintain without a template, and inconsistent grouping across pages costs more than no grouping. And a grouped layout usually implies collapsing, which brings its own set of problems. ## Checklist - What is the grouping axis, and is it applied consistently down the whole page? - Would a different axis serve the primary reader better? - Does every group have a label that says something specific? - Is there a group called Misc, Other or Metrics? - Does proximity anywhere imply a relationship that does not exist? - Are groups ordered by importance, or by when they were added? - Do the same groups appear in the same order across related dashboards? - Does a new panel have an obvious home, or does it default to the last group? - Are group boundaries visible without relying on colour? - Does the grouping still make sense after the last reorganisation? ## Compare **Grafana** provides rows as the grouping mechanism, so a group is a labelled collapsible band, and the label is the only thing carrying the semantics. **Datadog** offers group widgets that nest within a page and can carry their own status, so a group is an object with state rather than only a divider. **Netdata** derives grouping from the collectors themselves—CPU, memory, disks, network, per application—which means the structure is generated rather than curated and is consistent across every node by construction. **Honeycomb** has little of this, because a board is a set of queries rather than a spatial arrangement, and the grouping question moves to which queries belong on which board. ## Related Panel grid is the mechanism adjacency is expressed through. Collapsible row is what a group usually becomes. Tabs as genres is the same idea promoted to page level. Multi-page dashboard is where grouping goes when sections outgrow one page. Dense small-multiple layout is the case where grouping matters most, because scanning is the only way the page works. ## Examples ### Home Assistant (Open Home Foundation) A card grid people genuinely rearrange, on a wall tablet, which is where resizable layouts either work or quietly stop describing the house. **Demo dashboard** — captured September 10, 2026, Home Assistant public demo (signed out). personal, medium density, light theme, desktop-web. The grouping axis here is physical space—Living room, Kitchen, Study, Outdoor—which nothing else in this gallery uses, and it works for the same reason process mimics work: the viewer already holds the model. The thing worth stealing is the state labelling. Every entity says its state in words: Open · 100%, Off, Closed, Playing, Up-to-date, Unplugged. The amber tint on an icon repeats what the word already said rather than replacing it, so the page is readable with no colour at all. That isn't accessibility diligence so much as an audience constraint—you cannot train a household on a colour key the way you can train an on-call rota, so the words have to carry. Each section header also doubles as a summary: Living room reports 22.8°C and 57% humidity beside its own name, and Study reports "In a meeting". And this is a control surface as much as a display—the Spotlights card is a slider you drag, the thermostats have plus and minus. Hotspots in this capture: - [Resizable card grid](https://patterns.konigi.com/dashboards/resizable-card-grid) — Cards a household arranges itself, grouped by room. Sections are one column each rather than a free canvas. - [Semantic grouping](https://patterns.konigi.com/dashboards/semantic-grouping) *(this pattern)* — Grouped by where the thing physically is, and the group header carries that room's temperature and humidity. - [Semantic status color](https://patterns.konigi.com/dashboards/semantic-status-color) — Amber means on, and the card says 49% anyway. Colour repeats the word instead of replacing it. - [Header KPI strip](https://patterns.konigi.com/dashboards/header-kpi-strip) — Three chips above everything: outside temperature, humidity, and whether anyone is home. - [Sidebar and canvas](https://patterns.konigi.com/dashboards/sidebar-and-canvas) — Collapsed to icons by default, because on a wall tablet the canvas is worth more than the labels. - [Sparkline](https://patterns.konigi.com/dashboards/sparkline) — One card carrying a number and the shape behind it, with no axis and no legend. - [Dashboard builder](https://patterns.konigi.com/dashboards/dashboard-builder) — A pencil in the corner. Editing is one click from reading, which is why these pages actually get rearranged. ### Kibana (Elastic) Query-first rather than panel-first: the search bar is the primary control and the charts are downstream of it, which inverts Grafana's arrangement. **Dashboards / list** — captured September 10, 2026, Elastic demo environment (guest session). analytical, medium density, light theme, desktop-web. The estate, rather than a dashboard. Twenty rows a page and fourteen pages, so something close to 280 dashboards, and sixteen of the twenty on this first page are called "[Metrics Kubernetes] something"—Cronjobs, StatefulSets, Volumes, Pods, Deployments, Proxy, DaemonSets, Jobs, Nodes. They were generated by an integration rather than designed, they all landed on the same day, and they will sit in this list forever. That's the shape every mature dashboard estate takes, and it's why search stops being a convenience at this scale: nobody is browsing to page nine. The list does two things well. Each row carries a one-line description under the title, which is the difference between a name and an answer. And the bracket prefix is doing the work a folder would, so the generated ones sort together and stay out of the way of the four a person actually made. Hotspots in this capture: - [Multi-page dashboard](https://patterns.konigi.com/dashboards/multi-page-dashboard) — A set of peers with no landing page. Fourteen pages of them, and nothing says which is the one the team uses. - [Search across panels](https://patterns.konigi.com/dashboards/search-across-panels) — Past about fifty dashboards this is the navigation and the list below it is a filing system nobody browses. - [Semantic grouping](https://patterns.konigi.com/dashboards/semantic-grouping) *(this pattern)* — Tags and a bracket prefix standing in for folders, which is what keeps 250 generated pages out of the way. - [Data table](https://patterns.konigi.com/dashboards/data-table) — Name, description, last updated, actions. The description column is what makes this a list you can read rather than scan. ### Netdata Per-second charts, hundreds per node, with a per-chart anomaly ribbon instead of a band on the series. **Metrics / System** — captured September 10, 2026, Netdata Agent v2.10.0-686-nightly (public registry node, signed out). operational, dense density, dark theme, desktop-web. Structurally the opposite of Grafana, and worth the comparison. Nobody built this page. The right rail says "showing 720 of total 720 charts" and the tree beneath it—System, Compute, Memory, Storage, Network, Hardware, Processes, then Apps, Users, Groups, O/S Services, and every application it found—is generated from what the agent collects. The canvas is the same hierarchy rendered downward, four levels deep, headings prefixed with dashes: System, then Compute, then CPU, then the chart. There is no editorial layer at all, which means nothing is missing and nothing is prioritised. The header also does something most products won't: it reports "Live 1, Stale 8" beside the node count, so eight of the nine machines behind this view are not currently reporting and the page says so rather than drawing their last known values. Hotspots in this capture: - [Sidebar and canvas](https://patterns.konigi.com/dashboards/sidebar-and-canvas) — The rail is the dashboard. A generated tree of every metric family the agent found. - [Search across panels](https://patterns.konigi.com/dashboards/search-across-panels) — 720 charts, so search is the navigation and the tree is the filing system nobody browses. - [Header KPI strip](https://patterns.konigi.com/dashboards/header-kpi-strip) — Twelve tiles in two rows, in four different layouts. It reads as twelve things rather than one strip. - [Gauge and dial](https://patterns.konigi.com/dashboards/gauge) — Arcs for disk reads and writes, where the maximum is invented—this is a rate, not a capacity. - [Semantic grouping](https://patterns.konigi.com/dashboards/semantic-grouping) *(this pattern)* — Sections generated by the collector rather than chosen. Consistent, and about nothing in particular. - [Freshness indicator](https://patterns.konigi.com/dashboards/freshness-indicator) — Live 1, Stale 8. Most products would have drawn all nine and said nothing. - [Dashboard builder](https://patterns.konigi.com/dashboards/dashboard-builder) — A query builder inline in the panel header: group by, aggregation, node and dimension count. - [Compare periods](https://patterns.konigi.com/dashboards/compare-periods) — Offered per chart rather than per dashboard, which is the scoping trap: one panel shifted, the rest not. ## Related patterns - [Panel grid](https://patterns.konigi.com/dashboards/panel-grid) — Many independent panels need to share one screen without fighting for it. - [Collapsible row](https://patterns.konigi.com/dashboards/collapsible-row) — The dashboard grew to sixty panels and the viewer needs the top twelve most of the time. - [Tabs as genres](https://patterns.konigi.com/dashboards/tabs-as-genres) — The same data serves different questions and each deserves its own page. - [Multi-page dashboard](https://patterns.konigi.com/dashboards/multi-page-dashboard) — One page can't hold it and the sections have different audiences. - [Dense small-multiple layout](https://patterns.konigi.com/dashboards/dense-small-multiple-layout) — An expert wants everything on one screen and will trade legibility for it. ## Sources - [Bach et al., Dashboard Design Patterns](https://dashboarddesignpatterns.github.io/patterns.html) - [Nielsen Norman Group, Progressive Disclosure](https://www.nngroup.com/articles/progressive-disclosure/) - [Grafana, Create a dashboard](https://grafana.com/docs/grafana/latest/visualizations/dashboards/build-dashboards/create-dashboard/) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.