A network portal for an enterprise networking company
Redesigning the portal big companies use to run their office networks, and testing every change as a hypothesis with a number attached
My role
Lead product designer
- Employer
- World Wide Technology
- Client
- An enterprise networking company
- Years
- 2022 to 2024
- Team
- Three product designers
- Led three product designers on an enterprise networking company's network portal.
- Changed how the team decided things: a problem statement worked back from what customers were promised, a hypothesis with its number written down first, and a shared field guide for testing.
- Led the design of the warnings timeline, the reusable setup templates and the many-devices tables, each checked against tracking in the live product.
- 8→4 weeks to bring a new customer's network on, with reusable setup templates
- +55% task completion after common tasks came out of menus four clicks deep
- 20→1 about that many warnings per site became one timeline instead of a pile
- 8 s average time to understand the timeline in testing, against a 30-second failure line
Summary
An enterprise networking company sells networking to large businesses, and their network engineers use its portal to watch over tens of thousands of pieces of hardware. The portal already existed, and it did not work: setting up a network took eight weeks, and when something broke the screen filled with thousands of warnings and no clue which one mattered. The engineers stopped trusting it.
I had two jobs. One was the design work itself. The other was changing how the team decided things, because designs were being argued instead of tested. Every problem went through the same four steps inside the product managers' sprints, and every result on this page was set as a target before anyone designed.
Who was involved
- Network engineers The customers' people who run the network and use the portal every day.
- Sales engineers The company's own, who fix problems for real customers; they stood in for customers in testing.
- Product managers Ran the sprints and set priorities; the hypotheses worked inside their cycles.
- Three product designers The team I led.
Context
The portal already existed, and it did not work. Setting up a network took eight weeks. The live map of the network showed up empty. The bulk upload, a spreadsheet meant to change many devices at once, had never worked. Common workflows sat four or more clicks deep in menus inside menus. When something broke, the screen filled with thousands of warnings and no clue which one mattered.
The engineers who used it stopped trusting it. That kind of failure never shows up as a bug report, so another round of redesign by opinion would not have found it either. The team needed a way to tell, before and after each change, whether the change had helped.
The problem statement
The contract promises what we committed to. Today the portal how it falls short. That puts what is at risk at risk. We'll know it's fixed when the signal.
Filled in for monitoring
The contract promises monitoring that lets customers find, understand and resolve problems in their network. Today the portal fills the screen with thousands of warnings and no clue which one matters. That puts the engineers’ trust in the portal at risk. We'll know it's fixed when an engineer can name the circuit that is down in under 30 seconds.
Each product problem was written in this form before it went to design, worked backward from what the customer had been promised. Here the promise comes from the company’s own proposal for monitoring, which asked for screens that let customers investigate and resolve any problem that came up.
Research
Before anyone designed a thing, each problem became a hypothesis with the number that would settle it. Designers, product managers and engineers then turned that number into questions a person could answer out loud, and kept them in a shared field guide.
The hypothesis template
We believe giving this feature to people doing this job will achieve this outcome. We'll know we're right when we see this signal.
Filled in for the warnings timeline
We believe giving one warning timeline per site to people doing triage when part of the network breaks will achieve finding the cause of an outage fast. We'll know we're right when we see an engineer find the cause in under 30 seconds.
Every design started as this sentence, with the last blank filled in before anyone opened a design file. Writing the signal down first meant nobody could quietly change what success meant later.
Why there is no persona in it
The template names a job, not a person, and that was on purpose. I had made personas for years, and by this point I no longer believed they did the work they were sold to do. A persona gives a made-up person an age, a photo and a backstory. None of that changed what a network engineer needed when part of the network went down. The job did: what they were trying to do, under what pressure, and how they would know they had done it. The portal had to work for whoever was on shift.
Demographic details also invite guessing. Once a pretend user has an age, a gender or a nationality, teams start designing for the stereotype instead of the evidence, a problem researchers have documented in how personas get used (Marsden and Haag, CHI 2016). If our research had shown that something about who the users were really changed the job, such as the language they worked in, it would have gone into the hypothesis as a finding. It never did. So the template left room only for what we could test: the feature, the job, the outcome and the signal.
Validation Field Guide
Before the session
- Hypothesis under test: We believe giving one warning timeline per site to people doing triage when part of the network breaks will achieve finding the cause of an outage fast. We'll know we're right when we see an engineer find the cause in under 30 seconds.
- Pass mark, set before the first session: every participant shows they understand the screen in under 30 seconds. Thirty seconds is the failure line.
- Participants: the company's sales engineers, standing in for customers. Note this on every result; where they and the live data disagree later, the live data wins.
- Ask permission to record, and say how the recording will be used.
Introduction
- Thank you for helping. This takes 30 to 45 minutes.
- We're testing an early prototype, not you. Nothing here is finished, so criticism is the most useful thing you can give us.
- Please think out loud as you go. I may not answer questions during the tasks; I'll come back to them at the end.
Warm-up
- Tell me about the last time something broke on a customer's network. How did you find out?
- What did you look at first, and what do you use today to find the cause?
Time to understanding (the clock starts when the screen appears; 30 seconds is the failure line)
- What, if anything, is wrong on this network?
- Which line would you deal with first, and why?
- Record: seconds until they showed they understood, and whether their answer was right.
Find it (no hints, no clicking for them)
- Show me how you would find out more about the problem you'd deal with first.
- Record: reached the detail without help, yes or no.
Decide
- What is happening on this line right now, and how long has it been happening?
- Is it past its limits? How can you tell?
- What would you do next?
Wrap-up
- What did you expect to see that wasn't there? What would you take away?
- How sure are you of your first answer, from 1 (guessing) to 5 (certain)?
Design
We put the warning history, the live numbers and a picture of the devices in one place. A problem shows up as one shaded patch on the map instead of a thousand stacked warnings, and each site gets one timeline of its warnings that you can rewind and leave notes on. Reusable templates replaced the broken bulk upload, and tables were rebuilt so an engineer could act on many devices at once.
What I did
Every problem went through the same four steps, inside the sprints the product managers already ran.
1Write it down first
Write the hypothesis and its number down before anyone starts designing. Writing it first meant nobody could quietly change what success meant later.
2Ask it out loud
Turn that number into a question a person can answer out loud: name the circuit that is overloaded, name the one that is down, show me where you would click. Designers, product managers and engineers wrote these together in a shared field guide.
3Design against it
Thousands of stacked warnings became one timeline per site that you could rewind. Reusable templates replaced the broken bulk upload, and the network was drawn live instead of left blank.
4Test before building
The company's sales engineers, who fix problems for real customers every day, tried the tasks on a clickable prototype while we scored them against what we'd written down.
Only designs that passed got built. Those same tasks became the tracking built into the product, so the measuring carried on after launch.
Iteration
The company's sales engineers tried each design on a clickable prototype while we timed how long they took to show they understood it. We had set 30 seconds as the line where a design failed. The average was 8 seconds, nobody came close, and in several sessions the sales engineers stopped the exercise themselves once they understood the idea. When the team disagreed, we built both hypotheses and tested both. Only designs that passed got built.
A design that didn't work
Not every version held up. An earlier device screen told you how a device was doing almost entirely by color: a green check on every part of the network, green and red dots along the last 24 hours, circuit bars striped green, yellow and red, and a smiling or frowning face for each circuit's score. When everything was fine, it looked fine. When something broke, the screen didn't say what broke or what to do about it. You had to hunt for the red, and about one man in twelve can't easily tell that red from green.
The later version, the one at the top of this page, kept the color but stopped leaning on it. Each problem carries an icon and a word, Warning or Down, the lines between parts are drawn solid, orange or dashed, and the newest problem is written out in a sentence with the buttons to fix it right underneath.
Outcomes
The same test questions became the tracking built into the live portal, so the measuring carried on after launch. About 20 warnings boiled down to one per site, and engineers found the cause in under 30 seconds, the target written down before designing.
8 → 4 weeks
Reusable setup templates halved the time to bring on a new customer's network.
+55%
Task completion rose after common tasks came out of menus four or more clicks deep.
3 designers
I led three product designers; each design started as a hypothesis with its number first.
Retrospective: what it takes to keep a practice going
The habit did not outlast my time there. While I was on the team, we wrote the hypotheses down first and worked from the field guide, and that is where the numbers above came from. When I left, the team stopped.
That came down to investment and risk, and design, product and engineering weighed them differently. Engineering needed an interface its own people could build and maintain, so the company chose PrimeVue, a free kit of ready-made parts for Vue.js, the framework the portal ran on. It was a reasonable call: low cost, low risk, and within what the team could support in 2024.
Product's pressure that year was speed. AI-assisted engineering had just arrived, and the push was for faster output. Design's case was that speed holds up only when the system is written down: a codified design system, with clear rules for who changes it and how. That costs time up front, and the company chose to spend it elsewhere.
I also proposed one place where a decision, the evidence behind it and the version it shipped in would sit together. It wasn't adopted. Next time I would make that case as a risk to the roadmap, in product's and engineering's terms, and find an executive sponsor before changing how a team works, not after the numbers came in.
What my team said
Bobby tackled everything from day-to-day tasks to complex features. He always keeps a user-centered focus, whether in concepting or usability testing. Because of his efforts, our clients and our design team has a real sense of direction.
Product Designer Design team
I’m grateful to have worked with Bobby. He’s been crucial to [the company], consistently delivering and bridging communication between our teams. His daily presence improved our velocity and morale, even in a remote-first setup.
Product Manager Client team
It was an honor working with Bobby and I’m sorry we couldn’t retain him as long as we wanted. Regardless, his impact on streamlining onboarding and championing design ops is undeniable. We’re thankful for the path he set.
Director of Software Engineering Client team