Private Cloud without a Learning Curve (2009-2015)

I led UX design and research for SmartCloud Entry from its earliest days through its last standalone release. Throughout its evolution, the design was driven by customer research and the goal of powerful simplicity.

Contributions: UX Leadership, UX Design, UX Research

IT administrators are busy professionals that keep websites and other IT services running. They have a wide variety of responsibilities and automated, repeatable processes make their work much more manageable. One time-consuming task they have is manually building virtual machines (VMs) for development teams. Often, this is done each time one is requested because small tweaks are required. IT administrators can avoid this by giving developers access to tools such as VMWare or XenServer, but that has tradeoffs. As one customer told me, giving developers access saved time building images, but increased time spent managing capacity, troubleshooting and dealing with "server sprawl" (forgotten VMs no longer being used). He loved the product concept when he saw it.

The concept was to enable developers to create VMs on demand, while giving administrators policies to manage capacity and configuration settings. Developers could get VMs without the wait and without making difficult configuration settings. Administrators could set limits on settings developers could make to automate many aspects of management.

Users and Usage

Companies that wanted a private cloud typically wanted it for software test and development. When software is in production, it is typically managed by a different set of processes. Most feedback came from a Customer Advisory Panel of current customers made up of 9 cloud administrators that I met about 10 times per year. There were also 3 internal development teams using SmartCloud Entry for software development (about 300 users) who participated in a yearly survey and were a rich source of data. In most installations, there would be one or two administrators and 10s or 100s of developers.

Early feedback indicated that usage would be regular but infrequent. This meant that it had to usable with minimal learning. Later surveys quantified usage.

• Developers: Typically had 2 instances (workloads) running for about a week. After this, they replaced their instances with an updated build. They spent about 5-10 minutes every week in the product.
• Administrators: Used the product a few hours a week. Typically, this was when new VMs or other infrastructure needed to be created, to troubleshoot.

Personas

I created a persona for each user role based on interviews and surveys.

Maureen (Developer)

• Need: Simple way to update a VM and get back to development.
• Design goal: Simple deployment with minimal learning curve.

Michael (Cloud admin)

• Need: Automate management to minimize time spent managing capacity and manually building images.
• Design goal: Simple policies to let administrators manage capacity:
• Expiration policies to avoid "server sprawl" (forgotten VMs).
• Approval policies to allow administrators to tweak developer configurations as needed.