What is a dashboard design system?

A shared set of design tokens, chart and layout components, number formatting rules and patterns for loading, empty and error states, used by several dashboards so that they look and behave consistently and can be built faster.

Should we build our own charting library?

Rarely. Wrapping a mature charting library with your tokens, formatting and defaults gives you consistency without the cost of maintaining rendering code. Build your own only when no library can draw what you need.

How do we make charts accessible?

Give chart lines and segments at least 3:1 contrast, never rely on colour alone, provide a title and a text alternative such as a data table, make tooltips reachable by keyboard and respect reduced motion preferences.

Do we need a design system for a single dashboard?

Usually not. A good charting library, a few shared formatting functions and a short style guide are enough. Revisit the question when a second or third dashboard is planned.

Can Wideline build a dashboard design system?

We build custom dashboards and the data work behind them, and a shared kit is part of how we keep several dashboards consistent. If an existing open source design system covers most of what you need, we will recommend building on it.

Three dashboards, one design system: building a reusable dashboard kit

Updated 18 October 2026 · 10 min read

The short answer

A dashboard design system is a shared kit of tokens, chart components, number formats and state patterns that lets several dashboards look and behave as one family. Its value is consistency people can rely on: the same metric formatted the same way everywhere, the same colour meaning the same thing, and charts that follow the same rules for axes, tooltips, loading and errors.

A kit is worth building when you have, or will soon have, several dashboards maintained by more than one team. For a single dashboard, a well-chosen charting library and a short style guide are usually enough. If you do build one, start with tokens and number formatting, wrap one charting library rather than writing your own, and give the kit an owner from the first day.

What a dashboard kit contains

A general design system covers buttons, forms and navigation. A dashboard kit adds the parts that general systems tend to leave out: a data visualisation palette, chart components, formatting rules for numbers and dates, and patterns for the states that data screens spend much of their time in, such as loading, empty and partial failure.

Keep the scope honest. The kit should hold what at least two products genuinely share. Anything used once belongs in that product until a second use appears.

Design tokens: colour, type, spacing, radius, elevation and a data visualisation palette.
Layout: grid, card and panel components, filter bars, date range pickers.
Charts: line, bar, area, scatter and table components with shared axes, legends and tooltips.
Formatting: functions for numbers, currencies, percentages, dates and durations.
States: loading, empty, error, partial data and stale data patterns.
Documentation and examples, with guidance on which chart to use when.

Tokens first

Design tokens are named design decisions, such as a colour, a spacing step or a font size, stored as data so that design tools and code read the same values. The W3C Design Tokens Community Group published the first stable version of its format specification in October 2025, giving teams a vendor-neutral file format with support for aliases, themes and multiple brands. It is a community group report rather than a W3C standard, but it is a sensible default for new work.

Structure tokens in tiers. Primitive tokens hold raw values. Semantic tokens give them a purpose, such as the colour for a positive change or the background of a panel. Component tokens apply those purposes to specific parts. Products and themes then change values at the right tier without editing components.

Tier	Example	Who changes it
Primitive	blue-600, space-4, font-size-14	Design system owners, rarely
Semantic	color-positive, color-surface-panel, color-series-1	Themes and products
Component	chart-gridline-color, kpi-value-size	Kit maintainers, when a component changes

Chart components with one scale

Consistency across dashboards comes mostly from charts that follow the same rules. Decide once how axes start (bar charts from zero, line charts where the data needs), how many gridlines to draw, where legends sit, how tooltips behave, how series colours are assigned and how dates are spaced. IBM’s Carbon Design System makes the same point in its dashboard guidance: charts should share layout and spacing and keep legends in the same position.

Wrap one mature charting library rather than writing your own. The wrapper applies your tokens, formatting functions and defaults, and exposes a small, opinionated API. Teams get consistent charts by default, and you can replace the library later without changing every dashboard.

Assign series colours by meaning, not by order of appearance. If revenue is blue on one dashboard, it should be blue on all of them, and a filter that removes a series should not repaint the others.

Number formatting

Inconsistent numbers erode trust faster than any visual flaw. If one screen shows 1.2M and another shows 1,234,567 for the same metric, people start to ask which is right. Put formatting in shared functions that every product calls, and never format numbers inline in components.

Browsers already provide most of what you need. JavaScript’s Intl.NumberFormat handles locale-aware separators, currencies, percentages, units, compact notation such as 1.2K, and explicit signs for changes. Your kit decides the rules on top: decimal places per metric type, how negatives are shown, when to switch to compact notation, and the difference between a percentage and a change in percentage points.

