Terminus Case Study
Users
The Department of Defense attracts users from all over the country with different levels of education, tech adoption rates, and views of the world. CodeMettle learned that minimally trained users are currently setting up highly technical equipment for IT management hubs in tactical environments.
Problem
The problem is that many of these users do not have the training and context to complete the task of setting up and managing constrained networking environments. The equipment sent to missions requires specific reconfiguration, reinstallation, and specific security protocols that is currently detailed in hand written manuals…(woah). Once the daunting task of setup is complete, users need operational connectivity with their neighbors, a higher authority to carry out a successful mission, and help with maintenance and operational task completion at the edge.
Solution
CodeMettle sought to create Terminus, an IT node management system, that allows minimally trained users on the ground to quickly pop up a custom private networking environment through guided setup and automation. Once set up, users would have access to an entire connected ecosystem, driving their mission and status, like their current network map, inbox and activities, dashboards and maintenance, chat, reporting, troubleshooting, and configuration management. The goal of the web app is meant to give the user the power of networking, without having to do the heavy lifting.
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, timelines, and feature priorities.
Questions we ask when working as a team: What do we know? What is the current state? What are the jobs, roles, technologies, and goals? What are our assumptions? What are our timelines? What are our blockers?
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. We iterated on personas through fieldwork studies and interviewing.
Minimally Trained Operational User: Moves positions often, high school educated, not specially trained in networking by the D.O.D. but performs 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
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.
Dual Track: 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 setup 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, and 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.
Usability Testing and Iterations
Throughout the process of research, ideation, conversation and learning, and 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
The desire for ease of use and even more 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 the automated system but wanted consistency that the steps were correct from a user and data perspective.
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.