Topology Builder

The stakes

Topology Builder is how Cisco Sales Engineers build the customised product demos they present to enterprise customers. A demo is often the moment a deal accelerates or stalls — so the tool's failures weren't UX annoyances, they were commercial risk. Engineers were configuring demos under time pressure, sometimes with customers watching, in a tool built entirely by engineers with no design input.

The traditional alternative was worse: shipping and racking physical demo kit, which costs days of setup and thousands of dollars per demo. If Topology Builder worked, virtual environments could replace that almost entirely. That was the real prize — and the mandate I was given as the platform's sole designer.

What was actually broken

I ran a structured discovery phase before touching the interface: 10+ remote interviews with Sales Engineers across global regions (scripts I wrote myself, focused on what happens when the tool fails mid-sale, not just how it's used), followed by a survey to quantify the themes — 100+ responses within days.

Four findings shaped everything that followed:

• No room to work. Configuration editing was cramped into the diagram view. Engineers were making avoidable errors because they couldn't see what they were doing — the single most cited pain point.

• The tool excluded part of its own user base. 8% of male respondents reported colour blindness, consistent with population data. The diagram system communicated through colour alone, so a meaningful slice of a 10,000-person user base couldn't reliably read their own topologies.

• Every demo started from a blank canvas. Setup was slow and inconsistent; engineers had built personal workarounds that introduced quality and reliability problems into live sales situations.

• 82% wanted dark mode. Not cosmetic — these are people working long hours in a visually dense tool, and eye strain was affecting accuracy.

The calls I made

This is where the project was won or lost. The research generated far more feature requests than an MVP could hold, and several stakeholders had their own priorities. I triaged everything against three criteria — user impact, technical feasibility, and fit with the core sales workflow — and committed to three bets:

1. 1.

   Config View — a dedicated workspace for editing complex configurations, separated from the diagram. A dual-screen model: edit in Config View, keep the visual topology alongside. This attacked the top pain point directly.

2. 2.

   An accessible diagram system — line styles (dashes, dots) alongside colour coding, so the diagram never relies on colour alone. The accessibility data made this non-negotiable: a sales tool that 8% of your salesforce can't read is a business problem, not an edge case.

3. 3.

   The Wizard — guided setup with templates and duplication, killing the blank-canvas start that was burning the most time.

Just as important is what I cut. Advanced sharing options and additional integrations were genuine, repeated requests — but they would have delayed the MVP without improving the core workflow. I presented those trade-offs explicitly to senior stakeholders rather than letting scope drift, and held the line. (Both later shipped, in better form, once the foundation was right.)

Decisions worth examining

Config View: separation over compression. The obvious fix for a cramped interface is denser UI. I rejected that — engineers under pressure need fewer things on screen, not smaller ones. The dual-view model gave configuration editing the full canvas while keeping the diagram one click away. Validated through two rounds of usability testing.

Accessibility: tested with the people it was for. Colour-blindness simulation tools showed several palette pairings collapsing into near-identical tones. I introduced line-style differentiation, added a diagram key for context, and then validated with colour-blind participants directly — who reported a marked improvement in reading complex topologies. Designing for the affected users and testing with them are different things; this project needed both.

Dark mode as a system, not a theme. We built on the Cisco UI Kit (the design system I'd created for the Sales Org) for cross-product consistency, but the 82% finding justified a custom dark mode — new components, adjusted contrast ratios and type styles, all within Cisco's brand guidelines. Because it was built as system components rather than a one-off skin, it's since been applied to subsequent products on the platform.

Iterate, then iterate again

Usability testing ran in two phases — four sessions, design refinements, then three more. The most important finding: even after the first Wizard iteration, demo creation still felt cumbersome. The fix was template duplication — start from a proven base demo instead of assembling from parts — and that single change drove the headline result: setup time down by up to 50%.

I also treated adoption as part of the design problem. A powerful tool with a steep learning curve fails quietly, so I built the onboarding myself: a video tutorial hub on the site and a full user guide, shipped alongside the product rather than after it.

Outcomes

• —10,000+ Sales Engineers adopted the tool within the first months of release
• —Demo creation time cut by up to 50% via the Wizard and templates
• —Days of setup and thousands of dollars in hardware saved per demo as virtual environments replaced physical kit
• —Fewer setup errors and stronger customer engagement reported by the sales team, with faster progression through the sales cycle
• —Launched at Cisco Impact, Las Vegas as a flagship internal product, with post-launch surveys showing strong user approval

Looking back

What I'd do differently: I'd instrument the product from day one. We proved the 50% improvement through testing and surveys, but live telemetry would have shown exactly where time was being recovered — and made the commercial case even harder to argue with. That lesson directly shaped what came next.

Where it led: Topology Builder became part of a bigger story. I now design across Cisco's dCloud demo platform, and my current work connects demo activity to Salesforce deal revenue — closing the loop this project opened, from “demos are faster” to “here's what demos are worth.”