Skip to content

Writing

Dense screens are a different craft

I redesigned a screen used all day by staff with a queue in front of them. It looked considerably better and it made their job slower, which took me a while to accept.

What I did

An internal screen, used constantly, looked like most internal software. Tight rows, small text, controls wherever they had accreted over two years.

I redesigned it with everything I knew about good interface design. More whitespace, a larger type scale, generous touch targets, a calmer hierarchy, controls grouped sensibly.

It was unambiguously better looking. I was pleased with it, and I still think it was the prettier screen.

What happened

The most frequent task got slower.

The extra breathing room had pushed part of the form below the fold. The number somebody needed to read and the control they needed to act on were no longer visible at the same time. So the task acquired a scroll, and worse, it required holding a figure in their head while scrolling to act on it.

Sixty times a day. Per person.

Nobody said the redesign was bad. What I heard was that the system felt slower, which is what people say about everything, and which I nearly dismissed because I had not changed anything that could affect response time.

The thing I had wrong

Almost every piece of interface advice I had absorbed was written for software people visit occasionally.

For a page somebody sees once a month, removing things and adding space is correct. Discoverability matters, cognitive load on first encounter matters, and a calm screen is genuinely easier to understand.

For a screen somebody lives in eight hours a day, those priorities invert. They learned the screen in week one. Discoverability stopped mattering in week two. What matters from week three onwards, forever, is the number of actions and whether everything needed is visible at once.

Optimise for the tenth repetition, not the first impression. When those conflict, and they regularly do, the tenth wins.

Why the mistake is so easy to make

Because the first impression is the only thing that gets evaluated.

A design review is a first impression. A screenshot is a first impression. A demo is a first impression. Nobody in the room has used the screen sixty times, so the density that would serve the actual user reads as clutter to everybody deciding.

The person who would tell you is not in the room, and when they do tell you, it arrives as “it feels slow”, which routes to the wrong team.

What I changed back, and what I kept

I did not revert. Some of the redesign was genuinely better and worth keeping: the hierarchy, the grouping, consistent alignment, states that were previously ambiguous.

What went back was the density. Tighter line height, less padding, and the whole task in one viewport again. The screen ended up denser than my redesign and better organised than the original.

Three specific things I now do without hesitating:

Everything one task needs stays in one viewport. If that requires a tighter layout than I would choose aesthetically, the layout loses.

Numbers get tabular figures and right alignment. Staff scan a column for the odd value using the shape of the digits, and proportional figures destroy that shape entirely.

Row actions live on the row. Up to two visible, three or more collapse. Moving a frequent action into a menu to calm a screenshot is a cost paid by somebody else, every day.

Where density stops

There is a limit and it is worth being precise about, because “dense is good” taken too far is its own failure.

Density stops paying the moment it costs accuracy. If a tighter grid produces mis clicks, or a shortened label produces the wrong action on something irreversible, you have traded seconds for mistakes. In operational software a mistake usually means somebody has to be telephoned and apologised to, which costs far more than the seconds saved.

So: dense for the routine, deliberately spacious for the irreversible. The one screen that should have generous spacing, an unambiguous label and a real pause is the one that cannot be undone.

The habit that would have prevented all of it

Watch somebody work for an hour before designing anything.

I did it afterwards, and it produced more insight than the entire redesign had. The second browser tab they had been using to keep two screens visible at once. The way they read down a column rather than across a row. The fact that they never used the filter I had spent a day on.

None of that appears in a requirement, and none of it appears in a complaint. It is only visible by watching, and an hour of it is the cheapest research available in software.

Published April 2026, updated July 2026.

Hiring someone to own work like this?

I am open to senior backend and full stack roles, remote and permanent.

Get in touch / Read the CV