Network Diagramming · Enterprise / B2B · 2021-2024
Topology Builder
Topology Builder: recreating network-diagramming tool from poc to b2b Saas.
- ROLE
- Lead UX Designer (the diagram view)
- TEAM
- Co-designer (table-config view) · product manager · product owner · QA analyst · engineering team
- MEDIUM
- Desktop web app
- CLIENT
- Cisco (dCloud)
- STATUS
- Shipped to new user groups
TOOLS
- Figma
- Miro
- iPad + Adobe Sketch
At a glance
- Problem
- A proof of concept built by engineers with no UX, suddenly critical for teams it was never designed for.
- What I did
- Took it to B2B SaaS: feature parity first, then diagrams that are easy to read, build and search. Then a hybrid canvas where drawings and live assets share one view.
- Outcome
- Users tripled, the team got its own booth at Cisco Live, and it is being prepared to sell as standalone software.
- 31.9k
- Users, up from 10.4k
- 56.9k
- Projects, up from 21.3k
- 28k
- Cisco Live attendees, where the team got its own booth
Challenge & context
I designed Topology Builder, Cisco's network-diagramming tool, taking it from proof of concept to B2B SaaS. As adoption grew from 10.4k to 31.9k users, people wanted to draw full solutions on top of live network assets, so I invented a hybrid canvas where static drawings and live assets could share one view without users confusing one for the other.
I took Cisco's network-diagramming tool from proof of concept to B2B SaaS, then designed a hybrid canvas where drawings and live network assets share one view.
Problem
Topology Builder was built ad hoc by engineers with no UX, a tool for demo developers only. Then remote work made it critical infrastructure for teams who'd never been designed for. It couldn't show a full solution, couldn't handle complex diagrams, and had no way to find anything.
The brief: hit feature parity with the old version, then make complex network diagrams genuinely easy to read, build and search, for user types the tool was never meant to serve.
System analysis, five interviews, one short survey
The research turned up 13 issues. They grouped into five problems, and each one became a design response that drove the whole redesign:
What we found
What I designed
No way to find items in a large diagram
Map search
Can't see which device connects to what
Clearer, colour-coded lines
Large diagrams too cluttered to read
Pan, zoom and a navigator
External entities can't be shown
On-diagram boundaries
Diagrams are static, all items must be configured
Freehand drawing for non-functional items
All 13 findings
- VPOD gateway not visible
- External entities cannot be depicted
- Current version does not show full picture of the solution
- All items must be configured
- No accompanying settings with VM templates, only name of the server
- Fluctuations in demo size not visible
- Storage size
- Excessive RAM use while running demo
- Better fitting alternate icon desirable
- Large diagrams create screening issues
- No facility for collaboration on building the diagram
- Diagrams are static and it cannot be used as a diagramming tool
- No way to find items
“The old tool asked users to configure everything. The redesign had to let them draw a picture first.”
How I worked
- Team
- I led design on the diagram view, with a co-designer on the table-config view, around five engineers, a product manager, a product owner, a QA analyst and the full management team.
- Keeping it coherent
- Daily UX check-ins and bi-weekly stakeholder reviews kept a large, ambiguous project on track.
- Research without direct access
- I couldn't reach users directly, so I used system analysis, five interviews and a short survey. After launch, a feature-request voting tool set the priorities.
- Options, not answers
- I sketched several concepts per problem and presented them to the team to choose from. Search had four.
- No precedent
- There was nothing to benchmark the hybrid canvas against, so we tested, watched, and let users choose between our ideas.
- Design QA
- I tested the UI the engineers built against the designs.
What I did
Part one
The redesign
Feature parity first, then diagrams that are easy to read, build and search
01A floating pill menu, not a fixed sidebar
Replaced the fixed sidebar with a floating pill menu, so complex diagrams had room on screen.
02Colour connections like a Tube map
Alternating line colours, borrowed from the London Underground map, made dense diagrams scannable.
Before: single-colour lines
Shipped: coloured, patterned connections
03A search modal that shows results with context
Explored four search patterns; shipped a modal that shows results with context.
04Line types and icon states carry meaning too
Dashes, dots and icon states show connection type and device state at a glance.
Concept & rapid prototyping
I quickly sketched ideas for each stated problem. Here is one: search.
Idea 1: highlight and zoom
DroppedThe result is highlighted and zoomed in on the diagram, with the settings panel open.
Idea 2: highlight all
DroppedHighlights every potential result, each device opening on its own side-panel tab.
Idea 3: grey out
DroppedFades non-matches and leaves matches at full opacity, with a button to clear the search.
Idea 4: search modal
ShippedA modal lists results with info; selecting one highlights it on the diagram and opens its settings.
App structure
Small examples of the user flows I redrew for the redesign.
01A floating pill menu, not a fixed sidebar
Replaced the fixed sidebar with a floating pill menu, so complex diagrams had room on screen.
- Problem
- The screen was too cluttered for complex topologies. The menu and search bar left the diagram tiny.
- Tried
- Fixed, fully-labelled sidebarSearch bar directly on the canvasCurved connection lines
- Shipped
- A floating pill menu plus a hover zoom panel, with straighter connection lines.
- Why
- A small learning cost on the icons, a huge gain in canvas space. The side panel also tabs multiple open devices, a feature users loved.
On a diagramming tool, every pixel the UI takes is a pixel stolen from the work.
More detail
A full left sidebar was clearest to read but ate the canvas, leaving the diagram, the actual point of the tool, tiny.
The first full wireframe kept that fixed, fully-labelled menu and put search directly on the canvas. Everything the user needed was on screen, and tabbed side panels categorised information well, but the curved connection lines read as visually inconsistent.
02Colour connections like a Tube map
Alternating line colours, borrowed from the London Underground map, made dense diagrams scannable.
- Problem
- On complex diagrams you couldn't tell which device connected to which VLAN. Every line looked the same.
- Shipped
- Alternating line colours, borrowed from the London Underground map, plus dashes and dots for connection types.
- Result
- A dense diagram became scannable.
The clearest reference wasn't another network tool: it was a 100-year-old transit map.
Before: single-colour lines
Shipped: coloured, patterned connections
03A search modal that shows results with context
Explored four search patterns; shipped a modal that shows results with context.
- Problem
- No way to find items in a large diagram.
- Tried
- Highlight and zoom to one resultHighlight all results, a tab per deviceGrey out everything else
- Shipped
- A search modal, opened from the pill menu, that lists matches with detail. Picking one highlights it and opens its settings.
- Why
- We chose it as a team when I presented the four ideas. Grey-out clashed with hidden items, and multi-tab opened too many panels.
- Result
- Opening the selected device in a side panel drew positive feedback from users and business stakeholders.
04Line types and icon states carry meaning too
Dashes, dots and icon states show connection type and device state at a glance.
- Problem
- Colour alone left two questions: what kind of connection is this, and what state is this device in?
- Shipped
- Dashes and dots for connection types, and a set of icon states for errors, connections and configuration types.
- Result
- A glance told users what they were looking at.
Colour told users which VLAN. Pattern and icon state told them what kind of connection or device they were looking at.
What shipped
Interaction demo, built in Figma on Cisco’s UI design language.
Supporting screens
A few of the many other screens and configurations in the V1 redesign.
The feature-request tool showed a clear ask: draw a full solution, not just configure live assets.
What I did
Part two
The hybrid canvas
What the feature-request tool told us next
05Separate views, switched by the zoom tool Validated in testing
A view switcher in the zoom tool, validated in testing, separates the Master, Config and Drawing views.
06A contextual tools menu, not one giant menu
The tools menu changes with the view, so users only see the tools that apply.
07Drawing options in a top bar, not the side panel Confirmed in testing
Drawing options open in a top bar and network settings in the side panel, so where it opens tells you what you’re editing.
The next problem
Users wanted to draw a full solution, not just configure live assets. That created a new problem: static drawings and functional network assets look identical on the same canvas, and there was no existing tool to benchmark against.
Method. The built-in feature-request tool, where users upvote what to build next, ranked the priorities (diagramming, import/export, enhancements). I then interviewed users who'd left emails to go deeper.
What people wanted
Frustrations
Motivations
They asked for
What I designed
Add labels
Text tool
Draw boxes
Box tool
Add static images
Upload & insert
Tell diagram types apart
View modes: the real problem to solve
The first three were straightforward. The fourth, telling static from functional, was what this phase was about.
“Two things that look identical but behave completely differently is a recipe for user error. The whole design had to make that difference obvious.”
Concept & rapid prototyping
I sketched the hard part first (how to let users see, and switch between, static and functional layers) before committing to wireframes.
05Separate views, switched by the zoom tool Validated in testing
A view switcher in the zoom tool, validated in testing, separates the Master, Config and Drawing views.
- Problem
- In a combined view, static and functional items were indistinguishable.
- Tried
- Bottom strip: clearest, and users said so, but it ate screen space and blocked a future terminalTop menu
- Shipped
- A view switcher in the navigator zoom tool, moving between Master (all-in-one), Config and Drawing views.
- Why
- It takes the least space, sits with the other view controls, and leaves the strip and top bar free for features still to come. Once fluent, users work in the combined view.
The clearest option isn't automatically the right one: I picked the one that still worked two features from now.
06A contextual tools menu, not one giant menu
The tools menu changes with the view, so users only see the tools that apply.
- Problem
- One menu holding every tool was cluttered. Users couldn't tell what applied to what.
- Tried
- One all-in-one tools menu
- Shipped
- A menu that changes with the view: drawing tools in Drawing, network tools in Config, both (greyed where unavailable) in Combined.
- Why
- Less clutter, and room to grow as features are added.
A menu that shows everything shows nothing. Context does the filtering the user shouldn't have to.
07Drawing options in a top bar, not the side panel Confirmed in testing
Drawing options open in a top bar and network settings in the side panel, so where it opens tells you what you’re editing.
- Problem
- Editing a static line looked the same as editing a live VLAN connection: both opened in the right panel.
- Tried
- Settings for every item in the side panel
- Shipped
- Static drawing options open in a top bar; network settings stay in the side panel.
- Why
- The location itself tells users which kind of thing they're editing.
Where a control appears can carry meaning. Position told users what type of item they had, before they read a word.
What shipped
Interactive prototype of the Master, Config and Drawing views, on Cisco dCloud’s Magnetic UI design language.
Impact & evidence
31.9k
Users, up from 10.4k (Cisco dCloud signup data)
56.9k
Projects, up from 21.3k (Cisco dCloud signup data)
28k
Attendees at Cisco Live Las Vegas, where the team got its own booth
V1 parity
Reached feature parity with the old version, before the growth that followed
New users
New user types onboarded, beyond the original demo-dev audience
Standalone
Being prepared to sell as standalone software
Its own booth at Cisco Live
The team got its own booth at Cisco Live Las Vegas, attended by 28,000 people. Users came up to me at the booth to say thank you for building something they genuinely enjoyed using.
What I learned
- Designing for users I couldn’t directly access, under constantly changing requirements, with a two-person design team.
- Daily UX check-ins and bi-weekly stakeholder reviews kept a huge, ambiguous project coherent.
- With no precedent you can’t measure against competitors: you test, watch, and let users choose between inventions.
- The feature-request voting tool made prioritisation objective instead of opinion.
Would do differently
- See the topologies run in real life. Covid meant we never watched the configurations work in the real world.
- Push the visual style further. It conformed to the UI kit, but could look more appealing within those constraints.