PatternFly: Empty State and Dashboard Design Guidelines (Red Hat)
Red Hat’s open-source enterprise design system. Like the AI guideline pages already cited in PatternFly AI: Conversation and Chatbot Guidelines (Red Hat), these two pattern pages are generated from the patternfly/patternfly-org GitHub repository.
License: MIT License — same basis as PatternFly AI: Conversation and Chatbot Guidelines (Red Hat), confirmed by the repository’s own root LICENSE file.
Key points
- Empty state design guidelines names seven scenario types (getting started, no results, required configuration, no access, back-end failure, success, creation), each mapped to a size variation (extra-small inside a card, small inside a table/wizard/modal, large full-page, extra-large for getting-started or full-page success) and a specific icon and color (a gray rocket for getting started, a gray search icon for no results, a gray wrench for configuration, a gray lock for no access, a red exclamation circle for errors, a green check circle for success). Each scenario gets Do/Don’t copy examples for its heading, body, and button text — the shared rule underneath all of them is to state what the user can do next rather than what’s missing or broken (“Configure your system,” not “You haven’t configured your system”; “No service accounts yet,” not “No service accounts have been found,” which could read as a system error rather than an expected empty state).
- Empty state design guidelines gives content rules independent of scenario: sentence case with a period ending each full body sentence but no period on headings or buttons, second person (“you”/“your”) without ever assigning blame to the user, and dropping “please” as unnecessary formality. Layout rules set a 3xl top spacer for a full-page empty state on desktop (2xl on mobile) with the block horizontally centered, and center embedded empty states (inside a table, card, or wizard) both horizontally and vertically within their container.
- Dashboard design guidelines documents a six-step design process: list the candidate cards a dashboard needs; prioritize that list so the most useful cards win the top rows (this ordering matters most once a responsive layout collapses a four-column grid to one column on mobile); size each card as small/medium/large by asking what format the data needs, how much of it there is, and whether its content is static or dynamic; lay out a column grid (three or four equal-width columns with consistent gutters is most common at 1200–1400px desktop widths) and place the sized-but-empty cards on it; populate the cards with real content and adjust; and iterate on the resulting layout.
- Dashboard design guidelines also defines five standard card templates — an aggregate-status card (a total count plus a breakdown of items in exception/normal status), a trend card (a current value plus a sparkline of its change over time, with an optional time-range filter), a utilization card (a bar or donut chart for a proportional value), a details card (attribute-value pairs, often a description list), and an events card (a time-ordered, filterable list of events) — plus a “dashbar,” a smaller dashboard-within-a-dashboard pinned to the top of the screen for critical state, historical charting, or cross-cutting filters. A specific warning covers dynamic cards whose content can grow or shrink: give a card a fixed height with internal scrolling, or use a flexible layout that reflows around it, rather than letting it leave an unused gap when a neighboring card is taller.