DECT Devices: Display Base Station Reports in Control Hub

When a base station starts misbehaving, an admin needs to know why: is the signal weak, is the battery failing, has it lost its connection to the network? All of that information already lived on the device. The catch was getting to it in a form anyone could actually use.

Technically, every DECT base station generated a file called status.xml. It carried everything needed to diagnose a fault, signal strength, battery levels, reboot history, registration state, but reading it was the problem.

To get a status report, an admin had to request one, wait for it to generate, download it, then read raw XML. No formatting, no structure, no way to view two base stations side by side. For a single base station, it was slow. For a deployment running dozens of stations, it was not a serviceability workflow. It was a last resort.

The ask from the field was clear: take data that already existed and make it legible, comparable, and accessible without leaving Control Hub.

The infrastructure did not need building. status.xml was already there, already being generated, already carrying the right signals. What it needed was a surface: a way to request it on demand, read it in a structured format, browse historical snapshots, and navigate across multiple stations without losing context.

This reframed the engineering conversation early. Not a new data pipeline, but a new view onto existing data. That distinction made the project tractable within the timeline and focused the design work on the right problem: structure and legibility, not infrastructure.

The design brief was focused on four admin capabilities, each representing a gap in the current experience that the new reports view needed to close.

The work started from a real customer signal: an escalation from the Orange account, surfaced through our TAM and customer success channel. Rather than treat it as a one-off ticket, I traced it back to the underlying serviceability gap, synthesising how admins actually manage DECT deployments, mapping the friction points, and translating the technical capability of status.xml into a flow that felt native to Control Hub. I kept checking each decision against that admin workflow rather than against the brief as written.

The starting point was straightforward: give admins a way to generate a status report on demand. As the design work progressed and the admin workflow became clearer, I identified two gaps that the brief had not addressed.

Neither was in the original brief. Both became baseline requirements as understanding of the actual admin workflow expanded. Expanding from generate-only to three use cases meant making the case that the timeline was still achievable when the pressure was to ship the minimum and move on.

Broader scope meant a longer timeline and a harder conversation with engineering. It also meant shipping without a pre-launch baseline. There was no established metric for how often site visits happened before this feature existed, so impact will be observable when the feature goes live, but not precisely quantifiable against a known starting point. That is the cost of moving when the historical data was never captured.

The obvious path was the minimum viable one: build a generate-on-demand flow. One button, one report. Fast to ship, low engineering lift, directly addresses the account escalation. I argued for a broader scope and had to make the case for it.

I anchored the argument in how admins actually diagnose DECT faults, not in what was easiest to build. Intermittent issues, a handset dropping signal sporadically or a base station degrading over days, are never diagnosed from a single snapshot. They require comparison across time and visibility across stations. A generate-only feature would have shipped faster and quietly failed the people it was meant to serve, so I made that case to the PM and engineering directly and carried it through mid-process triad reviews until the broader scope was committed.

Three use cases drove the design, each reflecting a distinct scenario an admin would encounter.

The four decisions below were not made in isolation. The SIP NOTIFY mechanism used to trigger status.xml retrieval came with constraints that shaped the UX directly. The polling interval, file retention limit, and rate-limit behaviour were drawn from a previous API used for similar collection tasks, reused deliberately because the behaviour was known and proven.

I drove the case for UC2 and UC3 against a brief that originally scoped only generate. I made the call to reuse the prior API’s rate-limit and retention behaviour rather than spec new limits, because proven behaviour was worth more than ideal behaviour on this timeline. Working with the engineering triad through mid-process reviews meant I designed around these constraints early, not patched after testing. The state machine for button behaviour (idle, generating, success, failure, cooldown) was built to match the actual protocol behaviour.

Final designs cover the complete journey, from how admins discover the reports view, through all three use cases and every edge state including failure, rate limiting, and multi-station search.

The AI vision is a proposal in progress. After the production-ready designs were signed off, PM and I started asking the same question independently: given that structured, historical, per-station data was now accessible from Control Hub for the first time, what could the layer above it do?

The Figma Make prototype was built to answer that question with something concrete rather than a slide: a working demonstration of the intelligence layer we are preparing to take to the engineering triad. The goal is not to speculate about future features. It is to show, rather than describe, what the same data could do if the system were designed to reason over it rather than just display it.

From "I can see the data" to "I know what to do with it". Built leveraging Figma Make for rapid prototyping, each of the six capabilities below is grounded in a specific friction point the current feature does not yet address.

Six AI-driven capabilities sit at the heart of this vision, each addressing a friction point admins surface today, from interpreting raw signal data to noticing problems before users do.

Of the six, natural-language debugging is the one I’d build first: it collapses the technical-depth barrier that gates everything else, and the foundation already supports it. Service-health scoring is the most speculative; I would want validation with real deployment owners before committing to it. Showing which capabilities to cut or defer is the point; equal confidence across all six would not be judgment.

Below, a high-fidelity prototype built in Figma Make, putting the six capabilities into a single admin surface.