Half two of two
Interface
The same person who designed the engine designed the screen. Most backend engineers cannot do this half, and most frontend engineers cannot do the other. That combination is the whole argument.
Software used all day by someone with a queue in front of them obeys different rules from software used once a week. Whitespace is not always kindness, and a beautiful empty state is worth less than a fast filled one.
Who these screens are for
Somebody at a counter with a queue of parents in front of them, doing the same task for the ninetieth time today. They are not exploring the product. They know exactly what they want to do and the interface is the only thing standing between them and doing it. Every rule on these pages follows from that one fact.
It leads to conclusions that read as wrong if you design consumer software. Density is kindness rather than clutter, because scrolling costs more than reading. The tenth repetition matters more than the first impression. A confirmation dialog on a routine action is not safety, it is a tax paid ninety times a day that trains people to click through without reading.
Why a backend engineer writes this section
Because the split between the two halves is where most of the damage happens. An engine that returns the right answer in a shape the screen cannot use, or a screen that cannot distinguish between nothing exists, nothing matched your filter, and the request failed, will produce a wrong decision by a real person regardless of how correct the backend was.
The three states every demo skips are the clearest example. Loading, empty and error are the states the data is in most of the time under real conditions, and they are the ones built last, if at all.
Designing dense screens for people who use them all day
Consumer design teaches you to remove. Operational design teaches you that removing something a clerk needs ten times an hour is not simplification, it is a second click on every transaction, forever.
Tables people actually use, and the four rules behind them
A table is the most used component in any operational product and the one most likely to exist three different ways in the same codebase, each with its own search box behaving differently.
Forms that do not lose work, and errors people can act on
The worst thing a form can do is not rejecting bad input. It is accepting twenty minutes of careful work, failing somewhere invisible, and leaving somebody with an empty screen and no idea what to retype.
Loading, empty and error, the three states every demo skips
Every screen has four states and a demo only ever shows one of them. The other three are where trust is won or lost, and they are almost always the last thing anybody builds.
Where to start
- The argument itself
- Why the tenth repetition beats the first use, and where the density argument stops being true.
- The most commonly skipped
- Three states, three different messages. Showing "no results" when the request actually failed is a lie the user will act on.
- If people type a lot into your product
- Losing twenty minutes of entry to a dropped connection is a data loss bug, not a UX complaint.
Common questions
- Is this design work or frontend engineering?
- Both, and separating them is what produces the failure. The decision about what belongs in one viewport is a design decision that only somebody who knows what the query costs can make correctly. I do the two together because on every system here there was nobody to hand either half to.
- Does any of this apply to consumer products?
- Partly. The three states and the forms rules apply everywhere. The density argument does not: it is a trade specifically for people who repeat a task, and applying it to software somebody uses twice a year would make that software worse.
The other half is what happens behind the screen. Engine design .