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
- Took over product design for the dashboard, from the workflows and prototypes to writing tests and seeing it built.
- Designed the map that leads the product: every network a dot, colored by a utilization-based status model with explicit thresholds.
- Designed the provisioner, which turned setting up a new network into four staged steps, and the captive portal editor for guest Wi-Fi.
- 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.
Read the record .
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.
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.
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.
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.
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.





