Bygger på:Konstant och kontextuellt↗ Foundation

Grids, Tables & Data Visualization — Aleris Design Tokens

Status

Design system foundation. Covers layout grid, data table component principles, and data visualization guidelines. Builds on existing token architecture (aleris-tokens.css) where chart palette and spacing scale already exist.

Part 1: Layout Grid

The Grid

12-column grid. Gutters use spacing tokens. Max-width capped per surface mode.

Columns:    12
Gutter:     var(--spacing-md)  — 24px
Margin:     var(--spacing-sm)  — 16px (mobile), var(--spacing-md) — 24px (desktop)
Max-width:  1200px (communicative), 1440px or fluid (instrumental)

Why 12 Columns

12 divides cleanly into halves, thirds, quarters, and sixths. It covers every common layout pattern without custom math. This is settled consensus across the industry — the value is in not overthinking it.

Grid and Surface Temperature

Communicative surfaces use the grid loosely: content typically spans 6–8 columns with generous margins, creating the whitespace and reading rhythm that defines Aleris's warm register. Max-width is capped to maintain comfortable line lengths.

Instrumental surfaces use the grid fully: content can span all 12 columns, sidebars take 2–3 columns, and the layout maximizes usable screen area. Max-width is fluid or set at a higher breakpoint.

The grid is the same structure in both modes. The difference is how much of it is used.

Grid Tokens

--grid-columns: 12;
--grid-gutter: var(--spacing-md);
--grid-margin-mobile: var(--spacing-sm);
--grid-margin-desktop: var(--spacing-md);
--grid-max-width-communicative: 1200px;
--grid-max-width-instrumental: 1440px;

Responsive Behaviour

Use CSS Grid with fr units and container queries. The grid adapts to its container, not just the viewport — this matters when the same component appears in different contexts (full-width page vs sidebar panel).

Breakpoints follow the spacing scale logic but are practical, not mathematical:

--breakpoint-sm: 640px;
--breakpoint-md: 768px;
--breakpoint-lg: 1024px;
--breakpoint-xl: 1280px;

Part 2: Data Tables

Two Types of Tables

Read tables display data. The user scans, compares, and perhaps filters or sorts, but doesn't edit. Patient lists, appointment overviews, compliance reports.

Work tables (data grids) are interactive workspaces. The user edits inline, takes actions per row, reorders, configures columns. Scheduling tools, checklist administration, CMS interfaces.

Both use the same token foundation but have different interaction patterns. Read tables are simpler; work tables are more complex. Don't design one pattern and stretch it to cover both.

Table Tokens

/* Row density — three levels, user-selectable in instrumental surfaces */
--table-row-height-compact: 36px;
--table-row-height-default: 48px;
--table-row-height-comfortable: 64px;

/* Cell spacing */
--table-cell-padding-x: var(--spacing-sm);    /* 16px */
--table-cell-padding-y: var(--spacing-2xs);   /* 8px */

/* Header */
--table-header-bg: var(--surface-subtle-cold);
--table-header-text: var(--text-primary);
--table-header-weight: var(--font-weight-bold);
--table-header-size: var(--font-size-xs);      /* 14px — smaller than body */
--table-header-transform: uppercase;
--table-header-letter-spacing: 0.05em;

/* Body */
--table-body-size: var(--font-size-sm);        /* 16px — one step below body */
--table-body-color: var(--text-primary);

/* Row states */
--table-row-hover-bg: var(--surface-subtle-warm);
--table-row-selected-bg: var(--color-petrol-100);
--table-row-border: var(--border-default);

/* Zebra striping — optional, off by default */
--table-row-stripe-bg: var(--color-sand-100);

Table Design Principles

Identifier in the first column, always. Whatever identifies the row (patient name, clinic name, document title) goes in column one and stays fixed during horizontal scroll. This is both a usability principle and a privacy principle — in clinical contexts, the identifier column is the one that carries patient safety weight.

Numbers right-aligned, text left-aligned. Decimal points and digit columns should line up vertically for scanning. Text reads left to right. Currency and percentages align right. Dates can go either way depending on whether they're scanned as text or compared as values.

Density is a user choice, not a design choice. Offer compact, default, and comfortable row heights in instrumental surfaces. Different tasks need different density: scanning a long list calls for compact; reviewing individual records calls for comfortable. Don't decide for the user — let them decide based on their current task.

Headers are quieter than data. Table headers use smaller type, uppercase, and wider letter-spacing — they're navigational landmarks, not content. The data in the cells is what the user came for. Headers serve the data, not the other way around.

Avoid full-width tables. Stretching a table to fill available width creates meaningless whitespace between columns that makes data harder to scan. Let the table take the width it needs, cap it, and let the page breathe around it.

Actions near the identifier, not at the far right. If a table has row actions (edit, view, delete), place them next to the identifying column — not at the opposite edge of the table where the user has to scan the full width to find them.

