Data Visualization Design in 11 Design Systems (2026)

In October 2024 we picked 11 design systems with strong data visualization design guidance. On 28 October 2026 we opened every one of them again. Seven are still live, four of those at a new address. The other four have retired their guidance, gone offline or been folded into something else.

Data visualization design is the set of rules a product team follows to turn numbers into charts people read correctly: which chart for which question, which colors, how labels and legends behave, and how it all stays accessible. The systems below are where you can see those rules written down by teams that ship data-heavy products.

Data visualization design in 11 design systems: the October 2026 status

All links were opened on 28 October 2026. "Moved" means the old URL now redirects or returns 404 and the guidance lives somewhere else.

The pattern is worth a second look. The systems that kept their data visualization guidance alive tied it to something code consumes: tokens, a chart package, a theme function. The ones that disappeared were mostly written guidance with no package behind it.

The seven that are still live

Each entry says what the guidance does today, not what it did in 2024.

Visma Unified Design

Visma builds accounting, payroll and procurement software, so most of its product surface is numbers. The VUD data visualisation section is unchanged in structure since 2024: three tabs for palettes, best practices and specifications.

• Limit the number of colors: fewer hues, so the chart reads at a glance and stays accessible.
• Shapes and line styles, not only color: line charts vary markers, dashes and thickness, so people with color vision deficiencies can still tell series apart.
• Visual feedback: hover and focus states show which value you're on.

Datadog DRUIDS

Datadog is a monitoring product, so charts are the product. The DRUIDS dataviz page now lists 13 visualization types as React components, from the change graph and heatmap to the topology map and treemap, each tagged with the kind of data it suits.

New since our first look is a typography rule: chart titles never go below the md size of 13px, and a long title wraps rather than shrinks. The pie chart guidance is precise too. Four to seven categories are ideal, and anything with more should be a treemap or a top list.

Atlassian Design System

Atlassian's data visualization guidance moved from a color-new path to foundations/color/data-visualization-color. It is the clearest example in this list of chart rules written as tokens.

• Single color by default: color.chart.brand, with color.chart.neutral for the data you want to fade back.
• Eight categorical tokens: color.chart.categorical.1 to .8, used in order, though the page asks you to keep a chart to 5 or 6 colors.
• Status and severity: success, warning and danger chart tokens, each with a bold variant for the more extreme value.
• Chart chrome uses normal tokens: titles use color.text, gridlines use color.border.

The page also says plainly that sequential and divergent chart colors are not supported yet. Few design systems admit a gap that directly.

Carbon Design System

IBM's Carbon moved its data visualization docs under Building blocks. The overview now lists 24 simple chart types, from area and bar to radar, sparkline and word cloud. Flow diagrams (alluvial, network, parallel coordinates) and spatial charts sit beside them.

Some of those are marked "design only", meaning there is a Figma spec but no code component yet. Carbon Charts ships getting-started tutorials for vanilla JavaScript, React, Angular and Vue, and its own repo and demo site.

Red Hat PatternFly

Red Hat's open source PatternFly moved its charts from /charts/about (now a 404) to components/charts/overview. The biggest change is under the hood.

PatternFly charts are React only, in the @patternfly/react-charts package. Most are built on Victory, and a few now use Apache ECharts. Dark theme support comes from importing a charts stylesheet that exposes chart variables, which you can also use to match charts to the rest of your UI.

GitLab Pajamas

GitLab's Pajamas data visualization overview is live at the same URL and now names an owner: data visualization sits in the design system's extended layer, owned by GitLab's optimize group, with a Slack channel for questions.

The content is still the strongest short argument against pie charts in this list. Values on a common scale are easiest to compare, lengths without a common base are harder, and angles and areas are hardest. Pajamas sorts charts into six categories (hierarchical, relational, spatial, temporal, spatial-temporal and statistical) and says it has built only the three it has use cases for.

Twilio Paste

Twilio's Paste left paste.twilio.design, which now redirects to the GitHub repo. The docs live at paste-dsys.com.

The guidance has become more concrete. Paste ships a usePasteHighchartsTheme hook that takes a Highcharts config and returns it with Paste colors and fonts, and it asks teams to load the Highcharts accessibility module. The page notes that Twilio holds a Highcharts licence for its own products, so a customer building with Paste needs their own.

The four that moved on or went offline

We kept these entries so the list stays honest. If you linked to any of them, the links below show what is there now.

Orange Design System

The Orange Data Display page we linked in 2024 now redirects to the design system's home page. The guidance went into code instead. A February 2024 post explains that Orange chose Apache ECharts in February 2023 as the base for its chart library, mainly on accessibility and eco-design grounds.

That library is ODS Charts, at version 0.5.2 on 28 October 2026. It is an ECharts theme that supplies Orange colors, typography and spacing, SVG rendering and keyboard navigation.

Shopify Polaris

polaris.shopify.com now redirects to Polaris on shopify.dev, which documents Polaris as web components for app surfaces. The data visualization guidelines page is gone. Wayback Machine captures show it redirecting since at least May 2026.

The chart library went too. Polaris Viz was archived on 29 July 2026, with a deprecation notice citing low external use and the cost of support, and a move to an internal-only library.

Sprout Social Seeds

Sprout Social's Seeds data viz page has returned 404 in Wayback Machine captures since March 2026. The last good capture is from February 2026. On 28 October 2026 the Seeds domain did not respond at all.

Mailchimp Pattern Library

Mailchimp's pattern library at ux.mailchimp.com returns a 503 error. Wayback Machine captures show the same error since May 2025, and the last working capture is from January 2025. Its advice was good and is still worth reading in the archive: solid lines for real data, dotted lines for averages and projections, and percent bar graphs instead of pie charts.

Why chart tokens outlast chart guidelines

Read the table again with one question: what could a developer, or an AI coding agent, actually use without a person explaining it?

"Avoid pie charts" is good advice and easy to read. It doesn't tell anyone which component to use instead, which colors, or how many categories are allowed. color.chart.categorical.1 through .8, used in order, does. So does a theme hook that returns a styled chart config. The first kind of guidance is readable. The second is resolvable: it gives a definite answer to "what do I output?"

The systems still standing are the ones that made their chart rules resolvable. That matters more now that agents write a growing share of front-end code, including dashboards. An agent asked for "a bar chart of signups by plan" will follow your chart tokens if it can find them, and will make up colors if all it has is a paragraph. Our guide to design tokens covers the basics. Making components accessible covers the rules your charts should inherit.

This is the problem Supernova's documentation is built around. Your tokens, components and guidelines live in one place, and agents can query them over MCP, so a chart rule is something an agent can look up, not just something a person can read. For more examples of guidance written well, see our roundup of design pattern documentation.

What to check in your own chart guidance this week

Pick the one chart your product shows most and trace it back to your design system.

1. Find the colors: are they tokens with names like chart.categorical.1, or hex values in a Figma file?
2. Find the component: is there a package, a theme function or a wrapper, or does every team pick its own library?
3. Find the rule: is "how many series before we group into Other" written down as a number, the way Datadog and Atlassian do it?
4. Check the links: four of the 11 systems above moved or vanished in two years. If your docs point to theirs, check yours too.

If any answer is "it's in someone's head", that chart is where your data visualization design will drift first. If you want to see what a resolvable version looks like for your own system, Supernova is free to try.