A network health dashboard for multi-site operations

The product was built at Asynchrony Labs, WWT's software engineering arm, for a provider of managed networks to multi-site organizations. When I took over its product design in 2018, the designer before me had spent the research time re-documenting Material Design and defining constraints, before there was a design concept anyone could get excited about. Field research had stalled, because there was nothing new for people to react to.

The product owners were trying to fix real problems with concepts of their own, and the build had grown out of simple requests to move parts of the UI around. The job was still to reduce two vendors' telemetry to one legible status model, and to make adding the next site a checklist rather than a project. What it needed first was something people wanted to talk about.

I recreated the UI as a prototype. I knew what Material's component catalog could do, and I held the prototype to a restyling of it. The restyling was deliberate: it made it obvious the product was experimental, and it gave the people who would use it something to get excited about.

That is a tactic experienced field researchers use, and I wanted their feedback. I also wanted them to see that we were not limited by Material Design. Across the design organization, that limit was taken for granted.

The build I inherited already led 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 first question in my review of the inherited build was 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.

In the build I inherited, 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. My review note on the location page asks whether actionable statuses belong on the list itself, one level up, where an operator scans first.

In the build I inherited, 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. My review asked where the main navigation had gone inside the flow.

The build I inherited had a captive portal editor that 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.

What survives in my archive is both halves of the takeover. The first is my review of the build I inherited: eighteen captures from November 19 and 20, 2018, 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. The second is the prototype in Sketch: 66 artboards, from Network Health in five views to each location in depth, the provisioner, the captive portal and visitor intelligence.

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

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.