Translating server hierarchy to information hierarchy

Methods: Whiteboarding, diagraming, internal discussions, competitive research

Before working on the UI, my first task is to determine the information architecture that will be used for the dashboard. While it was relatively simple to identify the top-level navigation, it was much more difficult mapping out how server orchestration is structured, and ultimately, represented on the dashboard.

To understand how servers, server groups, and containers work, I conducted research by reading existing technical documentation on Docker Swarm, discussing how the technology will be used in our product, and creating an information architecture diagram to organize what I had learned.

The benefit of creating an information architecture diagram was threefold:

1. It confirmed the items that should go on a the top-level navigation

2. It illustrated the relationship between the different parts of a server group, informing how servers and server groups will be represented on the UI

3. It provided an “inventory” of the pages and components that need to be designed.

Turning CLI-based tasks to GUI-based tasks

Methods: competitive research, wireframing, prototyping, UX and UI design

Typically, a workflow that relied on a command line interface (CLI) and additional tools is used to provision servers, server groups, and containers. These workflows required a working knowledge of DevOps and infrastructure engineering, which many of our target users do not have.

A GUI dashboard provides additional value that a CLI-based workflow cannot, such as:

• Allowing developers to easily see and troubleshoot the status of their infrastructure

• Reduce distraction and cognitive load when performing key tasks (for example, when adding services to a server group)

• Reducing the barrier of entry for developers who are less knowledgeable about DevOps.

Supported by competitive research, technical alignment, and the previously completed information architecture, the design strategy was:

1. Isolate the most complicated tasks, break down the steps and use the resulting patterns to support the design of simpler tasks by removing complexity.

2. Make sure of the visual space on the screen to accurately depict the concepts of servers, server groups, and containers.

3. Introduce more negative space to reduce cognitive load.

The result was a user experience that allowed developers to get progressively more specific the deeper they delve into the server group’s configurations. By using visual “clusters” and wayfinding components such as steppers and additional tabs, developers were able to navigate between server groups and configurations, while also able to focus on specific tasks.

Monitoring VM and container metrics

Methods: UI design, data visualization, information architecture

An important part of managing infrastructure is being able to monitor the status and performance of your virtual machines and containers. To do that, MedStack Control featured a Monitoring section where developers are able to see an overview and detailed views of all related metrics.

The information hierarchy was tricky as each individual server and container had its own set of metrics, yet each server and container belonged to a different “parent group” - Virtual Machines or Docker Swarms. In addition, each server and container belonged to different server groups or hosts, and the relationship needed to be present on the UI. Thankfully, the structure that was introduced in the “Configure” section of the product was able to provide the scaffolding to represent the multilayered structure.

In terms of data visualization, there are three main types of visualizations:

• Logs - Used to represent status over time

• Line graphs - Used to represent remaining space over time (i.e server storage, memory storage)

• Bar graphs - Used to represent space used over time (i.e. CPU)

Challenges & Learnings

As this was my first major design project, there were many challenges and limitations I encountered. These included:

• Changing scope and short timelines - The business needed some sort of live prototype to demonstrate this product to key stakeholders within two months of me starting this project

• Lack of expertise - I lacked DevOps knowledge, and the development team lacked front-end expertise. As such, it took us extra time to learn the best practices and information we needed to deliver the product.

If I were to do this project again, I would improve the following:

1. Conduct user research - We simply didn’t do it and we need to in order to validate assumptions. 

2. Track assumptions from all sources - Team members from all business operations were impacting decisions and there was no organized way to acknowledge, track, and test them. 

3. Validate product decisions with evaluative testing - Our own engineers tried dogfooding, but we are not our users. 

4. Accessibility - At the time, I had very little knowledge of accessible design and have since learned that there are many problems with the designs shown here.