Our classic product’s “network map” attempted to provide a high level network overview, but suffered from multiple cognitive and execution gulfs. While providing layout and status information, the page was an operational flow dead end - requiring the user to navigate away, sometimes deeply, to update configuration or investigate issues.
We aimed to create a new landing page for network engineer’s seeking to manage any aspect of their configuration. In addition to feature parity, additional capabilities would be added that brought critical status and configuration details to the user.
The following is a working draft, explaining this project. Language will be cleaned up and additional details will be expanded on soon.
I served as the principal designer, leading and coordinating all facets of the redesign from start to finish, including: project scoping, requirements gathering, technology analysis, task flows, prototyping, and development. I also conducted user research using methods such as interviews, surveys, focus groups, and participatory design in order to address both user behavior and attitudes.
As the principal designer it was my responsibility to provide the initial wireframes and broad-stroke composition of the design. These patterns were to be the first step in rationalizing the feasibility of a planned total redesign of the product’s graphical user interface. I then led junior designers and developers through the process of designing the final design elements and task flows.
The classic product's network map suffered from multiple issues:
- Servers were sorted alphanumerically, with no other options. Early guidence from SMEs demonstrated that server status was of primary importance.
- Sort was down on columns, forcing users to scroll vertically down to follow the logical sort order, and then return to the top to continue.
- No filtering options were provided to reduce visual clutter.
- No sorting on status, resulting in critical issues hidden.
- The page was a dead end, where any action required navigating away. This forced the user to externalize a great deal of information.
- Details were located elsewhere, as were statistics - preventing discoverability of data insights.
- Visuals were dated, but we couldn't change things too drastically within the existing product.
- Configuration sizes caused the page to crash (we needed technology updates).
We worked closely with a group of Enterprise Network Engineers (ENEs) - F5 Networks employees who install, organize, and support customer networks - acting as SMEs, functional users of the existing map, and target users for the redesign. ENEs were interviewed regarding typical use cases. Scenario where then constructed and observations were conducted with recordings. This allowed us analyze the material after the event and demonstrate specific pain points to stakeholders.
Multiple brainstorms were held to ideate multiple different modern visualizations. An extesive Network Map Design Consideration document was created in Confluence, to provide a central collaboration point on design efforts. This document highlighted several important design artifacts:
- The problems we saught to overcome;
- Typical network topologies that would loaded into the network map;
- Feature capability mapping;
- 3rd-party library options with thier technical and functional pros and cons;
Quick prototype and testing iterations allowed us to quickly discover that the compact nature of the classic network map provided a much greater benefit to the users. In other words - our new designs didn’t help and staying with a design more closely aligned with the existing system was to the user’s benefit.
In parallel with the task-based redesign of the visuals, a technology review was conducted.
The ability to “flip” a card was added. This brought a few information to the user instead of making users go get it. This improved the ability of users to diagnose issues in-place!
The “Inspector” was also introduced. A well known pattern in multiple other products, the idea of a left-side details panel was not prevalent in the classic BIG-IP product; the only exception being the Advanced Firewall Management, where I had also introduced the pattern with a slightly different goal.
The Inspector's goal was simple -- bring the data to the user.
The classic design forced the user down into multiple property pages to build the complete picture of a virtual server (today, regularly called an "app"). This forced the user to internalize a great deal of information as they built a piece of the picture from each page. Adding further complexity, pages were not interconnected -- forcing the user into an excessive navigational process.
Adding the Inspector brought detailed information of the complete virtual server chain into a single space; it provided editing capabilities without leaving the current visual; and maintained the current memory stores by leaving the primary visuals in place.
Internal Enterprise Network Engineers and System Engineers were used as test participants. These individuals where all very familiar with the product and delt regulary with the Network Map regularly, especially when helping customers debug network issues. Testing was conducted prior to and throughout the prototyping efforts.
Ten functional use cases were created and a baseline set of metrics were critically evaluated as a group.
We demonstrated to module owners that the Network Map was a viable landing page, versus the previous static links page. This allowed other design teams to begin to investigate integration with the existing map, or borrow design elements to create similar experiences. The introduction of the Inspector demonstrated that light weight configuration could drastically improve the user experience, without losing advanced functionality.
Our team was quickly approached by multiple groups seeking to introduce similar concepts, utilizing both the technologies and usability patterns we demonstrated!