Skip to content
UX Atlas
Case studyCraft conventionIntermediate

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.

Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.

Concepts behind this decision

What the reasoning in this case rests on.