Anatomy of a Dashboard
A dashboard puts the numbers that matter (and the tools to slice them) on one glanceable screen, so decisions can be made without digging through raw data.
Every part of the example below is labelled and explained. This page is one of 55 annotated tours on AnatomyOf, a free, open-source project by LunarWerx Studios .
What is inside a Dashboard page
Sidebar navigation The vertical menu switching between the app’s main sections.
A persistent left sidebar lists the top-level areas of the product (Overview, Reports, Customers…) and marks the current one. It stays put as content changes, giving users a stable map of where they are and where they can go. Dashboards favour a sidebar over a horizontal nav because they are dense, data-heavy apps used for long sessions. Vertical space is cheap and the extra room lets labels and icons coexist. On narrow screens it typically collapses to icons or a hamburger.
Top bar The header with the page title, search, and account menu.
The top bar names the current view and hosts global controls: search, notifications, and the user/account menu. It is the dashboard’s constant frame, distinct from the sidebar’s section navigation. Keeping account and global actions here (separate from the data below) means the workspace can change entirely while the controls stay exactly where the user expects them.
Search A field for jumping straight to a record or metric.
Global search lets users pull up a specific customer, report, or metric without navigating the hierarchy. In data-heavy tools it is often the fastest path to anything, so it earns a prominent, always-visible spot in the top bar. Good dashboard search is scoped and typo-tolerant, shows results grouped by type, and supports keyboard shortcuts (a slash or ⌘K) since power users live in these tools all day.
KPI / stat card A single headline number with its trend.
A KPI card surfaces one key metric big and bold (revenue, active users, churn) usually paired with a comparison to the previous period (▲ 12%). A row of them across the top answers "how are we doing?" in a glance. The value should dominate, the delta should be color-coded (green up / red down, but mind that "up" is not always good. Churn rising is bad), and each card should link through to the detail behind the number.
Chart A visualisation showing a metric over time or by category.
Charts turn rows of numbers into shape (a trend line, a bar comparison, a distribution) so patterns and outliers jump out far faster than a table would allow. Choosing the right chart type for the question (time → line, parts-of-whole → bar/stacked, correlation → scatter) is most of the battle. Label the axes, keep the ink-to-data ratio high, and avoid decorative 3D or dual axes that mislead. A chart’s job is an honest, instantly-readable summary, not decoration.
Filter control Narrows what the dashboard shows: date range, segment, etc.
Filters (a date-range picker, a segment dropdown, toggles) let one dashboard answer many questions by scoping the data down. The current filter state should always be visible so users trust what they are looking at. Sensible defaults matter ("last 7 days" beats an empty picker) and applying a filter should update every card and chart consistently, so nothing on screen silently disagrees with the chosen range.
Data table Rows and columns of the underlying records.
When users need the exact figures rather than the shape, a table lays records out in sortable, scannable columns. It is the drill-down layer beneath the charts, the "show me the actual rows" view. Good dashboard tables support sorting and column alignment (numbers right-aligned), keep the header visible while scrolling, and let users export. Dense but legible beats pretty-but-sparse here.
Table row A single record across the table’s columns.
Each row is one entity (a customer, an order, a transaction) with its fields spread across the columns. Consistent alignment lets the eye run down a single column to compare values quickly. Rows are frequently interactive: hovering highlights them, clicking opens a detail view, and row-level actions (edit, delete) appear on hover to avoid cluttering every line at rest.
Pagination Controls for moving through large result sets in pages.
Pagination breaks a large dataset into pages so the browser only renders a manageable slice at a time, keeping the table fast and the page short. It shows where you are ("1 / 12") and lets you step or jump between pages. The alternative (infinite scroll) suits feeds but frustrates tables where users want a stable position and a sense of total size. For record lists, explicit pages usually win.
Official Dashboard site · All languages on AnatomyOf
Every language on AnatomyOf
Concept tours
The interactive tour needs JavaScript. Enable it to hover a callout and trace it into the code.