Back to home

The case for Cisco and “Network Insights”

Finding the users who needed us most, then redesigning the dashboard around them.

Phase 1 Security

Summary

Role: Senior product designer, lead for both products
Team: 1 PM, 1 eng lead, 10 engineers, and me
Timeline: Jan – Oct 2023
Tools: Figma, Miro, Zoom
Outcome: Research changed our main persona, and validated designs for dev release

 

Cisco’s network security tools held millions of rows of data. Analysts drowned in alerts and opened tab after tab to investigate. I led 4 rounds of research and design, with 30+ interviews. Halfway through, we found our secondary persona got the most value from the product and the least design attention. That changed where we focused the dashboard.

Quick background check

Cisco’s Secure Network Analytics and Secure Cloud Analytics help security teams find threats on their networks. They collect huge amounts of network data, often millions of rows, and hide most of it behind layers of search filters.

Analysts didn’t need more data. They needed to know what mattered right now. My job was to lead the vision for the main dashboard, the first screen analysts see every day, and turn that flood of data into clear, prioritized insights.

Discovering the problem space

To begin, I ran workshops with stakeholders to find which data sets mattered most and which ones people actually used. Here’s what kept coming up.

Secure Cloud Analytics pain points:

  • It ships with a long list of preset alerts, and most users never change them
  • Alert fatigue from poor priorities and unclear names
  • Users wait for email alerts before opening the product
  • Security analysts and network analysts use the product in very different ways

Secure Network Analytics pain points:

  • Users send data out to a separate security tool (a SIEM) just to organize it
  • Everyday users struggle to tune alerts and priorities
  • Network analysts open many tabs to investigate one issue
  • Users want deeper network data, not more alarm categories

Defining the solution

I was assigned the vision for the main dashboard and daily experience, a high-profile project with high risk. Early on, I found we had very little data to back up our assumptions about our main persona, Remi. So before designing much, I built a research plan: an external survey, 30+ interviews, and 4 rounds of research and design.

The turning point

We started out designing for Remi. But halfway through, the data told a different story. Our secondary persona, Sam, got the most value from the product. Most of them jumped in at step 3 or 4 of an investigation, already hunting a threat. We’d been designing for the wrong starting point.

So we shifted. We decided to make the dashboard more of a workboard that led with spikes and anomalies instead of a general overview for management.

How we worked

1. REFINEMENT AND PRIORITIZATION

This step typically consisted of meetings and workshops focused on refining priorities, roadmap planning, journey mapping,competitive analysis, user workflows updating designs, assumption mapping, aligning with stakeholders, and creating a research plan for the following phase.

(Personal tip:  Although plenty of activities can be done at this stage, the most important to me is clear and consistent communication. No amount of activity can make up for building trust with stakeholders and translating complex ideas into concise problem and value statements.)

This part of the process was always the most crucial and challenging as it can, at times, feel like you’re going in circles. Still, I found that we could keep the work on track and progressing forward by minimizing one-off sessions and planning strategic workshops and collab sessions with effective communication. It was essential always to be selective with the users we were going to interview to ensure that they matched our target persona for the given user study and to ensure our research questions were all ironed out and in alignment with our stakeholders.

2. IDEATION AND PROTOTYPES

This step is always the most fun and often looked at as what we do best as designers. To the right you can view the progression of similar dashboard screens and prototypes we tested throughout the process. These are just the screenshots of the actual prototypes that were filled with interactions, drawers and contextual data.

(Personal tip: It’s important to never rush or skip over the prototyping phase even when your designs are sticking close to a design system. This can result in critical issues or misdirections in user interviews or stakeholder reviews.  I say, take your time and gather feedback and refine your design as it can drastically affect the feedback you will receive.)

Designing for dense data
Analysts lived in tables with thousands of rows. They needed to go from “something’s off” to “here’s why” without opening 10 tabs.

Helping analysts decide what matters
Alert fatigue was the core problem. Preset alerts piled up, and people stopped reading the emails. One CTO told us:

Original SNA dashboard
Original SNA dashboard
Initial concept given
Initial concept given
UI analysis
UI analysis
Cisco example
Cisco example
Cisco example
Cisco example
Dundas exploration
Dundas exploration
Dundas contd.
Dundas contd.
Dundas contd.
Dundas contd.
Network workshop
Network workshop
Security Insights
Security Insights
Phase 1 Security
Phase 1 Security
Phase 1 Network
Phase 1 Network
Phase 2 Security
Phase 2 Security
Phase 2 Network
Phase 2 Network
Phase 3 Security
Phase 3 Security
Phase 4 Network
Phase 4 Network

3. USER INTERVIEWS AND HUNDREDS OF NOTES

Now, this step tended to always be the most time consuming of them all and for good reason. You should never rush good analysis of user feedback and be sure to always check yourself and others of assumptions you may be making when making sense of it all.

With a research plan and study flow in hand, it was time to test the Figma prototype with the users. We were sure to leverage the current design system so as not to add extra usability elements within the user testing and include data that would be familiar to the user’s common workflow.

Adequate note-taking was always taken in the voice of the customer and devoid of any personal assumptions. It was key to keep these notes sorted correctly and efficiently using the template you can see in the image on the right. Team members would often hop on the call in the background to aid in note-taking but it was crucial that I also watch every video and fill in the gaps of notes after every call.

4. ANALYSIS, PRESENTATIONS AND HANDOFFS

The fourth and final step is often the most rewarding. We start by completing a thematic analysis of all the notes we took from the interviews. We do this by breaking down all the insights into smaller digestible categories that are sorted by similarity and priority. We then quantify them and cross-check that our original research questions were being answered.

(Personal tip: It’s super easy at this stage to get excited with PMs on delivering value that we can quickly “overengineer” some of the discovered value and features and not include engineering leads early and often when prioritizing where to focus next steps.)

After this comes everyone’s favorite part of sharing these insights, highlights, and recommendations through presentations, recordings, and vidcasts. It’s vital to ensure that every main stakeholder receives this feedback and is a part of the collaboration process for decision-making and planning.

After each stage of research, it was essential that we broke down and implemented any key design elements that were validated enough to be handed off to development that fit within their bounds of key initiatives and time management.

"The longer I've been here it seems we've programmed ourselves to constantly send us email alerts so my mailbox gets filled with about a million email alerts and frankly, most of which go straight to the trash. I'll be honest: if we knew that we were getting alarms that truly were a high probability issue, we would probably look at email, texting, or webex messaging to help prioritize those. But we just don't have time to dive in all of them."
User 1
CTO

Final prototype we tested

"I think this is a great dashboard. I think it tells me what I need to know. It tells me if there's anything imminent and, if so, what they're using. It also shows me my alerts and alarms and shows me kind of an overview of what concerns it's seeing based on your machine. I also like that it gives me the high-value targets, the concern area or machines, and that way you can see how protected things are."
User 2
SecOps Lead

What changed

  1. Shifted the dashboard’s focus to Sam
  2. Turned the dashboard into a customizable workboard with sorting, filtering, and pivoting
  3. Led with trends and percentage changes to encourage proactive threat hunting
  4. Insights shaped the 2024 roadmap for SNA Revamp

What I learned

  1. Earn trust early. On high-risk projects, clear and steady communication with stakeholders matters most.
  2. Never skip prototyping, even when you’re working inside a design system.
  3. Bring engineering in early, so the plan doesn’t get overbuilt.

Let’s work on
your product together.

Send me an email

noblecreativeaz@gmail.com

Visit to download my resume and see my info