Carbon Design System: Empty States and Dashboards (IBM)
IBM’s open-source design system. Like the guideline pages already cited in Carbon Design System: Accessibility, Content, Color, Motion, and Spacing Guidelines (IBM), these two pattern pages are generated from the carbon-design-system/carbon-website GitHub repository.
License: Apache License 2.0 — same basis as Carbon Design System: Accessibility, Content, Color, Motion, and Spacing Guidelines (IBM), confirmed by the repository’s own LICENSE file.
Key points
- Empty states distinguishes three basic scenario types — no-data (first use, nothing populated yet), user-action (a search with no results, or a completed-process confirmation), and error-management (a permissions, systems, or configuration issue) — each needing a different level of detail and directness. A basic empty state is built from an optional image, a title stated as a positive next step rather than an absence (“Start by adding data assets,” not “You don’t have any data assets”), a body explaining the next action, and a primary action as a button, an inline link, or a pointer to the relevant UI element. Layout guidance covers left-aligned blocks for most cases (a small-tile exception centers the image to avoid the state reading as skippable content), and a hard accessibility rule: an empty state should fully replace the element it stands in for — a table’s headers and footer included — so a screen reader doesn’t have to read an entire empty structure before reaching the message that there’s nothing in it.
- Empty states also names two “in-depth” alternatives for a first-use empty space beyond the basic pattern — in-line documentation (a more detailed explanation for a primary feature, following Progressive Disclosure to link out to fuller docs) and starter content (pre-built, tinkerable sample data or pre-configured workflows that save a new user setup time) — and states that its own dedicated guidance for onboarding and for error states was still in planning as of this page’s publication, so its onboarding mention here is a brief pointer rather than a fully worked-out pattern.
- Dashboards splits dashboard design into two types by purpose: a presentation dashboard gives a big-picture, at-a-glance status of key business metrics (its own worked examples: a car’s dashboard, a stock ticker board), prioritized by an F-shaped reading pattern with the most important metric top-left and decreasing importance following that scan path; an exploration dashboard instead supports active interaction with the data (search, sort, filter, drill down), and needs consistent chart layout/legend placement across its charts, linked charts that update together when one is filtered or zoomed, and annotations that call out trends without obstructing the underlying data.
- Dashboards is explicitly marked a work in progress by Carbon itself, so its guidance is comparatively brief next to PatternFly’s dashboard pattern in PatternFly: Empty State and Dashboard Design Guidelines (Red Hat).