A demo audience wants to see that the system knows things. A shift operator wants to be told which three of four thousand devices need attention in the next hour. Those two goals produce almost opposite interfaces, and most consoles are built for the first one.
The symptoms
- Every metric is on the front screen, because each one was impressive to someone during the build.
- Everything updates live, so the table repaints while an operator is trying to read a row.
- The default sort is alphabetical or by identifier, which is never the order anything needs attention in.
- Alarms are a flat list rather than incidents with state, so the same fault appears forty times.
Sort by what to do next
The most valuable change we make to an inherited console is usually the default sort order. On a cold-chain build we replaced alphabetical with time-to-breach; nothing else about the screen changed, and the median time to intervention halved. The information was always there. It was in the wrong order.
If an operator has to scan the whole list to find the urgent thing, the interface has delegated its job to the human.
Live only where live matters
A fleet table does not need a websocket. Polling every ten seconds is fine, and it stops the list moving under the cursor. A single device view during an active incident does need to stream, because the operator is watching for a change right now. Applying the same update strategy to both is how consoles become unusable at scale.
Watch a full shift before you design anything
We sit with an operator for an entire shift before building the console, and again after the pilot. It is the least efficient-looking eight hours in the project and it consistently produces more design decisions than any workshop. You find out what they have written on a sticky note on the monitor, and that sticky note is your specification.