Data Tables, Data Visualization & Dashboards

Data-heavy UI succeeds when structure carries the cognitive load: users compare, scan, and decide — they don't decode. Tables are for looking up and comparing exact values; charts for seeing shape (trend, outlier, proportion); dashboards for at-a-glance monitoring with a path to detail.

Data tables

• Column alignment: right-align numbers and use tabular (fixed-width, lining) figures so digits and decimal points line up vertically — this is what makes magnitude comparison down a column possible. Left-align text. Align each header with its column's data. Avoid center-aligning data columns; it destroys the scanning edge. Typographic conventions, not lab findings — but universal across financial practice and stated in the Material, Carbon, and Fluent table specs.
• Row density: offer compact/regular/comfortable options where users live in the table daily (IBM Carbon and most enterprise systems ship 3 sizes, roughly 32/40–48/56+ px rows) — compact for expert scanning, comfortable for touch and mixed content. Zebra striping or row borders aid tracking across wide tables; pick one, not both.
• Fixed headers and frozen columns: keep the header row visible under vertical scroll (else numbers lose their meaning) and freeze the identifying column(s) under horizontal scroll so rows stay anchored to identity; signal frozen edges with a shadow or divider.
• Sorting: show the current sort column + direction visibly and via aria-sort; default-sort by the column users care about most, not insertion order.
• Filtering: show applied filters as removable chips near the table with a result count and one-click "clear all" — invisible filters are a classic "where did my data go?" failure.
• Pagination vs. infinite scroll: pagination gives location sense, reachable footers, stable URLs/bookmarks, and predictable performance — the default for work tables. Infinite scroll suits leisurely feed-browsing but breaks "go back to that row," destroys the footer, and hurts orientation (documented repeatedly by Nielsen Norman Group's listing-page research). A "Load more" button is the honest middle ground. Whatever the mechanism, preserve scroll/selection state on back-navigation.
• Inline editing: edit-in-place beats a form round trip for single-cell fixes: distinguish editable cells on hover/focus, validate inline, save on blur/Enter with explicit success/failure feedback, Escape cancels. For multi-field edits, a side panel or row expansion beats juggling many live cells.
• Bulk actions: row checkboxes + a header "select all" (with an explicit "select all N matching, not just this page" affordance — the Gmail pattern) + a contextual action bar that appears with selection and shows the selected count. Bulk destructive actions get undo or type-to-confirm, per the feedback/errors file.
• Responsive strategies: (1) priority columns — keep identity + the 1–3 decision-critical columns, move the rest behind row expansion or a detail panel; (2) horizontal scroll with a frozen identity column; (3) reflow rows into cards/key-value lists on narrow screens. Choose by task: comparison across rows needs columns preserved; record lookup tolerates cards. Never shrink text below readable size to force fit.
• Table states: distinguish "no data yet" (explain + primary action) from "no results for these filters" (say so + clear filters); load with skeleton rows matching real layout, header and controls in place; on error keep the table chrome and offer retry, not a dead end (see Onboarding, First-Run & Empty States and Feedback, Loading, Errors & Recovery).
• Accessibility: use a real <table> with <th> and scope="col" / scope="row" (or headers/id for complex spans) and a caption/accessible name. Reserve ARIA role="grid" for genuinely widget-like tables needing arrow-key cell navigation with managed focus; a table can be sortable, filterable, and contain links/buttons and still be a plain table (W3C ARIA Authoring Practices Guide draws exactly this line). A misapplied grid role is worse than none.

Data visualization fundamentals

• Chart by question, not by novelty: comparison across categories → bar; change over time → line (bars for few periods); distribution → histogram/box/strip; relationship → scatter; part-to-whole → stacked bar or, for ≤~5 slices, pie (pies force angle/area judgments — low on the perceptual hierarchy — so bars usually beat them for comparison).
• The perceptual hierarchy: Cleveland & McGill (1984, JASA) ranked elementary perceptual tasks by decoding accuracy — position along a common scale > position on nonaligned scales > length > angle/slope > area > volume > color saturation. Prefer encodings high on the list for the values that matter; it's why dot plots and bars outperform pies and bubble charts for precise comparison.
• Data-ink: Tufte (The Visual Display of Quantitative Information,
  1983. — maximize the share of ink that shows data; erase gridlines, borders, backgrounds, and 3D effects that don't ("chartjunk"). Treat as a strong default, not dogma — light gridlines aid value reading.
• Honest axes: bar charts must start at zero because bars encode value as length — truncating the axis makes a 2% difference look like 2×. Lines encode change as slope and position, not length, so a non-zero baseline is legitimate when the meaningful variation would be flattened — but label the axis clearly. Don't dual-axis two unrelated scales to imply correlation.
• Color in charts: sequential ramps for ordered magnitude, diverging for values around a meaningful midpoint, categorical for unordered groups (keep to ~6–8 distinguishable hues). Use tested palettes: ColorBrewer (Cynthia Brewer's cartography palettes, with colorblind-safe flags) and Viridis (perceptually uniform, designed to survive deuteranopia and grayscale printing; matplotlib's default since 2.0). Never encode critical distinctions by color alone; gray out context series and reserve saturated color for the point being made.
• Direct labeling over legends where feasible: label lines at their endpoints, put values on/near marks. Legends force a repeated eye-travel-and-match loop — a widely held practitioner convention (Few, Tufte), not a single canonical study.
• Annotation as narrative: a chart title that states the finding ("Churn doubled after the March price change") plus a marker on the relevant point outperforms a generic label ("Monthly churn"). Reference lines for targets/benchmarks give numbers meaning.

Dashboards

• Purpose types (Few, Information Dashboard Design, 2006): operational — real-time monitoring of ongoing activity, alert-driven; analytical — exploration and comparison, filters and drill-down; strategic — periodic executive KPIs against targets. Mixing them on one screen serves nobody; pick one primary audience and cadence.
• Overview first, zoom and filter, then details-on-demand — Shneiderman's visual information-seeking mantra ("The Eyes Have It," Proc. IEEE Symposium on Visual Languages, 1996). Lead with the summary view; make every aggregate a door to its underlying detail (click a KPI → its trend → its records).
• The 5-second rule — practitioner convention, not a study: the most important status should be extractable within seconds of landing. Operationalize with hierarchy: one dominant answer zone top-left (where scanning starts), supporting detail below.
• Actionable over vanity metrics: cumulative totals only go up and flatter rather than inform; prefer rates, cohorts, and target-vs-actual (critique popularized by Ries, The Lean Startup, 2011). Every number needs an implied "so what" — a comparison, target, or trend.
• Progressive disclosure of detail: sparklines and deltas on the overview; tooltips, expandable panels, and linked full views for depth — drill-down exists so you don't show every dimension at once.
• Refresh and staleness: always show data recency ("as of 14:32") and refresh cadence — silently presenting yesterday's numbers as current destroys trust. Load per-widget, don't blank the whole board.
• Anti-patterns: the wall-of-KPIs (20 equal-weight tiles, no hierarchy — nothing reads as important); chartjunk gauges and 3D pies that spend pixels on decoration; unexplained deltas (▲12% — versus what period? is up good?); rainbow categorical color with no meaning; requiring scroll to see whether anything is on fire.

Sources

• Cleveland, W. S. & McGill, R. (1984). "Graphical Perception: Theory, Experimentation, and Application to the Development of Graphical Methods." JASA, 79(387), 531–554.
• Tufte, E. (1983). The Visual Display of Quantitative Information — data-ink ratio, chartjunk.
• Few, S. (2006/2013). Information Dashboard Design; (2004/2012). Show Me the Numbers — dashboard taxonomy, table/graph selection.
• Shneiderman, B. (1996). "The Eyes Have It: A Task by Data Type Taxonomy for Information Visualizations." Proc. IEEE Symp. on Visual Languages, 336–343.
• Brewer, C. — ColorBrewer palettes (colorbrewer2.org); van der Walt, S. & Smith, N. — Viridis colormaps (matplotlib ≥2.0 default).
• W3C — ARIA Authoring Practices Guide, Grid vs. Table patterns (w3.org/WAI/ARIA/apg); WAI table tutorials.
• Ries, E. (2011). The Lean Startup — vanity vs. actionable metrics.
• Nielsen Norman Group — pagination vs. infinite scroll, data-table design (nngroup.com); Butterick, M. Practical Typography — tabular figures; IBM Carbon, Material, Fluent — data-table specs.