Kentik Trial Onboarding Case Study

Gallery Block

These are example images. Double-click here to replace these images with your own content. Learn more

Users

Kentik’s main user base tends to focus around network engineers, security engineers, backbone engineers, etc. For this project, we utilized Salesforce ‘title’ integration with Pendo to track and segment who was landing in global trial. We found two different personas- one was our typical subject matter expert, and the other was a buyer persona. These users were project managers, CTOs, and Heads of IT.

Problem

The problem is that our current onboarding is very long, taxing, and the backend data collected shows that users are not completing basic tasks before drop-off. Kentik has a robust sales and solutions engineering team that could reach out and help users set up their complex system, yet connection is rarely made. Different types of users are coming to Kentik with differing levels of understanding and need context in building their system for user satisfaction and to help alleviate internal pains throughout Kentik. Users expect ease of use based on website content, then hit a wall of complexity.

Solution

The solution for product onboarding is to increase collaboration among teams. We changed the context on the website to change user expectation and built a roadmap for product onboarding based on our internal and external journey map. As many users do not come to Kentik for every product area, we beginning with drop in trials based omni-channel marketing efforts, beginning with Synthetics.

For the global trail experience, next year, we will clean up the flow, create in product connection to internal teams, and allow users to curate their experience based on product interest.

Role and Team

Our product team is organized as an empowered product team. Since the product launch, I have been working as the lead product designer, working in strategy, research, and design. I work alongside a product owner, many developers, subject matter experts, an additional researcher (as needed), and additional designers (as needed). We currently meet daily and throughout the week to remain on the same page and pivot based on constraints, timeline, and feature priorities.

Questions we ask when working as a team: What do we know? What don’t we know? What are our assumptions? What are our timelines? Who do we need? What are our blockers? How are we doing?

Research

Persona creation: Personas are representations of a cluster of users with similar behaviors, goals, and motivations. As such, personas are fictional, yet realistic because they embody the characteristics and behaviors of real people; they should be built on insights from several people and eventually tested for validity.

In creating our personas, our assumptions came from leadership and SME knowledge. Based on our assumptions, we conducted internal and external testing to validate and create our two personas for Terminus
Minimally Trained Operational User: Moves positions often, high school educated, not specially trained in networking by the D.O.D but preforms mission-based management activities and setup. Motivated to ‘keep the lights green’ and provided minimal context.
Technically Trained Admin User: User with multiple years of networking experience and course educated within the D.O.D (i.e. signal flow certification and mission management). Admin often supports lower level users, reviews reports, can assist in mission planning. This user is focused on keeping larger networks up and active.

We incorporated Heuristic Analysis and Competitive Analysis in throughout discovery and ideation.

We focused on products that were functioning in our space and reduced the cognitive load on users.
Main Competitors: Datadog, Elastic, Honeycomb, IBM Spectrum, IQ Core, Palantir, Solarwinds

Hierarchy and Navigation

When crafting Terminus, it was important for all parties to understand the hierarchy and how different parts of the system would interact with one another.

For example, devices have the ability to roll up under larger group dashboards and reporting mechanisms. Users will be able to view large amounts of working data, while at the same time, being able to drill down into troublesome areas to resolve issues.

Epics, User Stories, and Task Flows

From initial ideation, we approached decision-making from a user-centered perspective, focusing on the Operator’s motivations and desires when completing a task. This led to compiling observational research and interviews to create realistic epics, user stories, and task flows. Below is an iterative example from a Network Map session.

Outcomes and desires from external interviews.
Research and motivations heavily impacted the design, logic, feature connectivity, and a network map mirroring function for Terminus.

Guided Setup vs. Automated

For beta, we arrived at two different paths for network setup. First, guided tutorial driven setup, which walks the users through a set up process of adding and configuring any device that may have been shipped to them, bucketed into three functional categories- Satcom, Baseband, Line of Sight.

For the user who may not know their SSH credentials, who is prone to fat fingering, or who may be multi-tasking, we approached Terminus from a templated automated perspective to reduce cognitive load. This way, the higher level admins can fill out our template and set their specific desired thresholds/parameters for the entire node and the user can just import the document and Terminus will configure the rest. Terminus can ping, discover, and locate devices in their area, connect to neighbors, and spin up services.

Dashboards and Connectivity

Methodology

Each system, each mission is unique and we wanted to bring consistency and rhythm for users (and metrics for reporting). Although different devices send and pull different/helpful information, we bucketed these into ‘Health’ and ‘Performance’ data for dashboard consistency. For example: if the CPU for your Switch ( ‘Health’ bucket) hits a certain threshold on your system that is above the parameter set by the admin, then an error would flag in the events inbox, which would also show up on your system map for that specific device. The system would suggest an activity to resolve before the CPU continues to grow.

We gave Terminus specific chart types that could grow with larger systems to display dynamic network data to higher users and to also teach lower level users how to easily digest complex data.

If a threshold has exceeded within an object, the user can instantly click on their map, view the specific error at a glance, and troubleshoot to resolve.
In this situation, the user can see that Server-4114 has a power spike and can select to run commands in the device.
Chat, Help, and Activity Comments are all available to assist the user throughout their daily processes to remain self-sufficient and proactive.

The Activity Board helps users track different types of tasks that need to be carried out through a mission and to maintain the node. Users can add relevant tasks, view suggested, and the Admin can have tasks directly populate to the board for users to carry out.
Fulcrum, the Admin parent product paired with Terminus, can track activities sent to node users, suggest relevant activities based on reporting metrics and priorities, and will automatically push relevant activities to the node based on historical data.

User exports Daily Node Report to Admin and converts to additional formats

Usability testing and Iterations

Throughout the process of research, ideation, conversation and learning, understanding stories and flows, we began to create concepts and then tested our concepts. We did rough, quick sessions with internal users and subject matter experts to gauge ideas, content, architecture, and layout.

After each major feature release, we tried to block out a week of external usability testing to see how real users digested our concepts and wireframes. Throughout the process we conducted moderated and unmoderated testing through Zoom and Playbook UX.

Key Takeaways

gENERAL USABILITY AND DESIRE FOR A DECREASE IN COMPLEXITY.
- Setting up networks is difficult and we needed to find ways to remove that stigma and create a connective product that was fluid and easy to navigate. A pivot point was adding more suggestions, adding more/relevant helper text, intro videos, more detailed navigation, etc.
- Delighter Goal: Create a chat system that users never want to leave. The system needed to be more than work for our soldiers.
Users liked the validation from automated setup and needed to know when they had it right
- No one likes to be left in the dark, especially in a tense situation. Let’s help them feel safe and stay on the right track. Building trust is key.
oUR HIGHER LEVEL USERS WANTED THE FREEDOM TO CUSTOMIZE THEIR PARAMETERS AND HOW THE REPORTS WOULD BE GENERATED
- Based on this user group, we built in flexibility to their permissions and reporting processes so they can configure multiple nodes and settings to run missions as they see fit.

Summary

Terminus is meant to be a living and growing product that evolves with the size of the unit and meets the soldiers at the tactile edge. A main goal is to bridge the tech gap and help soldiers “adopt” skills through Terminus and give users the power of network IT management. Through features like configuration management, automation and intelligent data management, chat, network topology, reporting, and events/activities, users can safely pop up a network and navigate a critical mission with ease.