Dashboard layout

Problem Context

• The page combines several widgets such as KPI cards, charts, tables, maps, alerts, summaries, filters, saved views, or action queues.
• Users need overview and triage before they choose a deeper report, table, chart, record, or workflow.
• Widgets may share global filters, cross-filter each other, refresh at different times, come from different sources, or represent pinned snapshots.
• The layout must survive responsive breakpoints, role-based permissions, missing data, slow widgets, long labels, and user customization.
• Dashboards often become operational artifacts, so their hierarchy, filters, and freshness need to be auditable and explainable.

Selection Rules

• Choose dashboard layout when the user's task is monitoring or triaging multiple related signals on one page.
• Use data visualization when one chart or analytic question is the main object rather than a page-level arrangement of widgets.
• Use table or data grid when exact row comparison, editing, export, or bulk operations are primary.
• Use saved view when the main object is a named presentation state for one data surface, not a multi-widget overview.
• Use summary box when the page only needs a highlighted text summary or next-step block rather than a full monitoring canvas.
• Use card grid when peer object cards are being browsed, not when widgets with different data roles are composed into a monitoring page.
• Place the most decision-critical and frequently checked indicators before supporting charts, commentary, and long tables.
• Avoid dashboard layout when widgets are unrelated, decorative, or cannot share clear scope, source, freshness, or interpretation rules.
• Avoid making dashboards the default answer for every report; if users need one exact answer, route them to the narrower report or data surface.
• Avoid hiding filters, stale data, permission gaps, or cross-filter state because those determine whether the dashboard can be trusted.

Required States

• Default dashboard with name, purpose, global scope, active filters, freshness, KPI tier, sections, and widget grid.
• Global filtered, cross-filtered, tile-filtered, cleared-filter, stale-widget, partial-refresh, and mixed-refresh states.
• Widget loading, empty, no-access, error, hidden-by-permission, data-delayed, and source-unavailable states.
• Collapsed section, expanded section, pinned or resized widget, customized layout, reset layout, and saved dashboard state when customization exists.
• Drill path from a KPI, chart, exception, or table into the relevant report, saved view, record list, or workflow.
• Mobile and narrow-screen state where dashboard identity, filters, freshness, exceptions, and critical KPIs remain reachable before secondary widgets.

Interaction Contract

• Dashboard title, purpose, active filters, and last updated time apply visibly to the widgets they govern.
• Each tile states what it measures, its unit or target, its source or freshness when relevant, and what happens when users select it.
• Global filters update every governed widget or mark exceptions where a widget is not affected.
• Cross-filtering and drill interactions leave visible state, a clear reset path, and do not silently change unrelated widgets.
• Pinned snapshots, live tiles, cached widgets, and manually refreshed cards are labelled differently when users could interpret freshness incorrectly.
• Responsive reflow preserves priority order, section grouping, widget titles, filters, and exceptions instead of merely packing cards into available space.
• Permission-limited widgets explain what is missing without leaking private metrics, names, counts, or report titles.
• Keyboard focus remains predictable after filters, collapse/expand, refresh, drill, or responsive reordering.

Implementation Checklist

• Define dashboard purpose, audience, refresh cadence, data sources, global filters, key metrics, exception rules, target thresholds, and drill destinations before placing widgets.
• Map the page hierarchy: first-read KPIs, operational exceptions, explanatory charts, supporting tables, source notes, and secondary links.
• Use a responsive grid with stable gutters, minimum tile widths, section containers, and priority-based ordering across breakpoints.
• Model widget metadata: title, description, source, scope, unit, target, freshness, permission, loading, error, stale, empty, and drill URL.
• Show active global filters, cross-filter state, last refresh time, partial refresh failures, and reset controls near the dashboard or affected section.
• Test long metric names, missing widgets, slow widgets, role-limited users, mobile width, zoom, keyboard order, screen readers, stale data, and mixed refresh cadence.
• Keep customizable layout state separate from data filters and provide reset, save, and unsaved-change handling when users can rearrange tiles.
• Log dashboard edits, shared changes, and data-source failures when the dashboard drives operational decisions.

Common Generated-UI Mistakes

• Filling a page with charts before defining dashboard purpose, audience, hierarchy, and decisions.
• Making every widget the same size even though only a few metrics drive action.
• Hiding global filters, cross-filter state, source, freshness, or stale data.
• Mixing live tiles, pinned snapshots, cached reports, and manual refresh cards with no freshness distinction.
• Letting responsive reflow push filters, exceptions, or critical KPIs below decorative content.
• Using dashboard layout when a single chart, table, saved view, summary box, or workflow page would answer the task faster.
• Showing permission-limited blank spaces with no explanation or leaking restricted metric names.
• Allowing dashboard customization to break shared layout, keyboard order, or widget relationships.

Critique Questions

• What decision or monitoring task does this dashboard support, and which widgets matter first?
• Can users see active filters, scope, source, freshness, and cross-filter state before trusting the numbers?
• Which widgets are live, cached, pinned snapshots, manually refreshed, partial, empty, or permission-limited?
• Does responsive order preserve the dashboard's priority and section relationships?
• What happens when a widget fails, refreshes later than others, or is unavailable to this user?
• Would one chart, table, saved view, summary box, card grid, or report page serve the task better than a dashboard?