Cisco

Helping network teams see where the problem is.

vAnalytics gave enterprise network teams their network data, but finding the cause of a slow or failing connection meant reading raw tables and tangled charts. I redesigned how they find the problem, and how product line managers (PLMs) set up who can see what.

Role

Sole designer

Team

30 engineers

Users

Network operators, architects and admins; internal product line managers (PLMs)

Status

Prototypes, presented to upper management

2

Deciding who sees what and where it landed

1

Finding the problem

CHAPTER 1


Finding the problem

Network diagnosis: from "something is slow" to which tunnel, which device and which provider.

BEFORE

The data was there, but the answer wasn't

The old screens put every application on one line chart and every number in a table. To find a problem, a network operator had to read rows of decimals and guess which path they belonged to.

WHAT USERS NEEDED

Start from the questions, not the data

Customer feedback came from current Cisco users, collected by Sales and passed to our team. I turned those pain points into the questions a network person asks, in order.

How many devices aren't performing?
How is each tunnel doing?
Where is the problem coming from?
What are my options, and can my connection handle them?

Each screen I designed answers one of those questions.

My question map, built from the customer feedback.


THREE DECISIONS

Make the problem visible before anyone reads a number


DECISION 1

Summary first, detail on demand

The dashboard opens with the answer to "how bad is it": tunnels lost, devices that need action, and the trend since the last 24 hours. Every chart below it can be filtered in place.

  • Titles double as filters: switch a chart from loss to latency or jitter

  • Time filter from the past hour to a year

  • Share a view with a teammate from the chart

Note: these 2019 prototypes label latency and jitter as “m/s.” The correct unit is milliseconds (ms).

DECISION 2

Trace the path, not the row

The map and the snail trail work together. Pick a site on the map and the snail trail shows every hop from that site to its destination, so the operator follows the path to where it breaks.

  • Bubble size and color show how severe a site or tunnel is

  • Line weight and dashes show the condition of each connection

  • Provider colors double as the legend

  • Click a bubble to isolate its path; hover for details

DECISION 3

Show cause and effect in one view

I replaced the raw table with a Sankey diagram. It connects the local device, its service tier and the remote device to the result: quality, loss, latency and jitter. Clicking a device isolates its path, so the operator sees which connection is pulling the numbers down.

A second view shows which applications use the most data, by device, and compares the past 30 and 60 days so teams can spot a pattern before it becomes an outage.

CHAPTER 2


Deciding who sees what

Onboarding enterprise clients without hand-coding.

THE PROBLEM

Accounts nested inside accounts

Clients weren't a flat list. A service provider could have its own partners, those partners had their own enterprise clients, and each enterprise had overlays with their own roles. Every level had different permissions and saw different data.

So each new client went to engineering to be coded and mapped manually.


How might a PLM onboard any client, at any level of the hierarchy, without needing an engineer?


The account hierarchy, mapped with the engineering leads before any screen.

The data model. The three links on the right became the matrix screens below.

DECISION 1

The parent decides the form

One account form for every type. Choosing a parent type opens the matching list in place, and the new client appears in the account partner list once saved.

DECISION 2

One matrix pattern, used three times

Plans, feature roles and overlay roles all answer the same question: which things go with which. One matrix, so PLMs only have to learn it once. Add a plan or role in place, copy a plan, and set trial dates so higher-tier customers can try a new widget.

DECISION 3

Each role edits only what it owns

With this many layers, each role sees and edits only the fields its permission allows. That keeps the backend tidy and avoids manual fixes.

WHERE IT LANDED

Prototypes that set the direction.
Designed, prototyped and presented to upper management

Both chapters stayed at the prototype stage. I shared them with upper management as the direction for vAnalytics. My time at Cisco ended before any launch


LOOKING BACK

What I'd do today –
From reactive to proactive: catch the pattern before it becomes the problem.

I'd test with network operators directly instead of hearing their pain points through Sales. Getting time with customers is hard, but that's a problem to solve, not a reason to skip it. I'd measure how quickly operators notice an issue, how fast it gets resolved, and how they use the forecast view to spot similar patterns early, so teams can act before an outage instead of after it.


Thank you so much!

Explore My Other Projects

Previous
Previous

Stay Safe, Stay Informed with Navify

Next
Next

Brand Engagement with Fike