Simplified hardware scaling

Project Overview

The purpose of the simplified hardware scaling project was to investigate just how simple the process of adding servers to a customer's private cloud could be. For this project, I was the lead UX designer working with key stakeholders in product management, architecture, and development to get as close to a 'one-button' experience as possible. During the month long project, we were successfully able to reduce the amount of time and effort required to expand a private cloud to just 4 clicks of the user's mouse.

Target Persona

This project targeted our IT administrator user persona Morgan. What sets Morgan apart from our other personas is that Morgan is what we refer to as an 'IT-generalist'. Morgan routinely wears many hats and is responsible for the general care and maintenance of all IT infrastructure at his company. His knowledge is broad, but not particularly deep in any given area and as such prefers 'simple' solutions that do a lot of the heavy lifting for him so that he can focus on keeping the lights on and making sure that everything is working as it should.

Project Kick-off

To start off the project, I first had several conversations with internal stakeholders and performed a quick heuristic evaluation of the product's current experience to get a first impression of the current experience and it's perceived shortfalls. What I found was not simple by any definition of the word.

After my initial investigations, the following problems were identified

Users could not add hardware directly in the product's main application, but instead had to navigate to a second application.
The amount of information being requested from the user to add hardware was excessive and unnecessary
The hardware scaling application had a large number of individual steps to add hardware that made the process seem a lot more complicated than it needed to be

Exploring the Problem

From my conversations with internal stakeholders it was apparent that there was a desire to consolidate the existing hardware scaling applications functionality directly into the main application. This was good as that app already contained a lot of the information that was being requested from the user to add servers to their hybrid cloud. By removing the need to ask for those pieces of information, the required inputs went from 17 down to 7. Further analysis showed that the biggest problem remaining was how to handle the new server's networking information. However, further investigation was needed to determine how we could avoid asking the user for that information.

Breakdown of required inputs and if they would be obtainable automatically to HCC or still require the user to manually provide the values.

Research Round 1 - Understanding the Problem

Before I could begin exploring how to remove the additional inputs from the workflow, I first needed to understand how customers were configuring their private clouds. To accomplish this I decided to leverage some good old-fashioned quantitative research and wrote several Python scripts utilizing a custom Python front-end I had also created for our Redshift support database. This allowed me to quickly and easily analyze customer deployments and find the answers that was searching for.
‍
‍

For this initial round of data mining/analysis I focused on the following questions:

How often do customers add new servers to their hybrid clouds?
How often do customers have to replace faulty servers?
Do customers typically assign servers contiguous IP addresses, and if so does that also apply to servers added after the initial installation?
Do customers name their servers in a consistent and predictable way?

Key Take-Aways

Adding Hardware happens somewhat regularly but not very often, so it needs to be simple as the user will most likely not remember what they did the last time they did it.
The number of servers added at once is most of the time fairly low, meaning that we don't necessarily need to optimize the workflow for adding large number of servers at once.
Customers generally keep the IP addresses of their servers contiguous, but it was obvious that there was some sharing of the IP space with other systems in their environment (such as other HCI deployments) that made it hard to maintain contiguous IP ranges after future expansions.
It was very easy to guess the hostnames of a newly added or replaced servers with near perfect accuracy.
Replaced servers were always configured with the exact same settings/IPs as the removed node.

Exploring the Solution-Space

Now that I was armed with some knowledge about how customers were configuring their HCI systems in the field, I began to start exploring some possible enhancements to HCI to simplify the experience of adding new hardware.

Hostnames

Because of my success in detecting server hostname conventions it seemed like overkill to try and force the user to configure and then save custom setting for hostnaming conventions for their private cloud. This lead to abandoning some preliminary designs that had been created to save this information in the private cloud's management application.

Network Settings / IP Addresses

Unlike hostnames, network settings and IP addressing were a bit more challenging. It was apparent that most clouds were initially deployed with contiguous IP ranges, but about half had introduced gaps in their IP ranges when new hardware was added after the initial deployment. Partnering with stakeholders, we decided to investigate the idea of integrating some very simple IP management (IPAM) capability into the app to allow pre-allocated IP space for future expansions of their cloud. I then prepared some initial designs for the new functionality to present users in a second round of user research.

Research Round 2 - Idea Validation

For the next round of research, I enlisted the help of our team's researcher to develop some interview questions to validate some of the assumptions that had been identified in the design process and to get some clarity on how we might want to proceed.

Key Take-Aways

Nearly all participants interviewed were interested in being able to pre-allocate IP ranges for future expansions of their HCI system and generally thought that it would be a useful functionality to have.
Several of the participants did express that they would be unable to utilize IP range management due to how their organization's networking team allocates IP addresses inside their environment, but even so most expressed that if they would be interested if they worked in a different company.
Participants confirmed that server hostnames would generably always be using the same convention across servers in the same system.

Final Design Concepts

Simplified Hardware Scaling

After another round of design iteration based on the feedback we received from the second round of user research, the workflow for adding a server to our customer's hybrid clouds was created that vastly simplified the process. After this redesign a process that took 2 applications, 9 steps and 25 inputs could now be done directly inside the management application in as little as 4 clicks.

Initial Deployment Changes

To accomplish this simplified hardware functionality, changes had to be made to the initial deployment application to allow the user to specify IP pools for their server networks to accomodate future expansions.

Initial Deployment Changes

In addition, a networking page was also needed to be added to the management application to allow the user to manage their network pools after the initial deployment.