Dashboard UI design is the visual layer: grid, spacing, number typography, and color. It is not the same job as deciding what a dashboard does when data goes stale or a call fails.
That behavior layer, including loading, empty, and failure states, lives in our sibling post on how a dashboard should behave when the data is missing, late or wrong. This post stays on the visual side.
Most guides under this heading come from prototyping tool vendors and UI kit sellers. They cover grid and color, then stop. Almost none mention how to typeset a number, which is strange, since a dashboard is mostly numbers.
If you're polishing an already built MVP's dashboard for a demo rather than designing a mature product, fixing the amateur tells fast covers the quicker version of this same problem.
Here is the craft that actually matters, starting with the biggest gap.
The baseline: grid, spacing, and contrast
The usual guides all agree on the fundamentals. Treat this as table stakes, not as differentiation.
Use a 12 column grid with an 8px base spacing unit. Every gap, padding, and margin should be a multiple of 8: 8, 16, 24, 32. It keeps a dense screen from feeling arbitrary.
Sidebar navigation runs 240 to 280px wide. Switch from a top nav to a sidebar once you pass roughly five destinations. A sidebar scales vertically. A top bar runs out of room fast.
Contrast follows WCAG: 4.5:1 for text, 3:1 for non text elements and for the meaningful parts of a chart, like a data line against its background.
Cards get about 24px of padding, 8 to 12px of corner radius, and 16 to 24px of gap between them.
| Element | Spec | |---|---| | Grid | 12 columns, 8px base unit | | Sidebar width | 240 to 280px | | Sidebar threshold | switch from top nav past roughly 5 destinations | | Text contrast | 4.5:1 minimum | | Non text contrast | 3:1 minimum | | Card padding | about 24px | | Card radius | 8 to 12px | | Card gap | 16 to 24px |
None of that is controversial, and none of it is where a dashboard succeeds or fails. What decides that comes next.
1. Typography for numbers: the biggest gap in dashboard UI design
Almost no dashboard guide mentions how to typeset a number. That is the gap this post exists to close.
Use tabular figures. They are sometimes confused with lining figures, which is a separate setting controlling digit height, not width. In most proportional fonts, a 1 is narrower than a 7 or an 8. Set a column of numbers in a font without tabular figures and the digits wobble. Fixed digit width is what makes place values stack, hundreds under hundreds, and it stops a live updating number from jittering every time a digit changes.
If your font ships tabular figures, font-variant-numeric: tabular-nums switches them on. Inter and Roboto both do, as do the faces system-ui resolves to on the major platforms. If your font does not ship them the declaration silently does nothing, and the font itself is the thing to change, no matter how nice the letterforms look in a hero section.
Right align every number column, and align on the decimal. Alignment is where the numbers land, but what the surface holding them can honestly offer is decided before you draw a row. A list of revenue figures only reads as a comparison if the ones place lines up under the ones place. Left aligned numbers ask the reader to do that alignment in their head, one row at a time.
Give the metric and its label a real size relationship. The value should be large and semibold, roughly 28 to 40px. The label sits small and muted above or below it, roughly 12 to 13px. The number is the content. The label is a footnote that happens to come first.
This matters even more once the numbers are money. On a fintech dashboard, a misaligned decimal or a wobbling digit is not cosmetic. It is a trust problem, because the reader is deciding whether to move funds based on what they can see in that column.
2. The chart to chrome ratio
Every guide gestures at "keep it clean." None of them give you a rule you can check a card against.
Here is one. Inside a card, the actual chart or number should take up the clear majority of the space. Everything else, the border, header, legend, and padding, is chrome. If the chrome competes with the data for room, the card is decoration with a chart stapled to it.
Three moves fix most offenders. Drop the card border when a background shade already separates it from the page, since a subtle fill does the same job a 1px stroke does, for free. Put the legend inline with the title instead of in its own band under the chart. Cut axis labels that just repeat what the title already said. A chart titled "Monthly Revenue" does not need a Y axis labeled "Revenue ($)" underneath it too.
Screenshot a card, then cover everything that is not the number or the chart with your hand. If a third of the card disappears under your hand, the chrome is winning. Cut something.
This is the same instinct that makes a spreadsheet more useful than a slide. Less styling, more signal, so the reader spends attention on the data instead of the frame around it.
3. Dark mode is ergonomics, not style
Plenty of guides hand you hex codes for dark mode. Few explain why those values matter.
A dashboard, unlike a marketing page, gets watched for hours. An operations screen sits on a second monitor for a full shift. That changes the design problem from "look good in a screenshot" to "stay comfortable under sustained attention." Eye strain is a real input here, not an afterthought.
Never use pure black as the background. Bright text on a pure black field glows and shimmers for anyone with even mild astigmatism, which is a large share of people, on any screen. That is an effect in the eye, the same way a car headlight blooms at night, not a property of the panel. On OLED there is a second, separate problem: pure black pixels switch fully off, so shadows stop reading and scrolling can smear. Use a very dark grey instead, the darkest neutral step in your palette rather than the pure black swatch.
The rule to carry forward: dark mode on a dashboard is not a mood. It is a decision about the people who stare at this screen all day. If your dashboard gets glanced at twice a shift, dark mode is a preference. If it gets watched continuously, the way an operations queue or a support floor display does, treat eye strain as a real requirement rather than a theme toggle. A night ward pushes that same call further, into dark mode as a patient safety decision.
4. Above the fold, pinned to a real number
"Above the fold" gets said a lot and measured rarely. Here is the actual number to design against.
On a standard 1080p display, once you subtract the browser chrome, the operating system bar, and the app's own top bar, you are left with roughly 900px of visible height. On a 13 inch laptop it is less, often closer to 700px once the OS dock and browser tabs take their cut.
That is your real budget for the first screen, not the full height of whatever full bleed mockup shipped in the design file. If your top row of KPI cards, your primary chart, and your first table header do not fit inside that number, the layout is being designed against an imaginary monitor.
In practice, this means the highest priority numbers belong in the first 900px. These are the ones a person needs before they decide whether to keep reading. Everything else, the secondary breakdowns, the trend explanations, the export button, can live below the scroll line without cost. Design the hierarchy against the pixel budget you actually have, then check it on a real laptop before you call the layout done.
5. What the sidebar does at 1280, 1440, and 1920
Everyone agrees on 240 to 280px for the sidebar. Nobody says what happens to it as the viewport changes, and that is where most dashboards quietly break.
At 1920px and wider, the full sidebar with icon plus label fits comfortably next to a 12 column grid. At 1440px it still fits, but this is the width where a dense table starts to feel cramped. Consider collapsing to icons by default here, rather than waiting for the user to do it.
At 1280px and below, collapse the sidebar to an icon only rail, roughly 64 to 72px wide, and let the user expand it on demand. Below that width you are usually fighting the layout more than serving the user.
One rule matters more than the exact breakpoints. A collapsed rail must still show which section is active. Give the active icon a filled state, a colored bar, or a background tint, something that survives the label being hidden. A rail that hides where you are is worse than no rail at all. It looks like navigation while quietly failing at the one job navigation has.
If you are inheriting a dashboard rather than building one from scratch, this is exactly the kind of detail a screen by screen usability review is built to catch. It checks whether the screen actually works for the people using it every day, not just whether it looks right in the design file.
The through line
A dashboard is a reading instrument before it is anything else. People do not visit it for delight. They visit it to answer a question fast: is this number good or bad, and has anything changed since I last looked.
Every choice in this post serves that one job. Tabular figures make a column comparable. A tight chart to chrome ratio spends pixels on data instead of decoration. Dark mode protects the person watching for hours. A real fold height keeps the important number where it gets seen first. A sidebar that shows its own state keeps someone from getting lost in their own tool.
Get the grid right, then get the numbers right, because that is what the screen was built to say.
If you are refining an existing product's interface, our UI development work covers exactly this layer, from the grid up to the last pixel of a KPI card.