Designing a Screen That Stays Open Eight Hours a Day

An admin panel is a completely different thing from a marketing page. A marketing page exists to persuade. A panel exists to get work done.

On a page opened once a month, three extra clicks bother nobody. On a task done two hundred times a day, the same excess becomes hours over a year, and eventually the team stops using the system.

The frequent task on the shortest path

This is the first question we ask when designing a panel. How many times a day is each task on this screen actually performed?

The answer usually surprises people. The large section in the middle of the screen gets used monthly, while the thing everybody does fifty times a day sits three menus deep.

Frequency should set the order, not logical grouping. Logical grouping is good for documentation and poor for daily work.

An empty screen explains nothing

In a newly installed system every list is empty. The user looks at the screen and does not know what to do.

The empty state is itself a design job. What this is, why it is empty and what the first step should be all belong there. That small detail decides whether the system survives its first week.

An error should say what to do next

When something fails, the user wants to know two things. What happened, and what should I do now.

A message saying something went wrong tells them neither. They either retry blindly or pick up the phone and call you.

Printing the technical detail on screen is not the answer either. A database error or a file path should never reach the user, because those describe the internals of your system to whoever is looking. The user gets the next step and the log gets the detail.

Every panel needs bulk actions

A task done one at a time becomes unbearable at fifty records.

Selecting and changing status in bulk, exporting in bulk, deleting in bulk. Without those three the user either avoids the work or asks for direct database access. The second is far more dangerous.

Bulk delete needs an undo, or at minimum an explicit confirmation. A button that removes fifty records in one click eventually gets clicked by mistake.

Permissions from the start

A panel where everyone sees everything causes problems as soon as the team grows.

The person in the warehouse does not need to see revenue. An intern does not need to export the customer list. Adding that afterwards means reviewing every screen one by one.

And one distinction matters. Being signed in is not a role. Every screen should have its allowed roles written next to it, and where nothing is written the default should be no.

Search and filters

As records accumulate the list screen becomes unusable. Scanning a thousand rows by eye is not a thing people can do.

Remembering the filter matters too. If the user has to rebuild the same filter on every page load, they stop using filters altogether.

Pagination is the skipped subject

A list screen tested against small data freezes in production against ten thousand records.

List endpoints need an upper bound. An unbounded endpoint both locks the page and lets a single request exhaust server memory. Learning that in production is expensive.

It gets opened on a phone

Panels are assumed to be desktop software, but in practice the manager checks in from a phone.

Clipped tables, tabs that cannot be reached and touch targets that are too small are the three problems we meet most. Measuring them is not hard, you open it on a narrow screen and look. On panels shipped without that check, all three usually appear at once.

The panel address is not security

An unguessable address makes an attacker work harder and that is worth having. But it is not access control on its own.

Even behind a hidden address, every endpoint still has to check permissions. The sign-in screen needs to sit behind the same door too, otherwise the hidden address means nothing.