Improving onboarding experience of routers in Network Management System

Table of Contents

Cisco CrossWorks is a Traffic Engineering tool used mainly by ISPs (Internet Service Providers) and CSPs (Cloud Service Providers). It helps them to run their network in optimal condition with minimal outages.

Introduction #

It uses technology called MPLS which uses labels to transfer packages instead of standard protocol. For the same reason it can monitor any network type regardless of the protocol it is running. It can actively monitor the network traffic and predict and resolve the issues even before it occurs. It has the capability to dynamically route the package traffic based on multiple inputs and always find the fastest route regardless of the network protocol or architecture of the network.

In short it works somewhat similar to the city traffic management system. It stands as a central server which monitors all the traffic in the network and reroutes the traffic for smooth transport of data. It does not follow the conventional package movement protocol.

Is it one of essential tools for ISPs to generate more revenue utilizing their full resources, without making any investments. Clients can sign-up contracts with them and CrossWorks would care for the network performance and maintain it within the acceptable level of outage.

Project Goal #

To improve user experience the device onboarding steps in CrossWorks. After repeated feedback from the customers, the project team had decided to improvise the overall usability of the application without breaking the current architecture. Two releases were dedicatedly slotted for the usability improvements.

The app has 5 different modules which includes Traffic Engineering, Topology, Device Inventory, Security and Automation. 3 designers were involved in this project on which I was taking care of the Device Inventory and the Automation. We had only one UX researcher who would help us in interviewing users, designers are the primary owner of both research and design.

For this case study I have taken the use case of improvising device onboarding process and describing the process followed in arriving at the final design.

Research #

We are a small team, where designers are responsible for both design as well as research. To have reviewed the current device onboarding steps and noted the key steps and my hypothesis.

After reviewing the current device onboarding steps, I have noted my hypothesis and planned the following research activities to deep dive into the details.

I have tested it with multiple users (both internal and external) specifically who are first time users.
Collaborated with multiple stakeholders to synthesize feedback and improvement ideas.
To run a competitor analysis to compare our app against our key competitor.

Usability Testing #

Tested with users from both outside and inside Cisco. Mostly selected users who are using it for the first time to avoid use of previous knowledge. It was unmoderated user testing, I have uploaded the prototype on maze.co and shared with users from different geography for testing.

Following questions were asked during the testing

Look around the app and talk about what you think the site is about. What can you do here? What’s it for, what strikes you about it?
What is the first thing you would do when you arrive on the app? Try to do that thing now - After compilation task rating 1 - 5
Adding a new device to the inventory which is not part your network - After compilation task rating 1 - 5
Add a device which is already from the network - After compilation task rating 1 - 5
Add 300 devices using the CSV file provided - After compilation task rating 1 - 5

Stockholder Expert Interview #

I have collaborated with PMs, TMEs and other field executives who work directly with the clients for their feedback. Also I have collected some of the known solutions which we can adapt. Here are some of the feedback which I have noted

Also I tried installing a session tracking tool to get more details about users behavior. But due to security reasons clients didn’t allow us to track.

Competitor Analysis #

As I heard from the multiple discussion I made a list of competitors who offer similar service and features like crossworks. We approached the Cisco Weapon team for this. They have access to most of our competitor apps with data. After discussing it we reduce the list to two important competitors for further analysis

After analyzing we got lot of ideas on UI improvement

Use of side panel instead of Module. We have seen that the side panel is being used to edit/vide additional information instead of opening in a new model or page. This helps the user to quickly navigate and view content clearly.
We were missing auto-discovery, where both our competitors have that feature. It would look for new devices in the network frequently and notify them if anything needs their attention.
Asking only the minimal required information while onboarding.

Design #

After the analysis, the following changes were proposed.

The new UI design was incorporated following Cisco guidelines
Simplified Add device flow
Simplify the Bulk upload by asking only required details in CSV and inline error rectification
Auto Discovery feature
Store the important details and reuse it instead of repeatedly asking the user
Enhanced device details with visual representation of ports and connections.

Simplify Add Device Flow #

The flow was redesigned to ask any of the device identifiers like IP, Host Name etc. and fetch the available information automatically. User don’t have to enter the details which are already available.

Bulk Upload #

The device details will be verified and error items would be highlighted before they get added. Users can fix the errors within the panel and they don’t

Minimal CSV input format #

CSV import plays a crucial role in migrating networks. While importing 100s of devices bulk import would be preferred. In the current template we have 32 fields which is a difficult step to make. After analyzing we figured out only 8 fields are required from the user. Rest of them can be fetched from the device or reusable information which can be grouped and added before.