Visual summary above, not instead of. When a table has aggregate meaning (totals, averages, trends), show a summary view above the table. This lets users see the pattern before the details. Sparklines embedded in table cells can serve this purpose for trends within the data.

Table and Privacy

Patient tables in clinical contexts need the patient identification component from the privacy JTBD analysis (Job 2.1): name + one secondary identifier, consistently placed, full ID expandable. In non-clinical tables (compliance dashboards, aggregate reports), patient identity is replaced by pseudonymised references or removed entirely.

Export from any table follows the tiered export dialog pattern: anonymous aggregate = no friction, individual data = confirmation + logging, bulk = formal confirmation + purpose.

Part 3: Data Visualization

Existing Foundation

The token file already provides a solid chart palette (12 colours in cool/warm series with paired assignment for comparisons) and a goal-status palette (traffic-light with accessibility requirement for icon/shape pairing). What follows are principles for how to use them.

Five Principles for Aleris Data Visualization

These are inspired by Edward Tufte's work but translated into practical Aleris guidance — not academic rules.

1. Show the data, then stop

Every visual element in a chart should either represent data or directly help interpret it. If it does neither, remove it. This applies to gridlines (lighten or reduce), borders (usually unnecessary), background fills (almost always unnecessary), decorative icons, and 3D effects (never).

In practice: start with just the data marks (bars, lines, points). Add elements one at a time only when the chart becomes harder to read without them. The moment you stop needing to add things, you're done.

This is the same principle as Aleris's "calm, professional aesthetic" applied to data: the chart should feel considered and restrained, not decorated.

2. Let comparison happen naturally

The most useful thing a chart can do is make comparison easy. The design should support this without requiring the user to work for it.

Common baseline. Bars start from the same line. Lines share the same Y-axis when comparing similar measures. If scales differ too much, use separate charts placed next to each other rather than dual Y-axes (dual axes create confusion more often than they create insight).

Small multiples over complex single charts. When comparing the same measure across 5+ categories (clinics, departments, time periods), repeat a simple chart for each category rather than cramming all series into one chart. Small multiples are easier to scan, less prone to visual clutter, and don't require a colour-coded legend that the user has to memorise.

Consistent colour assignment. If "Aleris Stockholm" is chart-1 (teal) in one chart, it should be teal in every chart on the same page. The paired assignment tokens (chart-pair-1-a/b etc.) exist for this — use them for any view where two series are compared.

3. Use colour with intention, not just variety

The chart palette has 12 colours. That doesn't mean a chart should use 12 colours. Most effective charts use 2–4 colours. Using more than 6 in a single chart is a signal that the visualisation should be restructured (filtered, split into small multiples, or simplified).

Sequential: Use chart-1 through chart-N in order for categorical data with no inherent ranking. The ordering puts the highest-contrast colours first.

Paired: Use the paired tokens (chart-pair-1-a / chart-pair-1-b) when comparing two related series (before/after, target/actual, this year/last year). The cool/warm pairing creates intuitive distinction.

Highlight + mute: For "one thing vs everything else" comparisons, use a single strong colour for the focus item and desaturated grey (chart-11-warm-grey) for all others. This focuses attention without a legend.

Never colour alone. The goal-status palette already mandates icon/shape pairing. Apply the same principle to all charts: supplement colour with pattern, label, or position so that colour-blind users can distinguish series. This isn't just accessibility — it's good information design.

4. Annotate the important, not the obvious

Labels and annotations should mark what matters, not what the reader can already see. A bar chart doesn't need a value label on every bar — label the highest, lowest, or target-crossing bar. A trend line doesn't need a data point marker at every interval — mark the inflection points.

Reference lines (targets, averages, thresholds) are among the most useful annotations. A line showing "national average" or "target" transforms a chart from "here is data" into "here is data in context." Use a dashed or lighter stroke to distinguish reference lines from data.

Direct labelling over legends. Where possible, label data series directly on the chart (at the end of a line, inside a bar, near a data point) rather than asking the user to match colours to a separate legend. This eliminates the back-and-forth eye movement between chart and legend.

5. Respect the reader's time

A chart should be interpretable within a few seconds of looking at it. If it requires extended study, it's either too complex, poorly structured, or showing the wrong thing.

Title as insight, not description. "Waiting times by clinic" is a description. "Stockholm clinic exceeds waiting time target in Q3" is an insight. The title should tell the reader what the chart reveals, not what it contains. (There are contexts where neutral titles are appropriate — research presentations, regulatory reports. For operational dashboards, insight titles are better.)

Progressive detail. Show the overview first (the chart). Let the user drill into details on interaction (hover for exact values, click for underlying data, filter to zoom in). This mirrors the surface temperature approach: the default is clean and scannable; complexity is available on demand.

