Operator UX

An operator on a Tuesday afternoon: ten meetings underway across two campuses, fourteen alerts in the queue, three of them looking like the same incident, two of them probably not actually incidents at all.

She opens the "investigate device" view on the NetSpeek operator console.

She sees a device list. She filters by site and room. She clicks into a device. She reads four tabs in sequence — state, telemetry, history, vendor data — and manually correlates timestamps across them to figure out what actually happened. Two minutes and twenty-two seconds later, she has a hypothesis. She writes a ticket in a different tool. She moves to the next alert.

Average time-to-decision: 142 seconds. Six context switches per decision. She does this 30–50 times a day.

In our Q1 2026 operator survey, the three top complaints were:

1. Remembering timestamps across four tabs is hard during an active incident.
2. The "recommended action" card lives at the bottom of the page; most operators scroll past it.
3. Lena's confidence is shown as a number; operators want to know what she's not sure about.

That last one is the one we keep coming back to. A number doesn't help; operators want signal about uncertainty shape, not a scalar.

The platform's data is fine. The backend API surface is reasonably shaped (see below). The operator front-end is the layer that is failing the operator.

We want to see how you'd redesign the default view of this screen. Not a polished mockup — a sketch in prose. What's on screen first, what's progressively disclosed, where Lena's signal sits, and which API surface you'd change (the surgical change, not the rewrite). And tell us how you'd keep the default render fast even though one of the upstream APIs is slow.