Dashboard & Data Table UI Rules

A dashboard's job is to answer "is everything okay, and if not, where do I look" in under five seconds — every design decision should serve that, not aesthetic completeness.

Hierarchy: the most important number is biggest

• Identify the single most important metric on any given dashboard view and give it the largest visual weight (size, position, contrast) — if everything is emphasized equally, nothing is, and the user has to read the whole screen to find what matters.
• Use size, color, and position together to establish a clear reading order (primary metric → supporting metrics → detail) — don't rely on layout position alone when the primary metric could be visually buried among equally-styled cards.
• Reserve red/warning colors strictly for things that need attention — using accent colors decoratively on neutral metrics trains users to ignore the color signal when it actually matters.

Progressive disclosure

• Show a high-level overview first (totals, trends, top-line status); require an explicit action (click, expand, navigate) to reach drill-down detail — never front-load every possible detail onto the first screen.
• Design drill-down as a natural continuation of the overview (clicking a chart segment filters the detail view to that segment), not a disconnected separate page the user has to re-orient on.
• Default to the time range and filter state most users need most often (e.g. "last 7 days"), and make it obvious how to change it — don't force every user to reconfigure filters on every visit.

Table rules

• Right-align numeric columns (so digits stack for easy comparison) and left-align text columns — center-alignment makes columns harder to scan and compare at a glance.
• Make sortable columns obviously interactive (hover state, sort indicator icon) and always show which column is currently sorted and in which direction — an unlabeled sort state forces the user to guess.
• Use a sticky header row on any table taller than one viewport — losing the column labels while scrolling forces the user to scroll back up to remember what a column means.
• Paginate or virtualize tables beyond a few hundred rows rather than rendering everything at once — unbounded row counts degrade both render performance and scannability; show a clear total count and page position regardless of which approach is used.

Chart type honesty

• Match the chart type to the actual relationship in the data: time series → line chart, part-to-whole → bar or stacked bar (pie only for very few categories), correlation → scatter — do not pick a chart type for visual novelty over legibility.
• Never truncate a bar chart's y-axis to start above zero — this exaggerates differences between values and misrepresents the data; line charts showing trend/rate of change are the exception where axis truncation can be appropriate and should be labeled as such.
• Label axes, units, and time ranges explicitly on every chart — a chart with unlabeled axes forces the viewer to guess what they're looking at.

Empty, loading, and error states

• Design an explicit empty state (with guidance on how to populate the data) for every table and chart — a blank chart with no explanation reads as broken, not as "no data yet."
• Show a loading skeleton that matches the eventual layout shape, not a generic spinner replacing the whole view — this prevents layout shift when data arrives and keeps the user oriented.
• Design a distinct error state (not just an empty state) for failed data fetches, with a retry action — silently rendering an empty state on fetch failure hides a real problem from the user.

Refresh and timestamp visibility

• Always show when the displayed data was last updated ("as of 2 minutes ago") for any dashboard that isn't real-time — users need to know whether they're looking at current state or stale data before acting on it.
• Make manual refresh available and obvious wherever auto-refresh isn't running continuously, and indicate clearly when auto-refresh is active versus paused.

Filtering and comparison

• Keep active filters visibly displayed as removable chips or a summary bar, never hidden inside a collapsed panel — a user who forgets an active filter is applied will misread the data as the full picture.
• Support comparison against a prior period (previous week, same period last year) directly in the primary view when trend matters, rather than forcing the user to manually screenshot and compare two separate views.

Responsive density

• Design a genuine mobile layout for dashboards that will be viewed on small screens — stacking cards vertically and shrinking a desktop table until it's unreadable is not a responsive design, it's a broken one.
• Let users choose information density (compact vs. comfortable row spacing) on data-heavy tables where both power users and occasional users share the same view — their needs for scan speed versus readability genuinely differ.