Screens for people with a queue standing in front of them

The situation

The people using this software are not enthusiasts. They are staff doing a repetitive job with somebody physically waiting for them, often on a modest laptop, sometimes on a connection that comes and goes.

The first version of these screens was built the way most internal software is built: a form per entity, a table per list, a modal for anything complicated. It worked, in the sense that every task was possible.

Then I sat and watched somebody use it for an hour, which I should have done a year earlier.

What watching changed

The single most common task took six interactions and two page loads. Not because anything was slow, but because the information needed to make the decision lived on one screen and the control to act on it lived on another.

They had adapted. Two browser tabs, one on each screen, switching between them. That is a workaround so smooth that it never generates a complaint, which is precisely why it never got fixed.

What people reported instead was that the system was slow. It was not slow. Requests were quick. The workflow was long, and long feels like slow to somebody with a queue.

Users report symptoms, not causes, and they report them in the vocabulary of speed.

What I tried first

I made it prettier. More whitespace, larger touch targets, cleaner typography, a calmer palette. It looked considerably better and it tested worse, because the extra breathing room pushed content below the fold and added a scroll to a task performed sixty times a day.

That was the correction that reframed everything: consumer instincts are wrong here. Removing things and adding space is right for a screen somebody visits once a month and wrong for one they live in. The trade is not beauty against function, it is first impression against the tenth repetition, and in operational software the tenth repetition wins every time.

The decisions that followed

Everything one task needs goes in one viewport, even when that means a denser layout than I would choose aesthetically.

Numbers get tabular figures and right alignment, because staff scan a column for the odd one out using the shape of the digits, and proportional figures destroy that shape.

Row actions live on the row. Up to two are visible, three or more collapse into a compact menu.

Tables keep the previous page rendered while the next loads, so the position is never lost and pagination feels instant.

Every table owns its own empty state, because only the table knows whether nothing exists, a filter excluded everything, or a request failed. Those three need different answers and generic messages get two of the three wrong.

The one place I deliberately went the other way is destructive and irreversible actions. Those get generous spacing, an unambiguous label, and a real pause. Density is for the routine.

Where it landed

The common task went from six interactions to two, and from two page loads to none. The second browser tab disappeared, which I take as the truest measure, because nobody was ever asked to stop using it.

Reports that the system was slow stopped, without any change to response times.

What I would do differently

Watch first. An hour of observation before writing anything would have produced most of these conclusions and saved a redesign that made things worse before it made them better.

And I would stop treating operational interface work as a lesser craft than product design. It has its own rules, most of the widely repeated advice is written for a different context, and getting it right is worth more per hour to the people using it than almost anything else I build.