DNA Center

Digital Network Architecture Center by Cisco is an enterprise class software for intuitive and insightful network management

Project Summary


UX Design




Interaction Flows

Working Prototype

Visual Design

Design Thinking Workshops

Made at


Problem: How can we create a reporting function that will fulfill a variety of users' needs, while also providing meaningful, actionable information?

I'm currently working at Cisco creating end to end experiences for networking hardware and software. There are a huge variety of projects and features that I've been involved in, however for this case study I'll be focusing on how we implemented a reporting feature within Cisco's DNA Center.


Usually when starting a project like this, I would try to get in touch with our users to get some generative data on their current behaviors and expectations. Unfortunately at this time, the UX team had trouble gaining direct access to our target users, and had to use Product Management as proxies. Our PMs have very specific and deep domain knowledge, and I knew that we could leverage that in order to get started. I ran a workshop with PM and engineering to level set, uncover some insights, and make sure we all had the same priorities.

Protopersonas to see how many types of users might use this feature

Needs Affinity Diagramming What do these personas use reports for? What are the key needs?

Dot Voting on features to prioritize and understand feasibility


  • Interpreting reports, especially those with lots of data, can be difficult
  • Some users generate reports while others will just review them
  • Creating reports can be time consuming and tedious
  • Create a reporting function that synthesizes data in a meaningful way
  • Allow different types of users to interact with reports in different ways
  • Allow users to do other tasks while reports are being generated

Creating Structure

I wanted to figure out how reporting would actually map to features and requirements. The product management and engineering teams I was working with really appreciated this, and helped them frame their work within what we were doing on the UX side. In order to distill the learnings from the workshop into requirements, I used a mapping system that worked on the basis of: Users need to do A. In order to do A, DNAC needs to provide B.

Integration & Flows

I then realized that the reporting feature was turning into so much more than a monitoring tool. As a result, it needed to live outside of my team’s section of DNAC. I worked with our Information Architect as well as other team leads to come to an understanding of how a feature like this might integrate into other parts of the product, and get their sign off on integration moving forward.


I also created a series of quick, sketched storyboards that addressed each use case. These helped keep the team aligned, as well as helped us bring back the human element into this project. Often, enterprise products can lose that human touch, the core problems that our users struggle with. Utilizing storyboards helped us keep the people at the center of our focus.


After creating some wireframes, I had the opportunity to run the concept by a few customers. This was a huge win for the UX team as we have historically not been allowed to interact with our customers. While these studies were very informal, they still provided us with key insights relatively early in the process that allowed us to pivot to fit their needs.

(Here is an example of watching our users go through their current report generation process, and expressing their frustration at only having two options for exporting)


  • Users want to manipulate data through third party application
  • Users like guided flows, but wanted as few clicks as possible
  • Network operators want a way to compare reports
  • Allow users to export reports as .csv, or port them directly into Tableau
  • Change our step by step wizard to one long scrolling page
  • Create a tagging and organization system that supports comparison

We decided to pivot, and strip down functionality in order to deliver an experience that aligned with our user's expectations. This also allowed us to create a product that was easier to engineer and deliver more quickly.
After a few more rounds of iteration, we were able to deliver a phase one of the reporting feature that met our users needs and helped them undertand their networks better.


Research Sooner

I'm a firm believer any research is better than no research, but this case study proves that some earlier research with our actual users would have been very beneficial.

Now or Later?

Something I've been thinking about it whether to ship sooner, with a less robust product, or wait to build something extraordinary and take a little longer. Get back to me on this one.

Saying No

Being able to say no to some of the requirements we were given ended up working in our favor. Again, using data from user testing helped us support our point of view.