DECT Devices: Display Base Station Reports in Control Hub
Before this project, diagnosing a DECT fault meant booking a site visit. For enterprise deployments managing dozens of base stations across multiple locations, that simply did not scale. I led the design of a remote status reporting tool inside Cisco Control Hub, giving IT admins full fleet visibility and the ability to identify and fix problems without ever leaving their desk.
Large service providers like Orange were scaling Webex Calling deployments into Webex MT at pace and they needed remote serviceability tools to match. Without visibility into DECT health, every support ticket risked becoming an expensive on-site dispatch.
DECT (Digital Enhanced Cordless Telecommunications) is the wireless standard behind enterprise cordless phones, found in offices, hospitals, warehouses, and large sites.
Cisco's DBS-210 is a multi-cell base station that handsets connect to over the DECT 1.9 GHz radio standard. Mount one on a wall, connect it to your network, and up to 30 handsets can register to it. Network multiple stations together and you get seamless, site-wide coverage.
Admins manage everything through Webex Control Hub, Cisco's centralised IT platform for devices, users, and calling services.
DECT base stations are deployed on-site in enterprise environments. The only way for admins to access network diagnostics was to physically log into each base station, not scalable for large service providers. PRT files held the data but extraction was slow and the output unreadable. The status.xml file had exactly what admins needed. It just had no way to surface itself.
status.xml already existed, embedded inside every PRT file, quietly carrying exactly the signals admins needed. The opportunity was not to build something new from scratch, but to make what was already there visible, on demand, readable, and actionable from inside Control Hub.
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 design process was grounded in understanding the existing serviceability gaps, synthesising user feedback from admins managing DECT deployments at scale, mapping the obvious friction points, and translating the technical capability of status.xml into a flow that felt natural within Control Hub's existing patterns.
From there, I moved into screen design and prototyping, iterating on the report generation flow, tab handling, and status states until the experience felt complete and production-ready.
Three use cases drove the design, each reflecting a distinct scenario an admin would encounter.
Each decision was shaped by a specific edge case or admin expectation, particularly around status feedback, state persistence, and recovery from failure. The goal was to avoid cognitive overload and accidental context-switching.
Button greys out immediately on trigger. Stays disabled for the 200 OK cooldown duration or 429 Retry-After period. Banner switches to failure if timeout is reached.
Each tab independently remembers its last selected report. New reports arriving do not override the current view, only the dropdown list refreshes silently.
Polls csdm API every 20s after request, only for the active tab. New report auto-surfaces when nothing is displayed; otherwise the view is uninterrupted.
Overflow arrow appears at 5+ stations. MAC/name search surfaces immediately. All per-station state, report, timestamp, progress, is maintained independently.
Architectural wireframes grounding the key screens, empty state, generating in progress, full report view, and handsets. Used to validate layout and information hierarchy before moving into high-fidelity design.
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.
Admins reach the reports view from two places, the individual device page and the DECT Network base stations list, both surfacing a "Base station status reports" link in the Support section.
The idle empty state prompts the admin to generate their first report. Once triggered, the generating state appears with a disabled button. When a report already exists, an informational banner overlays it during collection.
The full report surfaces base station values, RSSI signal bars, reboot log, SIP and metrics in collapsible accordions. Admins browse historical reports via a timestamped dropdown, and drill into individual handsets for battery and signal detail.
"Find base" opens a search dropdown allowing admins to locate any station by MAC address or name. The inter base station view shows adjacent station signal data from the perspective of the selected base.
Three distinct error states, a red banner with failure toast when generation fails, an empty "hit a snag" state, and a "request sent too soon" rate-limit screen when the admin triggers within the cooldown window.
Production-ready designs covering the complete admin journey, entry points, report generation, exploration of base station and handset data, and edge states.
From "I can see the data" to "I know what to do with it". This section focuses on an AI-based future, built leveraging Figma Make for rapid prototyping.
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.
Below, a high-fidelity prototype built in Figma Make, putting the six capabilities into a single admin surface. It tests the vision against real workflows: spotting issues at a glance, drilling into reports through three lenses, and querying the data in plain English.
