| name | dashboard-ui |
| description | Design and build data-dense dashboards, back-office, and admin apps that surface the few metrics a decision needs. Use when laying out an admin/console screen, KPI strip, chart grid, data table, sidebar nav, or reviewing the visual design and information hierarchy of an internal/operational UI. |
Dashboard & Admin UI
A dashboard optimizes for repeated decision-making under time pressure, not
persuasion. The user returns daily to extract a number, compare it to a target,
and act in seconds. That means less hero typography, more data density, a
stricter color system, and zero decorative motion.
The job: surface the smallest set of metrics needed to make a decision, in the
order the eye scans them, with one accent color and no decorative noise.
When to use
- Building or reviewing an admin panel, back-office console, analytics overview,
ops dashboard, or settings/management screen.
- Laying out a screen with KPI cards, charts, data tables, or a sidebar nav.
- Choosing a chart type, color usage, or where an element belongs on the page.
- Designing empty/loading/error states for an operational UI.
Combine with the shadcn and nextjs-modern skills for implementation — this
skill governs layout and information hierarchy; those govern the components and
data wiring.
1. One job per dashboard
Before laying anything out, write one sentence: who looks at this, and
what decision do they make from it? ("The on-call engineer opens this during
an incident to find which service is degraded.")
- "An overview of the business" / "all the data in one place" is not a job —
it's a database with bad lighting.
- Three audiences = three dashboards. Don't serve every stakeholder from one
screen; make focused screens and link between them.
2. Lead with 3–5 hero metrics
Pick the smallest set of numbers that, glanced at together, tell you whether the
job is going well today. These become the top KPI strip.
- Each KPI card shows three things: the current value (large number), a
delta vs. the previous comparable period (small % with a directional
arrow), and an inline sparkline / trend.
- Use absolute numbers, not normalized ratios, for the hero metric when stakes
are real (
$1,248,000 reads faster than "104% of target").
- Make the delta sign explicit — a green up-arrow next to "+12.5% vs last month"
beats a bare "12.5%".
- A KPI card without a sparkline is just a number; the trend earns its 60px.
- Twelve cards is a wall, not a strip — walls don't get scanned. Cut to 4–6.
3. Lay it out on the F-pattern
Users scan in an F-shape: a horizontal sweep across the top, a shorter sweep
lower, then a vertical drift down the left edge. Place by importance:
- Most important metric top-left — where the eye lands first.
- Secondary metrics extend right along the KPI strip.
- The chart that explains the hero metric sits directly below.
- Detail (tables, drilldowns) flows down from there.
- Filters and time-range pickers go top-right — reachable, but not
competing with metrics for attention.
Keep the primary view to 7–8 elements max. Push secondary detail behind
tabs, drilldowns, or a "View all" link (progressive disclosure).
4. 12-column grid, card-based content
| Region | Width | Purpose |
|---|
| Left sidebar | 240–280px | Nav, workspace switcher, account menu |
| Top bar | Full width, 56–64px | Page title, search, date range, notifs |
| Content area | 12-column CSS grid | KPI cards, charts, tables, detail panels |
- KPI strip of 4 cards → each spans 3 columns. Paired charts → 6 + 6 or
8 + 4 (wide chart + narrow context panel). Full-width table → 12.
- Every content element lives in a card: consistent radius (8–12px),
consistent padding (24px default), consistent border.
- Prefer a 1px border at ~8% opacity over a drop shadow — it reads cleaner
and ages better (Linear/Vercel ship borders, not shadows).
- Whitespace (16–24px) does the grouping — no divider lines, color blocks,
or section headings needed when spacing is right.
- A persistent sidebar on desktop, never a hamburger menu — it's navigation,
not wasted space.
5. Color discipline — one accent, the rest for status
The fastest way to look professional is to use almost no color.
- Two surface colors — off-white/white cards in light mode; near-black in
dark (
#0a0a0a/#111, never pure #000).
- Two text colors — near-black primary, 60–70% gray secondary.
- One accent — interactive elements, links, the active sidebar item, the
hero chart line. That's it.
- Three semantic status colors — green (on track / up), red (at risk /
down), amber (caution). Reserved: they appear nowhere else.
Heuristic: if you removed every color except one accent + three status colors,
does the dashboard still work? If yes, your discipline is right. The moment red
becomes a decorative icon background, you've taught the user that red means
nothing — and broken the most useful signal a dashboard has.
Never use colored card backgrounds. Use neutral cards with a colored accent on
the metric or a status pill.
Use semantic tokens (bg-background, text-foreground, border, ring) per
the shadcn skill — don't hard-code hex.
6. Charts follow data shape
Pick the chart from the data, not because it looks interesting.
| Data shape | Use | Don't use |
|---|
| Trend over time | Line, area, sparkline | Bar-per-day |
| Categorical compare (≤7) | Horizontal bar | Pie, 3D anything |
| Categorical compare (>7) | Sorted table, treemap | Bar chart with 25 bars |
| Composition (parts of a whole) | Stacked bar / single-row stacked bar | Pie with >3 slices |
| High-density patterns | Heatmap | Line chart with 50 series |
| Detail to sort or scan | Table with sortable columns | Any chart |
| Relationship between 2 variables | Scatter plot | "Balanced scorecard" |
- Tables are charts. First-class: sortable columns, sticky headers, status
pills, pagination. Most "this feels janky" complaints trace to a bad table.
- Don't use color as a category. Distinguish series by line style, weight,
or order — five-line charts stop being readable around the third line.
- React charting: reach for Recharts, Tremor, or Apache ECharts.
Mobile dashboards — the rules change
A desktop dashboard squeezed onto a 430px phone is worse than one designed for
mobile. When targeting mobile:
- One dominant KPI at the top, not four.
- Secondary metrics in a 2×2 grid (two columns max).
- Bottom tab bar (≤5 tabs) instead of a sidebar — thumb-reachable.
- Cut the table → a list of the top 3–5 items + "View all".
- Simpler charts: drop axis labels/legends where possible, never >2 series.
Common mistakes to avoid
- The 14-card overview — cut to 4–6; the rest belong on sub-pages.
- Colored card backgrounds — neutral cards + accent/status pill instead.
- Pie charts with 7 slices — use a sorted bar chart.
- Hamburger menu on desktop — keep the persistent sidebar.
- Decorative motion — ticking counters, self-drawing charts, hover wiggles.
None help a decision; cut them.
- Design system defined in two places — one source of truth for tokens.
- No empty states. What does it look like with no data / for a new user?
Empty states are ~80% of perceived polish — design them, plus loading and
error states, for every data surface.
Checklist before "done"
- One stated job; primary view ≤ 7–8 elements; 3–5 hero metrics top-left.
- KPI cards show value + signed delta + trend; layout follows the F-pattern.
- 12-column grid; consistent cards (radius/padding/border, not shadows);
spacing does the grouping.
- One accent + 3 reserved status colors only; no decorative/background color;
semantic tokens, no stray hex.
- Chart type matches data shape; tables are sortable/sticky/paginated.
- Empty, loading, and error states designed for every data surface.
