A network health dashboard for multi-site operations

One dashboard for hundreds of networks

My role

Senior UX Designer

Employer
World Wide Technology
Team
Asynchrony Labs, WWT's software engineering arm
Where
St. Louis
When
2018
  1. Took over product design for the dashboard, from the workflows and prototypes to writing tests and seeing it built.
  2. Designed the map that leads the product: every network a dot, colored by a utilization-based status model with explicit thresholds.
  3. Designed the provisioner, which turned setting up a new network into four staged steps, and the captive portal editor for guest Wi-Fi.
  4. Reviewed the November 2018 build, each red annotation a question for the next iteration.
  • 483 networks on one map in the test build, from two vendors' platforms under one health model
  • 5 states in the status model: healthy below 75% utilization, watch, warning, critical above 94%, and unconfigured
  • 4 steps to stand up a new network: its details, its devices by scanned serial, the manual steps, then live
  • 3 or 4 enterprise customers used it after it shipped; it never grew past them

Summary

Multi-site organizations run their branches on whichever network vendor each site happened to get, and every vendor ships its own dashboard with its own idea of health. An operations team watching hundreds of locations had no single answer to the only question that matters at a glance: which sites need attention right now? The product had to reduce two vendors' telemetry to one legible status model, and make adding the next site a checklist rather than a project.

I took over product design for a dashboard that answered that question for a whole fleet. It put every managed network on one map, reduced two vendors' telemetry to one status model, gave each location its own depth of detail, and made adding the next site a checklist. It shipped, and three or four enterprise customers used it, though it never grew past them. What survives is the design-review record of the November 2018 test build: annotated captures, each red note a question for the next iteration.

Who was involved

  • Asynchrony Labs WWT's software engineering arm, whose engineers built the product.
  • The client A provider of managed networks for multi-site organizations, named only by industry here.
  • Me Product design: the workflows, the map and status model, the provisioner, the captive portal editor, and the design reviews.
The network map of the central United States: 483 networks as status dots, mostly healthy green, with toggles for healthy, watch, warning, critical, and unconfigured states, and a legend mapping each status to a utilization band. A red review annotation asks whether the legend could be always visible.
The network map, November 2018. 483 test networks on one map, colored by the status model. The red note is from the design review.
Read the record . 7 sections, about 2 min

Where it started

The product was built at Asynchrony Labs, WWT's software engineering arm, for a provider of managed networks to multi-site organizations. In 2018 I took over its product design, from workflow planning and prototyping through test-writing and implementation. The job was to reduce two vendors' telemetry to one legible status model, and to make adding the next site a checklist rather than a project.

One map, one status model

The dashboard leads with a map: every network a dot, colored by a utilization-based status model with explicit thresholds. Healthy is below 75 percent, watch runs to 84, warning to 94, critical is above, and unconfigured is a state of its own rather than a gray guess. Each state can be toggled on the map, so an operator can hide the healthy majority and see only what needs attention.

The review's first question is on the map itself: could the legend be always visible? An operator should not have to open a panel to learn what a color means.

Each location in its own depth

Locations carry the per-site detail: circuit utilization, uplink status, and bandwidth history in the site's own time zone, so a spike at a branch reads at that branch's hour. The locations list shows which vendor's platform manages each site. The review note on the location page asks whether actionable statuses belong on the list itself, one level up, where an operator scans first.

Location detail for a test site: circuit utilization tiles flagged unconfigured, an uplink status table, and a download bandwidth chart in the site's time zone. A red review annotation notes that actionable statuses should surface on the list of all locations.
A location in detail. Circuit utilization, uplink status and bandwidth in the site's time zone. Test data.
All Locations table listing test networks by name, with a column per vendor platform, showing which system manages each site.
Every location, and who runs it. One row per network, a column per vendor platform. Test data.

Setting up a network as a checklist

The provisioner turned network setup into a staged flow: the network's details, its devices added by scanned serial number, the steps that still had to be done by hand, then push it live. It bound the vendor's templates behind the scenes and logged each step, so adding the next site was a checklist rather than a project. The review asked where the main navigation had gone inside the flow.

The provisioner's Create Network flow at the Add Devices step: fields to add a device by scanned serial number and name, grouped counts for security devices, switches, and access points, and a log confirming a network bound to a template. A red review annotation asks where the navigation went.
Create Network, at the device step. Devices added by scanned serial, grouped by type, with a log of each step. Test data.

Guest Wi-Fi without a console

A captive portal editor let staff who are not network engineers manage the guest Wi-Fi splash page and its terms: templates, button text and colors, with a preview as a device would show it. It kept the people who write the terms out of the network console.

Captive Portal Editor with tabs for templates and terms and conditions, editing a default template's button text and colors, with a View as Device preview action.
The captive portal editor. Templates and terms for the guest Wi-Fi page, with a device preview.

Outcomes

What survives in my archive is the design-review record: eighteen captures of the November 2018 test build, dated November 19 and 20, with red notes on them. Could the map legend be always visible; where did the navigation go in the provisioner; do actionable statuses belong on the locations list; does Admin need to be a main navigation tab. I kept the annotations in the captures because they show the review doing its job.

The product shipped, and three or four enterprise customers used it, but it never grew past them. No adoption or performance figures are in my files, and the screens show test data.

Admin screen for a test tenant's users, empty but for an Add User action. A red review annotation asks whether Admin needs to be a tab in the main navigation.
Admin, with a question on it. Does Admin need to be a tab in the main navigation? A review note, posed as a question for the next iteration.

If I did it again

I would put the review's questions somewhere they could be answered in writing. The red notes are good questions, and the captures are the only place they survive; what the team decided about each one went into a conversation and stayed there.