Choosing a Density for an Analytics Dashboard
A generous, modern-looking redesign made a dashboard slower for the people who used it all day.
Definition
A decision case about information density: how a design that reviewed well internally reduced task efficiency for daily users, and how offering a preference resolved it.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
A composite scenario assembled from situations that recur across teams. It is written to teach reasoning rather than to report on a named company, and outcomes are stated directionally rather than as invented measurements.
Problem
After a visual redesign, experienced users complained the dashboard had become slower to use, while new users and stakeholders praised its clarity.
Context
An analytics product used daily by a small number of analysts and occasionally by a much larger number of managers. The redesign applied the company's marketing-site spacing scale to the product.
Constraints
- The visual refresh was already shipped and had executive support.
- Analysts represented a minority of users and a majority of revenue-linked usage.
- Screen sizes ranged from a laptop to a wall display.
- Touch target minimums applied because a proportion of use was on tablets.
Decision
Keep the new visual language and add a density control with three levels, implemented as a multiplier on the spacing tokens, defaulting to comfortable and remembered per user.
Rationale
Both groups were right. Occasional users benefited from the space; daily users lost the ability to see a full working set without scrolling, which cost them on every task. Density is a legitimate user preference rather than a single correct value, and implementing it as a token multiplier meant one set of components could serve all three levels.
Evidence used
- Task timing before and after the redesign, segmented by user tenure, which showed the two groups moving in opposite directions.
- Counting how many rows were visible without scrolling before and after.
- Interviews with analysts describing the scroll cost on a task they performed dozens of times a day.
- Verification that compact mode still met minimum target sizes on touch devices.
Trade-offs accepted
- Three densities to design, build and test rather than one.
- Screenshots in documentation and marketing no longer matched what every user saw.
- A settings decision added for users who did not need one, mitigated by a sensible default.
Outcome
Analyst task times returned to their pre-redesign levels in compact mode, and occasional users kept the more spacious default. The density setting became one of the most-used preferences in the product.
Alternatives considered
Revert the redesign
Why not: It would have discarded genuine improvements for occasional users, who are the majority by headcount.
Split into two products or two modes
Why not: Two full interfaces doubles maintenance and strands users who move between the roles.
Choose density automatically by screen size
Why not: Screen size does not indicate expertise. An analyst on a laptop needs compact; a manager on a large display does not.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applies when you are designing
Concepts behind this decision
What the reasoning in this case rests on.
- Target SizeAccessibility
- Dashboard UX ChecklistChecklist
- Design TokensDesign system
- Flexibility and Efficiency of UseHeuristic
- Power Law of PracticeLaw
- DashboardsPattern
- DensityUI foundation
- Spacing SystemsUI foundation