Sparklines in context. Small inline trend indicators (sparklines) embedded in tables or cards are often more useful than standalone charts. They show "is this going up or down?" without requiring the user to navigate to a separate view. The chart palette's first colour (chart-1, teal) works well as a single-colour sparkline.

What to Avoid

Pie charts for comparison. Humans are poor at comparing angles and areas. Use horizontal bar charts instead — they're always more readable and take less space.

Dual Y-axes. They imply a relationship between two measures that may not exist, and they're easy to misread. Use separate charts placed side by side.

3D effects. They distort data perception and add visual complexity without information value. Always flat.

Excessive animation. Subtle transitions when data changes are fine; animated entrances and bouncing bars are noise. Motion should serve comprehension (showing what changed), not decoration.

Dashboard overload. A dashboard with 12 charts is not a dashboard — it's a report page. A dashboard should show 3–5 things that matter right now, with clear paths to explore further. If everything is highlighted, nothing is.

Chart Typography

Charts use the token system but at reduced sizes:

Axis labels:     var(--font-size-xs) / var(--font-weight-regular)
Axis titles:     var(--font-size-xs) / var(--font-weight-bold)
Data labels:     var(--font-size-xs) / var(--font-weight-regular)
Chart title:     var(--font-size-lg) or var(--font-size-md) / var(--font-weight-bold)
Legend:           var(--font-size-xs) / var(--font-weight-regular)

All chart text uses the primary font family. Axis labels and legends use --text-secondary for a quieter tone — the data visuals should dominate, not the labels.

Chart Spacing

Charts breathe with the same spacing tokens as everything else:

Padding inside chart container:     var(--spacing-md)
Space between chart and title:      var(--spacing-sm)
Space between chart and legend:     var(--spacing-xs)
Space between small multiples:      var(--spacing-md)
Minimum bar width:                  var(--spacing-2xs)

Design Decision Record

Decision: 12-column grid with spacing-token gutters, surface temperature controlling utilisation (not structure). Why: The grid is infrastructure, not expression. The same 12 columns serve both communicative and instrumental surfaces. The difference is how many columns content occupies — not how the grid is built.

Decision: Three density levels for table rows, selectable by the user in instrumental surfaces. Why: Different tasks need different density. Scanning a list of 50 patients calls for compact; reviewing one patient's checklist history calls for comfortable. Designers shouldn't pre-decide — the user's current task determines the right density.

Decision: Table headers use smaller type than body, uppercase, with wider letter-spacing. Why: Headers are navigational landmarks. Data is content. The visual hierarchy should reflect this: data is primary, headers are secondary. This inverts the common pattern of bold/large headers dominating small data — and it's what actually helps scanning.

Decision: Data visualisation follows five practical principles rather than a rigid rule set. Why: Rigid rules ("never use more than 5 colours", "always label directly") break in specific contexts. Principles ("use colour with intention", "respect the reader's time") guide judgment across contexts. The design system should develop judgment, not enforce compliance.

Decision: Pie charts are not recommended; horizontal bar charts are preferred for categorical comparison. Why: Humans compare lengths more accurately than angles or areas. This is well-established in perception research (Cleveland & McGill, 1984, refined by Heer & Bostock, 2010). Horizontal bars also handle long category labels better and work better on mobile.

Open Questions

  • Should table density be a user preference that persists across sessions, or reset per view? (Hypothesis: persist — it reflects a personal working style, not a per-task choice.)
  • How do small multiples work on mobile? The pattern depends on placing multiple charts side by side, which breaks on narrow screens. (Options: vertical stack with consistent scale, or swipeable horizontal scroll.)
  • Does the chart palette need a dedicated "sequential" ramp for heatmaps or choropleth maps? The current palette is categorical (distinct colours), not sequential (gradient from light to dark). If map visualisations are in scope, a sequential ramp derived from petrol (light teal → dark petrol) would be needed.
  • Should the data vis principles be illustrated with reference implementations (e.g. a "good chart" vs "bad chart" example page), or is the written guidance sufficient?

Key References

  • Edward Tufte, The Visual Display of Quantitative Information (1983) — foundational principles: data-ink ratio, small multiples, graphical integrity
  • Edward Tufte, Envisioning Information (1990) — layering, colour use, small multiples in depth
  • Steve Few, Information Dashboard Design (2006) and Show Me the Numbers (2004) — pragmatic dashboard and chart design for business contexts
  • Tamara Munzner, Visualization Analysis and Design (2014) — academic framework for choosing visualisation type based on data type and task
  • Andrew Coyle, "Design Better Data Tables" — the definitive practitioner reference for table UI patterns
  • Stéphanie Walter, "Enterprise UX: Essential Resources for Complex Data Tables" — curated resource collection
  • Cleveland & McGill, "Graphical Perception" (1984) — empirical basis for why position/length beats angle/area
  • JMIR 2026 scoping review of healthcare dashboard design practices — current state of the field