VPN

Turning that “less shiny project” into your team’s next big feature

Help Network Operators detect and support VPN connectivity problems

Overview

During one of our sprint cycles, we had available resources to work on a “small story” that would help Network Operators to know if a Virtual Private Network - VPN - was up or down.

Based on research and our network device capabilities, I helped expand the potential of the VPN feature by working with stakeholders and making them realize that Network Operators needed data that helped them be proactive and find VPN issues before customers recognized there was a problem.

The request from our Product Manager

Working on that small VPN feature that “should not take too much time to design and implement in one sprint cycle”

While working with one of the security teams, We would use three sprint cycles of three weeks each to release a feature.

However, in one of those sprints, from our Product Manager, we heard that Network Operators using our VPN product requested a “small feature that should not take that much time"

Team's "ideal" sprint cycle

The problem - What we knew Network Operators were facing

Network Operators don’t have visibility into the current state of their VPNs. Customers would report a VPN issue, and Network Operators would look into the event logs of the security device and try to find the problem.

So what are Virtual Private Networks - VPN -

Provide speed and security to all data in the network

Network Operators use VPNs to enable users to send and receive data across public networks while connected to the private network.

The request from Network Operators, according to our Product Manager

Provide a status - up or down - for each VPN Connection

From the user requirements point of view, it was a small story and straightforward – add a table with a column for the VPN name and a column for the status.–

Actual request from PM for the VPN feature.

Digging beyond the sprint story requirements

No matter how small the sprint story is, it is important to get a broader perspective about users’ current actions and the elements around the requirements that could bring value to the user.

Who are the Network Operators

Network Operators configure, monitor, and troubleshoot the VPN product. Every day, Network Operators receive tickets for a client incident in the network. In the VPN case, the ticket details would state that the connection between the two sites may seem down or slow.

After talking to Network Operators, we compiled the data they would use to find the root cause of a VPN issue or prevent others.

What we found about Network Operators’ jobs to be done

Their main goal is to keep users’ remote connections up and running

From our conversations with internal Network Administrators that control our VPN services, we analyzed the objectives, and critical task Network Operators may have while working on VPN.

“As an IT Admin, my interest is to maintain connections up and running. To do that, I need to detect customer problems even before they realize an issue exists.”
— Network Operator

How others solved the same issues

The main issues across the industry are the complexity of the visualization - lack of detailed information, details placement, scaling limitations, and graph clustering.

In the networking industry, some solutions provide a way to visualize VPN. However, as the VPN connections increase by the thousands, I observed that for these solutions to give an easy way to display the relevant information is challenging.

Information about other VPN monitoring tools and their value propositions.

The opportunity

As I met with Network Operators about their day-to-day activities and talked with stakeholders about our VPN technology, It was clear that users were interested not only in the VPN connectivity but also in other properties like edges, nodes, and topology to be able to troubleshoot VPNs.

The information gathered was beyond the Product Manager's story requirements.

Reframing the Problem

Presenting the findings and bringing Product Manager on-board

I decided to present to PM two scenarios, one with the PM requirements - showing VPN satus - where users will have to go to the device and find what the problem is, and other where users will have access to all the VPN information in a tooltip to point out where the VPN problem is - mockup above.

Although there were concerns about the implementation time, The Product Manager realized how powerful the VPN feature could become if we provided users with the VPN information needed to troubleshoot.

Wireframe created to give context to the Product Manager and Stakeholders about how to improve the VPN experience and as a method to guide the conversations and align with them in the direction we wanted to take.

The story requirement went from “provide current VPN tunnels status” to:

Help Network Operators detect and support VPN connectivity problems to alleviate customer pains

Principles - What was our intent

Clarity about the state of the VPN environment

Network Operators should quickly detect the elements in the VPN environment that need their attention and understand the status at a high level.

Association of VPN data to help understand issues

Network Operators should be able to support their decisions on the why of any issues by looking at different VPN properties and identifying the cause.

Design Refinement

The most critical information for Network Operators is the VPN status

During the iteration process with Network Operators, Product Manager, and VPN stakeholders, it was clear that for users, the VPN status was the information that they wanted to look at first. This input changed the position of the VPN monitoring widget through the proposals.

We tested initial iterations with Network Operators of the VPN monitoring pages displaying information about the state of multiple VPN properties.

Network Operators’ VPN journey

The outcome

IPSec VPN Monitoring

With VPN Monitoring Network Operators can now view the IPsec VPN tunnel status directly into the application without the need to analyze the logs from a security device

Overview of current VPN tunnels up or down, the causes, and historical VPN status

Tunnel statistics in tabular format across VPNs to find problems correlation

High-level information about the devices and links inside the network to be able to find any cause of a VPN problem quicker

View the state of device interfaces for the VPNs created

Project constraints

Limitations with the components of our design system and engineering front-end resources.

At the company, we own the design system that allows us to assemble reusable components. However, sometimes this creates certain constraints and is not flexible enough to provide the best design solution for our users.

Working with the PM and engineers, we decided to create new design components to solve the users' problem, yet, we would have to wait for engineering front-end resources to be available to implement the proposal.

Considering resources and the feasibility of the proposal by talking to engineers

Even though there were concerns from TPM and engineers about the number of sprints the design would require, they saw the value that would bring to the product and agreed to discuss how to incorporate it into our sprint cycle.

The implementation

Once the engineering team scoped the proposal, they compromised to implement it in multiple phases:
Phase 1. Overview and detail analysis pages for configured VPNs.
‍Phase 2. It will provide network information (topology details) about where those VPNs are configured. There was a dependency on the design system's team to turn the topology feature into a component.

Final Thoughts

Help teams that are in deep production mode to stop, look at the big picture, measure the most significant possibilities and risks for the team and the potential of a product, and estimate if it is a good idea to go into the development cycle.

You can turn that "less shiny project" into something your company needs to focus on.