There is a special class of software that has to work while strangers are staring at it.
Lobby boards. Shop-floor status. Queue displays. Event screens. The TV above the ops desk that the whole team glances at between calls. If it dies, everyone notices at once, including people who do not care about your stack and should not have to.
There is built enough of these to have opinions. Most admin dashboards can fail politely. Ops displays fail in public.
Design for ten feet away, not for your laptop
Tiny tables with forty columns are fine in a CRM. They are useless on a wall.
Big numbers. Short labels. High contrast. The one status that matters should be readable from across the room. If someone has to walk up to the TV and squint, you built a report, not a display.
Pick fewer metrics. It is better to show four true things than twelve decorative ones.
Assume the network will get weird
Displays live on flaky guest Wi-Fi, shared players, and machines nobody patches until they cry.
So:
- cache the last good payload and show it with a “as of” timestamp
- retry with backoff
- degrade to a simple static fallback instead of an infinite spinner
- avoid architectures that need a human to refresh the browser every morning
If the board says nothing, people invent stories. A slightly stale number with a timestamp is more honest than a blank screen of shame.
Latency budgets are product requirements
A display that updates every five minutes might be fine for daily totals. It is not fine for “now serving” or live queue depth.
Be explicit. What freshness does the job need? Build to that. Do not use the same polling interval for everything because it was the default in the tutorial.
Write mode and panic mode
Happy path: calm layout, normal colors, boring reliability.
Panic path: outage, SLA breach, rooms full, calls abandoned above threshold. The display should change posture. Color. Size. Maybe sound if the environment allows it and you will not create chaos.
Test the panic path. Nobody should discover the red full-screen state for the first time during a real incident with visitors in the lobby.
Content rules matter more than animation
Animations look cool in demos and get annoying by week two. Prefer clear state changes over theater.
Also ban accidental internal jargon on public screens. If the display faces patients, families, or customers, the language should be human. Internal codes belong on internal boards.
Ops ownership
Someone has to own:
- what the numbers mean
- when the feed is wrong
- how to reboot the player
- who gets paged if the board is dark during business hours
Software without an owner becomes art installation.
Prefer a tiny health endpoint and a weekly glance in the same review where we check other always-on systems. Displays are production.
Build boring on purpose
My favorites are dull tech: a simple web page, kiosk mode, local cache, signed URLs if needed, minimal moving parts. Cleverness is how you get a unique failure at 5pm on a Friday.
AI can help generate layout variants or summarize incidents for an internal board. you would not put an LLM in the render path for a public lobby number unless I enjoy non-deterministic fonts of risk.
Rehearse the ugly day
Unplug the network. Kill the API. Expire the token. Watch what the screen does. If the answer is a white void, you are not done.
Write a one-page runbook and tape the reboot steps near the player. Public displays fail at the worst time. Prep is cheaper than improvising in front of an audience.
Bottom line
Ops displays are public contracts. They need distance-readable design, honest stale states, clear freshness rules, and an owner.
If it has to work in public, build it like it will fail in public. Then make the failure boring and recoverable.
Pretty is optional. Readable and up is not.