Value type	Rule to decide	Example
Currency	Decimals, symbol position, compact above a threshold	USD 1,234.50 or EUR 1.2M
Percentage	Decimals, and whether 0.5 means 0.5% or 50%	12.5%
Change	Always show the sign; percentage points for changes in rates	+2.1% or +0.25 pp
Count	Thousands separators, compact notation on cards only	12,480 or 12.5K
Missing value	One marker for no data, distinct from zero	n/a or a dash

Empty, loading and error states

Dashboards spend more time in awkward states than designers expect: data still loading, a filter that returns nothing, one widget failing while the rest work, data that has not refreshed since yesterday. Each of these needs a pattern in the kit, or every team will invent its own.

Loading: skeletons that match the final layout, so the page does not jump when data arrives.
Empty: say why there is nothing to show and what the user can change, for example widening the date range.
Error: contained to the widget that failed, with a plain explanation and a retry, never a blank card.
Partial: show what loaded and mark what did not, rather than failing the whole page.
Stale: show when the data was last updated, and mark it clearly once it passes its expected refresh time.

Accessible charts

Charts are often the least accessible part of a dashboard. Under WCAG 2.2, graphical objects needed to understand the content, such as chart lines and bar segments, need a contrast ratio of at least 3:1 against adjacent colours, and colour must not be the only way information is conveyed. Use direct labels, patterns or markers alongside colour, and test the palette for common forms of colour vision deficiency.

Every chart needs a text alternative that matches its complexity. The W3C’s guidance on complex images suggests a short description plus a longer one, and for a dashboard chart the most useful long description is usually the data itself as an accessible table. Make tooltips reachable by keyboard, respect reduced motion preferences for animated transitions, and give each chart a title that states what it shows.

Light and dark themes

Dark mode is not inverted light mode. Data colours that work on white often look harsh or lose contrast on a dark background, so each theme needs its own tuned values for the same semantic tokens. Check contrast in both themes, including gridlines, axis labels and the boundaries between adjacent bars or segments.

Browsers expose the user’s preference through the prefers-color-scheme media query. Follow it by default, offer an explicit choice, and remember the choice. Screenshots, exports and printed reports usually need the light theme whatever the screen shows.

Theming per product

When the kit serves several products or brands, theming happens at the semantic tier: each product supplies its own brand colours, type and logo, and the components stay the same. Keep the meaning of data colours stable across products where you can. A positive change, a warning or a particular series should not change colour because a different brand is showing it.

Test every theme against the kit’s contrast rules automatically. A brand colour chosen for a marketing site can fail as a chart colour, and it is better to catch that in a build than in a customer complaint.

Governance

A design system without an owner decays into a folder of components that each product has copied and changed. Name an owner, publish the kit as a versioned package, keep a changelog, and follow semantic versioning so that teams know when an upgrade might break something.

Make contribution easy and review real. Teams should be able to propose a new component or variant, with a clear bar for acceptance: used in more than one product, documented, accessible, tested. Visual regression tests catch unintended changes to charts, and a deprecation policy gives teams time to move off old components.

When a kit is worth it

A dashboard kit is an investment that pays back through reuse. If reuse is not coming, it is a cost without a return. The table below is a rough guide.

There is also a middle path. Adopting an existing open source design system with data visualisation guidance, and adding only your tokens and formatting rules, gives you much of the benefit for a fraction of the effort.

Situation	Recommendation
One dashboard, one team	A charting library with a short style guide and shared formatting functions
Two or three dashboards, one team	A light kit: tokens, formatting, a chart wrapper and state patterns
Several dashboards across teams or brands	A full kit with an owner, versioning, documentation and theming
Dashboards embedded in products for customers	A full kit, because inconsistency is visible to the people who pay you

Questions

What is a dashboard design system?: A shared set of design tokens, chart and layout components, number formatting rules and patterns for loading, empty and error states, used by several dashboards so that they look and behave consistently and can be built faster.
Should we build our own charting library?: Rarely. Wrapping a mature charting library with your tokens, formatting and defaults gives you consistency without the cost of maintaining rendering code. Build your own only when no library can draw what you need.
How do we make charts accessible?: Give chart lines and segments at least 3:1 contrast, never rely on colour alone, provide a title and a text alternative such as a data table, make tooltips reachable by keyboard and respect reduced motion preferences.
Do we need a design system for a single dashboard?: Usually not. A good charting library, a few shared formatting functions and a short style guide are enough. Revisit the question when a second or third dashboard is planned.
Can Wideline build a dashboard design system?: We build custom dashboards and the data work behind them, and a shared kit is part of how we keep several dashboards consistent. If an existing open source design system covers most of what you need, we will recommend building on it.