The Challenge
The report showed network interruptions, outages and trends as static screenshots. You could look at the data. You could not do anything with it.
WAN Availability Report
Google's internal WAN Availability Report was a stack of screenshots. I rebuilt it as a dashboard you can filter, sort and drill into, using Google's own PLX library
Role
UX Researcher
& Designer
Duration
3 Months
Company
Google
1
Screen for the whole report
5
Report categories on it
+16
Features the old one lacked
14%
Of the space it used to take
10s
Live data refresh
I signed an NDA with Google, so there is not much I can show. The numbers in this image are fake.
Redesigning how Google processes network availability data
The Users
Executives and network engineers in several departments. They read this report to decide where to invest and to know how bad an outage is while it is happening.
The Solution
One dashboard, built in Google's PLX library, that holds the five report categories on a single screen. It added 16 features the old report never had: filters, drill-down, sharing, and picking the exact slice of data you need.
The Problem
To answer one question about network availability, an engineer had to walk through a sequence of screenshots and read the numbers off the images. No filtering, no drilling down, no comparing two points. People rebuilt the data by hand in spreadsheets, and a routine check ate a chunk of the morning.
No way to filter or specify needed data
Static screenshots with no interactivity
Time-consuming manual data processing
Unable to drill down into specific metrics
No sharing or export capabilities
Fragmented view across multiple pages
Learning how Google's network works
I had never worked on network infrastructure before, so I spent the first phase reading, asking and learning PLX, the library that would end up deciding what I was allowed to design.
4
Research Areas
12+
Interviews
5
Report Categories
3
Data Sources
Area 01
Google Network Functioning
I learned how Google's internal WAN works, so I could see everything the report had to cover.
Network architecture, availability metrics, bad minutes, and which team reads which number.
Area 02
Existing Report Analysis
I mapped the route people walked through the old report, and where they got stuck.
I audited the 5 report categories and how each one shows its data, then marked every spot where screenshots let people down.
Area 03
Mastering PLX Library
I learned PLX, the internal library the developers would build this with. This part took the longest.
Knowing what PLX can and cannot do told me which features were real and which ones I had to drop. It has no responsive support, for example.
Area 04
User Feedback Collection
I ran the research across departments, because each one wanted a different thing from the same report.
I interviewed executives and engineers until the list of requirements stopped growing.
Research Process
01
Context Gathering
I sat with developers and engineers to learn how the WAN works and where the report lands in their week.
02
Pain-Point Mapping
I walked the whole journey through the static report and wrote down every friction point and every workaround people had invented.
03
PLX Capability Assessment
I ran simulations with test data in PLX to see what it could draw, what it could filter, and where it broke.
04
Multi-Department Interviews
I interviewed people from the other departments too. Each one uses this report for something different, and I did not want to miss a requirement.
Sorting complaints into features I could build
Approach
The users were too different from each other to treat the feedback as one pile, so I sorted it into the report's five categories. I wrote down every point people raised, including the ones I could not build because PLX would not do it or because the team had decided otherwise.
Patterns that repeat across user groups
Features ranked by how often people asked and how much it hurt
Alignment with existing report categories
Documentation of PLX limitations and workarounds
Data Sources
01
Previous Surveys
Feedback and complaints collected on earlier versions of the report
02
User Reports
How teams were reading the static report, and the workarounds they built for themselves
03
New Interviews
My own interviews with executives and engineers from several departments
Key User Requirements
Real-time Updates
Bad minutes get logged every 10 seconds, so the data never sits still
Alerts for bad-minutes with prioritization and time-range evolution
Flexible Time Windows
Drop the 28-day limit and let people pick a wider window
Quarterly and weekly trend comparison views
Wider Views
A network agnostic view, to analyse without picking a network first
General pair availability (independent from B2/B4)
Individual event duration tracking for bad minutes
Interactive Drill-down
Drill down to specific region-pairs, B2 sector/B4 neighborhood, metroshard and topology domains vs. aggregate level
The Manual
I wrote a manual explaining how to reach every point people had asked for, and why the rest could not happen, either because PLX would not do it or because the team had decided otherwise. The developers built from that document, so nothing got lost on the way from research to code.
Designing within PLX's boundaries
I designed the interface while I was still learning PLX, so every feature got checked against what the library could draw before it went in.
5
Main Categories
1
Unified Screen
16
New Features
14%
Space Used
Principle 01
New Data Visualization Architecture
The screenshots are gone. Network data now lives in a structure you can open, explore and reshape, in a fraction of the space.
Principle 02
Consolidated Single Screen
The five categories and their subcategories share one screen. You no longer page through static content hunting for one number.
Principle 03
16 New Features
16 features the old report never had. You can filter, drill down, share a view, and ask for the exact slice of data you came for.
Principle 04
PLX-Driven Design
I checked every decision against PLX before committing to it. Its limits, no responsive support among them, drew the edges of what this could become.
Iterative Process
01
First Iterations
First mockups, built from the requirements and already boxed in by what PLX allows
02
PLX Validation
I tested each element in PLX to see if it could exist at all
03
Capability Testing
Test charts, to check how the data rendered, filtered and responded to a click
04
Refinement
I reworked the designs with what the tests taught me and what the team asked for
PLX Constraints
PLX does not do responsive design. The dashboard had to live in a fixed desktop viewport, and that single limit decided most of the layout and every interaction on it.
Learning PLX took a big slice of the project. Once I knew where its walls were, I could push it to the edge and still warn the team early about what the final product would never do.
From screenshots to a dashboard people can dig into
1
Screen for the whole report
5
Report categories on it
+16
Features the old one lacked
14%
Of the space it used to take
10s
Live data refresh
Static screenshots of network data
No interactivity or filtering
28-day time restriction
Fragmented across multiple pages
Manual data processing required
No sharing or export options
Same data, 14% of the space it used to take, plus 16 things you can now do with it
Interactive PLX-powered dashboard
16 new filter and drill-down features
Flexible time windows
Unified single-screen view
Real-time data every 10 seconds
Share and specify exact data needed
16 New Features
Filter by network, region-pair, and time range
Drill down from aggregate to topology domain level
Share specific views and data snapshots
Specify exact data parameters needed
B2 sector and B4 neighborhood breakdowns
Network-agnostic availability views
Individual event duration tracking
Bad minute alerts with prioritization
Flexible time windows beyond 28-day limit
Real-time data updates every 10 seconds
General pair availability independent from B2/B4
Metroshard-level granularity
Quarterly and weekly trend comparisons
Custom date range selection
Time-range evolution visualization
Consolidated five-category single-screen view
What changed
The old report let you look at the data and never touch it. No filters, no drill-down, no comparing two points. If you needed more, you rebuilt it by hand in a spreadsheet. The redesign folds the five categories into one screen you can question, and it stays inside what PLX can deliver. Same data, finally usable.
Impact
Five report categories on one screen, in 14% of the space the old report needed. The 16 new features are what got it there: filter, drill down, share, and ask for the exact data you came for.
