Redesigning Cisco Network Analysis Tool.

WAE (WAN Automation Engine) is a network analysis app. Used by internet service provider to run a outage free network. The tool helps to simulate the traffic with actual data, forecast issues, and suggest optimisation methods. It can predict the result precisely since it runs the analysis on actual data.

Introduction #

WAE Design consists of two primary parts based on its functions, One is WAE collector and the other is WAE Analysis. WAE collector collects various data from multiple networks and archives it on a scheduled period. WAE analysis simulates the network traffic and analyzes by running various test cases and scenarios.

I’m taking care of the WAE collector, which collects various network data like Topology, VPN, LSP, BGP, Traffic, Demand, NetFlow etc. All the collected data would be aggregated into a single file and stored in a folder for further analysis.

Goal #

The current tool was not user friendly, due to repeated customer feedback, and losing customers to competitors, the management team decided to redesign the App to make it user friendly. Hence usability plays a major role in success of the current release.

I was leading the WAE collector design project with 2 more designers. My team includes PM, SME, Technical Architect, Dev team, and TME (Technical Management Engineers). Below I have described the process I followed to achieve the design.

Discovery #

Since it is a redesign project it started by asking feedback about the current implementation from the PMs, TMEs, Technical Leads and prioritized the key issues. Further I did a heuristic review on the complete application and noted the usability issues. The current product has a major usability problem.

During the user testing with TMEs who are using it for the first time, we noticed they get stuck in many places and are not able to complete without our help. I repeated the testing with users from multiple locations and found the repeating pattern.

To educate myself about the technical details about the network data type and its usage, I had gone through several documents like Product Wiki, Help documents, Technical guide, Presentation made by PM and TMEs etc. Some of the presentations even had the customer use cases, feedback etc. which was helpful.

Problems Identified #

After about 20 days of analysis I have listed the following 3 improvements for the first release. I have presented it to the team and described how it can improvise the user experience and the overall impact.

Currently, the WAE installation is through CLI only experts can do it. WAE requires a specific storage space, RAM, OS Platform, framework (Like Python, Perl, FontConfig) etc. WAE does not verify and doesn’t let the user know about the reason for failure. It takes a lot of time and effort for the user to verify each requirement and identify the reason for the failure. A simple verification check can help the user identify the missing requirement and quickly fix it. It will make the installation step much quicker and quickly start using the product without much wait.

To start collecting the network data the user needs to provide network access information, device details, Agents which are required to collect the data etc. Without these details the collection can’t be started, which is where most of the users are getting stuck. Users need to go back and forth to figure out these steps, which is frustrating to them. A guided approach to get the required details upfront and make the composer flow straight forward, without any back and forth.

User composes the required network data mixing many different types of data. In the current flow, it looks like they can start composing from any data type. But in reality they need to follow a sequence. The current build was based on the assumption users would be aware of the order. But it was not true. We observed users starting with VPN info without having topology info and trying to figure out why it is not running. Our new design must make this flow simple and guide them in a proper sequence.

Analysis #

After getting the team’s approval to work on the 3 key stories listed above, I deep dived and collected more details for further analysis. I did the following analysis before moving on to design.

Data Analysis #

After Discussing with the Tech architect and referring several documents I was able to understand about each network data in detail and the sequence in which it would be collected. Here is the illustration of the sequence and few insights about them

1. Users need to start with a basic topology information on top of which the additional Topo information can be added like VPN, BGP, LSP etc.
2. One stands as the source of the other. Users need to follow a sequence. For example, Multilayer data can be collected only after configuring the LSP.
3. An external script can be injected at any phase and it can be in multiple.
4. The two aggregations, one after the topology information is collected and the second one is at the end.
5. Some or dependent for example, traffic demand can be collected only if the traffic data is collected.
6. Basic topology impacts the subsequent. For example, for a XTC topology data the LSP will also be collected in XTC format.

Users #

The primary users of this App are Network Architect, and Network Engineer. For some use cases a network admin would also use this tool but very rarely. I have referred to the following person’s from the Cisco central research team.

Architect: Different users use it for different reasons, for example an architect would use the app to analyze the current site operations and understand the scalability issues upfront.

Arun - Network Architect.pdf

Engineer: Where as engineer would use it to re-configuration for the optimal running for the network.

Edward - Network engineer.pdf

NOC Tech: Would use it for regular analysis and error fixing.

Kay - Advanced NOC Tech.pdf

Use Cases #

Here some of the common uses cases which I have figured out for each persona, with respective to WAE collector.

Scenarios #

Some of the scenarios I have collected are WAE Analysis in general. These scenarios are important for the WAE collector, because the analysis is based on the data collected. Users need to collect all the information required for their analysis.

Design #

I started on the design after I got the required information via my analysis. For this case study I will explain only the design process followed for the composer flow as it is the core function of the application.

I have tried at-least 3 options for composure flow alone and analyzed the pro’s and con’s testing with multiple individuals. I have created the options with the following goal in mind.

1. Simple to use
2. Users are trust the data what is been collected and confident for their analysis report
3. Able to configure all the required data for analysis with least number of clicks
4. Even the first time users must be able to use it feature without anyone’s help

Wireframe #

I always start my design with wireframe as it can be quickly done and iterated, helps the user to focus only on the functionality and eliminate the design related feedback. I will take the design related feedback in the next step which is the mockup step. Here I will be only testing the flow and how effective in addressing the problem. Below are some of the options I tried for composure flow

Options 1: Each collector are carefully sequenced in various segments based on the data they are collecting. The stepper would help the user to go in a sequence and finally schedule the collection.

Option 2: All the data options are listed in a appropriate groups. Users can only configure only the items which they need. On the scheduler page they can choose and sequence them in a order for aggregation and archiving.

Option 3: Stepper based on user selection. It is a combination of first and 2nd option User can select and configure only the options they wanted to configure. And a horizontal stepper would be build in a logical sequence.

Mockup #

After many round of review, option 3 got most number of voting. I further designed the mockup and prototype based on our team’s design system.

Further plans #

1. Users are expecting an auto-discovery of devices after proving the network access details. Which is one of the key selling factors for our competitors. Dev team needed more time to plan this feature, so it was not considered for the first release.
2. Starting with a template based on user requirement another repeated feedback from the user. They wanted to start by a template based on their intention. To address half of the feedback, the user can select the collector which they wanted to configure. But building as a template would need further research.