Dashboard Density: How Much Data Belongs on One Screen?

Every operator screen is a negotiation between two goods: more information per glance, and more clarity per number. Cram everything on and nothing stands out; strip it back too far and the operator is paging through five screens to answer one question. This guide covers how we pick a density when building Niagara UI templates - try the playground above as you read.

Match density to viewing distance: a control room wall read from across the room, a desk monitor an arm's length away, and a tablet in the field are three different jobs. As distance grows, drop the tile count and raise the type size. The same page usually needs two densities, not one compromise.

Group before you compress: density feels chaotic when unrelated points sit shoulder to shoulder. Cluster related points into cards - one air handler, one loop, one hall - and let whitespace do the separating. A well-grouped dense page scans faster than a sparse but scrambled one.

Prefer drill-downs to dumping: the overview page answers "is anything wrong?" and the equipment page answers "what exactly?". Trying to make one page do both jobs is where 200-point spaghetti screens come from. Progressive disclosure keeps each page honest about its question.

Let hierarchy carry the load: a big value over a small label survives compression far better than uniform text. When everything on a card is the same size, density destroys it; when the value dominates, you can halve the padding and it still reads.

Apply the three-second rule: put an abnormal value somewhere on the page and time a colleague finding it. Around three seconds is the bar. If it takes longer, the screen is too dense for its viewing distance - or the abnormal state isn't coded strongly enough.

The playground above uses nothing exotic - the densities are just different stops on the same 8px spacing scale and type scale from our graphics standards. Pick the stop that matches the room, not the one that fits the most numbers.