# Mobile adaptation > The on-call engineer is looking at this on a phone at 3 a.m. - Canonical: https://patterns.konigi.com/dashboards/mobile-adaptation - Group: Screenspace - Level: context - Status: published - Updated: September 10, 2026 - Also called: stacked cards, swipe between panels --- ## Problem The page loaded from a link in an alert. The person reading it is standing up, holding a phone, half awake, and needs to know within about fifteen seconds whether to open a laptop. ## Solution Decide what the phone version is *for*, then build that, rather than reflowing the desktop grid and hoping. The distinction that makes this tractable: the mobile case is almost never analysis. It is triage. Somebody wants to know whether this is real, how bad, and whether it can wait. A phone layout designed for those three questions is a different page from the desktop one, and much shorter. Reflow alone fails predictably. A twelve-column grid collapsing to one column produces an order determined by the source, which is usually the order panels were added. The most important panel ends up eighth. Nothing about the desktop layout expressed priority in a way the reflow could preserve, which is why priority has to be declared rather than inferred. Three specific capabilities disappear on touch and need replacements rather than degradation. **Hover is gone.** Anything only available in a tooltip is unavailable. Values that mattered enough to be on hover need to be on the page. **Precision pointing is gone.** WCAG's target size minimum exists because fingers are not cursors; drag-to-zoom on a chart, legend toggling and dense table rows all need larger targets or different interactions. **Horizontal space is gone.** Wide tables and long legends have no version that works, so they need to become cards, or to be dropped. The honest position, which few teams take, is that some dashboards should have no mobile version at all. A forty-panel investigation surface has no fifteen-second story, and shipping a scrollable version of it teaches people to squint at something that cannot help them. ## Use when People genuinely arrive on a phone, usually from an alert or a link, and there is a short answer worth giving them. ## Don't use when The page's whole value is density and comparison. Better to show a deliberate summary with a "open on desktop" path than a technically-responsive page nobody can use. ## Trade-offs A real mobile version is a second design with a second maintenance cost, and it drifts. Deciding what to cut is a political conversation, because every panel belongs to someone. Testing on real devices at real brightness in real conditions rarely happens. And a good mobile summary creates its own risk: people start making decisions from it that needed the full picture, because it was easier to reach. ## Checklist - What are the two or three questions someone on a phone actually has? - Does panel order in the collapsed layout reflect priority, or source order? - Is anything essential only reachable by hover? - Do interactive targets meet the minimum size for fingers? - What happens to wide tables and long legends? - Is chart text legible at phone size, or scaled-down desktop type? - How does this behave over a bad mobile connection? - Is there a clear route to the full version when the summary is not enough? - Has anyone opened this on a phone, at night, at low brightness? - Should this dashboard have a mobile version at all? ## Compare **Grafana** reflows its grid to a single column below a breakpoint, which keeps every dashboard technically usable on a phone and rarely produces a priority order anyone chose. **Datadog** and most modern observability products ship dedicated mobile apps rather than responsive dashboards, which is an admission that triage on a phone is a different product rather than a narrower page. **Sentry** ports well by accident, because its primary surface is a list of issues and lists are what phones are good at. **Public status pages** are again the best-adapted example, since they are frequently read on a phone by someone who just found out something is broken, and they carry roughly three pieces of information for exactly that reason. ## Related Panel grid is what reflows, and the entry that covers why collapse order is rarely the priority order. Hover detail is the capability that disappears entirely. Sidebar and canvas is the navigation that has to become something else. Detail on demand is the interaction pattern that adapts best to a small screen. Header KPI strip is usually the only part of a dashboard worth keeping on a phone. ## 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 at phone width** — captured September 10, 2026, Home Assistant public demo (signed out, 390px viewport). personal, medium density, light theme, mobile. The same dashboard as the desktop capture at 390 pixels. It is a reflow rather than a designed phone page, and for this content that is defensible—a list of things with states doesn't need width the way a chart does, sections stay intact, nothing is dropped, and the slider becomes a much better touch target than it was with a mouse. What doesn't survive is the order. On desktop the sections sit in three columns and each column reads down: Welcome, Energy, Outdoor on the left. On the phone they come out row by row instead, so Energy falls from second in its column to fourth on the page and Kitchen climbs from the far right to third. Nothing about the desktop layout expressed which of those mattered more, so the reflow had nothing to preserve and picked an order from the source. The rail is the other casualty and goes exactly where these always go, into a hamburger. Hotspots in this capture: - [Mobile adaptation](https://patterns.konigi.com/dashboards/mobile-adaptation) *(this pattern)* — Reflowed, not rebuilt. Section order comes out row-major here and column-major on desktop, so priority shifts. - [Sidebar and canvas](https://patterns.konigi.com/dashboards/sidebar-and-canvas) — The rail is gone. Everything it held is now behind one button, which is the usual and unavoidable trade. - [Resizable card grid](https://patterns.konigi.com/dashboards/resizable-card-grid) — Two columns of cards inside each section rather than a single stack, so the page stays short enough to scroll. - [Header KPI strip](https://patterns.konigi.com/dashboards/header-kpi-strip) — The three chips survive the switch intact, which is what a strip of four to six is for. ## Related patterns - [Panel grid](https://patterns.konigi.com/dashboards/panel-grid) — Many independent panels need to share one screen without fighting for it. - [Hover detail](https://patterns.konigi.com/dashboards/hover-detail) — The chart shows shape; the viewer needs the exact value at one moment without leaving it. - [Sidebar and canvas](https://patterns.konigi.com/dashboards/sidebar-and-canvas) — Navigation between many dashboards needs to be persistent without stealing the canvas. - [Detail on demand](https://patterns.konigi.com/dashboards/detail-on-demand) — A small panel needs to become a big one for a moment. - [Header KPI strip](https://patterns.konigi.com/dashboards/header-kpi-strip) — The first row of the page has to answer 'is it okay' before the rest asks 'why'. ## Sources - [W3C, WCAG 2.2—Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) - [Nielsen Norman Group, Progressive Disclosure](https://www.nngroup.com/articles/progressive-disclosure/) - [Grafana, Use dashboards](https://grafana.com/docs/grafana/latest/visualizations/dashboards/use-dashboards/) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.