How to design for density without making it feel cramped

Whitespace is a tool, not a virtue. The right density depends on what the user needs to hold in view at once.

The design industry has over-corrected toward whitespace. Not everywhere. Consumer apps are still cramped in plenty of places. But in design culture, "breathe more" has become a reflex applied regardless of what the interface is actually trying to do.

A financial analyst's data table and a marketing homepage need completely different density. Same with a developer settings panel and an onboarding flow. Applying the same "generous whitespace equals quality" heuristic across all of them produces interfaces that look beautiful in Figma and frustrating in use.

Think about what the user needs to see at once

The question isn't "how much whitespace feels good." It's how much information the user needs to hold in view simultaneously.

For someone monitoring a server dashboard, seeing 20 metrics at once matters. The mental overhead of scrolling to find values they need to correlate is real. The spacious layout that reads well in design review is the one making their job harder.

For someone making a purchasing decision, fewer options visible at once is often better. Comparison is the task, and overloading the view complicates it.

Density should follow task structure. Information-heavy work warrants density. Low-volume, high-engagement tasks warrant space. Most real products have both, and they shouldn't look the same.

What makes density feel cramped

Dense and cramped aren't the same thing. Dense means a lot of information per square inch, usefully organized. Cramped means close together in a way that makes things hard to distinguish or interact with.

The things that push density into cramped:

Touch targets below minimum size. On mobile, 44×44pt is the floor. On desktop, 32px height is a reasonable minimum for interactive elements. Reducing target area in the name of density creates an interaction problem, not an aesthetic one. Reduce internal padding first.

Rows with no visual separation. When list items are too close together, users misclick. A 1px separator or a small gap is enough. You don't need more height, just something marking where one item ends and the next begins.

Uniform type at small sizes. Dense layouts need hierarchy. When everything is 12px regular, nothing reads first. Add weight contrast: label at 500 over value at 400, same size, and the same information becomes scannable.

No breathing room at structural edges. The density inside a section doesn't have to match the density between sections. Tight rows inside a table with 24–32px around it reads cleanly. Tight rows running edge-to-edge with no break reads as claustrophobic. Whitespace does its best work at transitions, not inside content.

The design system angle

If your product has dense surfaces, the system has to support them. Spacing values of 4px and 8px need to exist and actually get used. Components need compact variants that are maintained. Not bolted on once and quietly abandoned.

The failure I see most: a system built for marketing and growth surfaces, then applied to product surfaces it wasn't designed for. Generous default padding, no compact alternative. Designers on data-heavy screens manually override everything or build outside the system. The system becomes overhead instead of a tool.

Compact variants aren't edge case requests. If your product has information-heavy surfaces, they're part of the baseline.

Before you ship

Two questions worth asking before you finalize a dense layout.

Can the user complete the main task without unnecessary scrolling? If the data someone needs to correlate requires scrolling to see together, the layout isn't meeting its requirements. Density that forces scrolling is usually just less whitespace.

Can someone unfamiliar with the product identify the hierarchy quickly? Ask someone who doesn't know the surface what's most important on the screen. If they hesitate, the layout may be information-rich but not information-organized. That's a structure problem, not a density problem.

Greg Sargent
Greg SargentDirector of Design Systems, Spring Health

I write about design systems, accessibility, and the way AI is changing how we build software.

Published November 4, 2025

Be the first to rate this article.