Defining goals:
Delays in manufacturing caused by supply chain disruptions, and pauses in USAID and USTDA funding means that this project hasn't been fully rolled out yet. However, internal testing shows strong results, and I plan to more thoroughly test for the aforementioned metrics when we do fully launch.
Impact:
While the network management system (NMS) is the most visible face of the software solution, it’s only one piece of the puzzle. Therefore, I stepped back early in the process to research both specific NMS requirements, as well as the wider company ecosystem. I noticed our initial solution tiers didn't provide enough clarity and distinct value. So, I workshopped with leadership to look at our CRM pipeline (which was all over the place, from the rocky mountains of Colorado, to the healthcare clinics in DRC), and create new product tiers that captured the essence of our three main markets. This helped define scope of the NMS more clearly, and reframe our focus to lock in product market fit as soon as possible.
Because our initial pool of customers was small, I conducted 10 user interviews with key stakeholders, and adjacent experts, to both understand the problem space, what they needed, and how they felt about existing solutions. Something particularly interesting that stood out to me was the current network management method one entrepreneur in the DRC had devised: pinging his network every five minutes to make sure it responded, and was still up.
This really helped clarify the core issue from the users' perspective. I was going a bit crazy looking at all of the different network KPIs that needed to be monitored, and had almost forgotten that at the end of the day, for users without quality connectivity solutions, making sure the network is still running is paramount.
Here are some of the summarized insights:
To design an effective solution, I needed to understand the underlying business model that was hypothesized to support self-sustaining networks, and where the NMS fits in. In an ideal world, our partners can set and forget their networks, and never have to look at the NMS, other than for subscriber management. Alas, the reality is that issues will inevitably arise. The NMS plays a critical role in enabling network owners to quickly detect and resolve problems before they impact service. If the network becomes unreliable, paying community members will eventually lose trust and not return.
Consolidated user stories for alignment on user needs.
Anytime I spoke with any of my brilliant teammates, they would speak about network concepts, and all of its components, jumbled together as one large mass. While this worked great for them because they had years of experience in this space, it did not for me. To best build an interface that not only correctly directs users to solve issues, but also builds trust as they're doing so, we needed to build something that spoke the users' language. What better way to do so that with plain, spoken, words?
I theorized that informing the user in the clearest possible way about the state of their network systems would be the fastest and least frustrating way to visibility, especially for users with lower technological literacy. Presenting the resulting network components in clearly sectioned building blocks, and leaving intuitive breadcrumbs that allow users to drill down into more detail if desired, will provide a simple, yet robust, network management system.
When facing tight resource constraints, my approach tried to balance both quality and quantity of insights. I combined structured task-based testing with think-aloud protocols, and tested 3 users per key flow in 3 rounds, based on Jakob Nielsen's research on percentage of insights that can be extracted from number of research participants. While he recommended 5 users across 3 rounds, I had to modify it due to timeline and budget constraints.
This dual methodology revealed not just what users struggled with, but also why, uncovering hidden assumptions, pain points, and motivations.
These calls gave me a lot of new insights into potential future roadmap items, but was wary of potential product bloat that could compromise the user experience, and developmental efficiency. Still, though the numbers said otherwise, I felt we weren't fully meeting users exactly where they were at.
After some group brainstorming, I realized we solve this without deadly product bloat. Building on our existing modular framework, we could introduce custom integrations that allow users to customize their NMS with optional add-ons, offering flexibility without compromising the core experience. The custom integrations tab isn't visible in any of the mockups because our team has been focused on delivering the core experience first.
Some of the core 20% of features that deliver 80% of the value (identified during an earlier research phase) are shown below. These features guide even non-technical users to successfully set up, manage, and troubleshoot their network, which is critical to business success; whether maintaining high NPS or ensuring smooth operations online.
Providing a clear overview of the network "health" for easy monitoring; freeing users to focus on what matters most to them: growing their business. When issues arise, intuitive breadcrumbs lead users through various layers to the root cause, empowering swift, informed, decision-making.
Sites represent the physical building blocks of the network; each composed of the node, controller, solar, battery, backhaul, and switch components. By translating this physical setup to a digital diagram, users gain a clear understanding of how everything connects, making it easy to pinpoint where to look when issues arise.
Nodes are the hardware piece that connects a subscriber's phone to the broader network. While each node contains many complex components, this interface simplifies the experience by organizing the most common sources of issues into logical groups, also allowing users to easily explore graphical insights and track performance trends over time.
I wanted to keep the interface consistent with the rest of the system, but the node's data is more independently jigsawed together, and doesn't fit the same physical representation as the site's data. So I optimized the layout to scan key numbers quickly, with the option to dive deeper.
