The Modular BIG-IP program ultimately changes the way F5 ships product, allowing F5 to accelerate app service adoption by making app services faster and easier for customers to achieve time-to-value. In cloud, virtual, hardware and agile environments, Modular BIG-IP allows customers to consume F5 services more flexibly to achieve optimal TCO while delivering robust control plane scale and higher product quality.
I am the Principal Usability Architect for the Modular BIG-IP project, working across multiple groups, leading all facets of the user centered design process, including: project scoping, requirements gathering, information architecture, user task flows, interaction flows, prototyping, and development. I also conduct user research using methods such as interviews, surveys, focus groups, and participatory design in order to address both user behavior and attitudes. I consult regularly with developers to focus around GUI, API, CLI, and hardware usability, supporting their efforts with user centered design practices and user testing.
As the principal designer of the GUI it is my responsibility to provide the initial wireframes and broad-stroke composition of the design. These patterns are passed off to junior designers who, with the use of Fleet, apply additional details when needed. I am responsible for the final approval of all design elements.
The “classic” BIG-IP was architected over 20-years ago and has grown organically since. With little to no gatekeeping, each module’s experience has been allowed to branch away from core towards developer convenience and away from a focus of the user.
Multiple APIs site on top, and are structured based from, the CLI.
The 15-year old look-and-feel has held up very well, but is showing its age. The organic growth of the product is most apparent within the GUI, where module teams lack any guardrails or restrictions to reinventing work flows multiple times.
Our set of personas suffered from being over a decade old and underutilized by all stakeholders, including UX. We made it an initial priority to re-discover and refresh our target personas.
The core tenant to the Modular BIG-IP UI set is: API first. By taking the API seriously, not an afterthought, we make it the core experience of the product’s legacy.
Throughout the API design process we assessed the usability of the Modular BIG-IP API, from the DevOps perspective, to validate the architecture and identify any areas for adjustment. The studies utilized a paper API where participants constructed calls using index cards representing endpoints. Usability was measured via the number yellow cards received for incorrect calls made and through post-task and post-test surveys.
The results of the API usability studies are intended to serve as a guide for future API development. Our intention is for the owners of the API to use these reports to understand where user pain points occur, and why they occur, in order to make an informed decision about if and how adjustments to terminology and structure should be made.
The goal of the Modular BIG-IP CLI is targeted primarily for human readability and usability before machines. Input and output is designed to be consistent across commands to allow the user to easily learn how to interact with new commands, delight the user, while at the same time supporting advanced users and output formats. This article provides a clear direction for designing delightful CLI plugins.
A grammar based around Heroku was designed:
f5cli [topic]:[command] --flag. This structure allowed us to create an easy to learn, efficient to use structure; with a familiar, structured, easy to understand and type language; that is ultimately memorable.
For each use case a flowchart demonstrating the desired command-line was created. Each flowchart allowed us to talk through the structure and spot potential issues. These maps were referred to each time we consider adding additional functionality to the CLI.
CLI wireframes to communicate grammar and interactions: cli.sketch
Our first objective was to clarify the information architecture for the new GUI. The “classic” IA was based off the system object schema; menu items were added by development teams based on system needs, instead of user task flows. Inter-module object relationships were expressed through the menu structure, resulting in the same object page being representing at multiple points.
We ran a series of card sorts to better understand how users would arrange and classify the BIG-IP user-facing terminology, conducting the card sort on twelve recruited subjects who were chosen for their match to the target personas, Olivia and David. Each participant provided us unique perspectives on how our personas might approach the system.
With the open card sort data collected, we conducted design sessions to develop the Modular BIG-IP information architecture. We then ran a series of closed cart sort sessions to validate the proposed design. The ultimate objective of the data collected was to information our IA that will provide success for each approach.
Accelerating into the third revision of Fleet, now fully internally productized, we began to define the primary patterns that are used across the GUI.
Check out more wireframe examples: mBIP Workflow Examples.sketch
The Modular BIG-IP effort is ongoing. Our API, CLI, GUI IA and work flows continue to grow and evolve as more use cases are defined and designed.