A Consumer-grade Experience for Cloud Orchestration
Senior Designer •2015 - 18
Setting up the cloud for an enterprise, and managing it at-scale is cumbersome for DevOps personnels. 
I redesigned CALM by simplifying the product offerings, creating a conceptual model and visual design down to the last detail.
CALM got acquired by Nutanix soon after the redesign
My Role
•User research/interviews
•Secondary research
•Low-fidelity wireframes
•Sketch for high-fidelity mockups
•Design critiques with the team
•Testing prototypes and product with users
•Engineering handoff (via Zeplin) & deployment
•Quality Assurance
Simplification of the product definition
I was deeply engaged with the different stakeholders in understanding the problem statements and intentions of CALM. I tested v1 with the existing customers of CALM as well as expert DevOps in the industry, and feedback from them became instrumental in shaping the next version of CALM.
Clarity from Testing, Interviews & Feedback
One of the critical inference derived from these user testing sessions and conversations was that there was a confusion for the users about the mode they were currently in - specifically, whether they were editing a blueprint or they were monitoring their infrastructure. This was an invaluable insight which pushed me to clearly bifurcate and label/name CALM's product offering into 2 discrete pieces or environments for the DevOps:
1. The Blueprint Designer: This would be the environment wherein the blueprints would be defined
2. The Deployment Console: This would be the environment (glass pane) where the deployed infrastructure could be monitored.
A visualisation for the space and a blueprint canvas in which virtual infrastructure resides and is created respectively.

Employment of metaphors
For the two environments, two metaphors revealed themselves for visualisations. The blueprint designer adopted the blueprint sheet as the infinite canvas on which the infrastructure could be 'sketched'. The sky was the obvious answer to the question 'Where is the cloud?', and hence space became the container of the virtual infrastructure.
Creation of a Conceptual Model
When I joined the team, v1 of CALM was already running as a POC with a few clients. I begun my journey of the design of CALM through research with the help of the core team, clients and DevOps personnels who I connected with via DevOps Meetups groups. My intention behind this research was to understand the mental models of the DevOps users, which would then result in a conceptual model for CALM.
The basis
Conceptual model: Blueprint in layers
Through testing of v1 and several sessions of brainstorming with the product managers, what emerged as the general method/process to define an application blueprint was to specify it in 3 layers. The entire process of this transformation is explained below.
The 3 layers in which an application was identified to be created were:
1. Services
2. Functions
3. Application Profiles
Layer 1
A service is the first element to be defined for a blueprint. Defining the service type would also make appear the icon of the service type. 
An empty service has a generic service icon too.
Layer 2
Creating a function creates an empty task list to be populated with tasks, which can then be connected across services.
Layer 3
Application Profiles
The same services' architecture could be deployed across multiple clouds and in different possible deployment configurations. Application profiles give DevOps the flexibility to keep this options open while running the blueprint.
The Devil in the Details
Although the conceptual model created a well-defined method for the creation of a blueprint, there were many visual design issues which I also deduced in the process of testing the interface at multiple stages of its evolution. What ended up getting created through the process was a representation system for a cloud based infrastructure.
1. The exact same visual environment was being used for blueprint creation as well as deployed infrastructure monitoring
2. Machine definitions and the operations tasks lists were merged visually, so the visual element on the blueprint canvas wasn't resolved
3. Machine dependencies and service task flows (operations) were illustrated using arrows styled identically
4. Substrate and Service definition and relationship not clear
5. Fatigue for the user in the interface, due to the controls for objects on canvas being docked away in a corner
I solved each one of these problems, keeping with the mental models of the users.
Solution part 1
Visual resolution to the blueprint designer
One of the key problems on the canvas was with the service definition. When I tested the interface with customers and other DevOps personnel, it came to light that they were unable to model easily, the object they were working with, on the canvas. It was unclear to them what the object was - a service, tasks list or a VM. This did not come as a surprise to me, since in fact these 3 pieces of information had been bundled up together on the canvas. Below, I've illustrated how I solved this:
a (left) shows the initial state of the virtual machine design. It was simply a mechanical combination of the virtual machine name and the tasks list. For the user, this caused there to be the lack of the formation of a clear mental model about the object in question.
b (right) shows the identified problem. That there were 3 information pieces to be communicated on the blueprint canvas: 
The VM (substrate), Service (Name, Type) and a Service task list
c (left)shows the further resolution of the problem in 2 steps:
1. Separating the Service from the service tasks, and,
2. Adding the substrate indication on the service.
Solution part 2
Dependencies vs Flows
A blueprint definition in CALM laid out the [1] dependencies between machines and, [2] the task flows between and across them. For both of these, v1 employed identical 'arrow' element, which emerged to be confusing, when the v1 interface was tested with users. Additionally, another problem that surfaced prominently was the confusion that the amalgamation of the service definition and the operation tasks had created. To solve the above 2 issues:
(left) The first level of connection is service-to-service, and this was assigned to a straight-line arrow. The straight line was chosen also in contrast to the 'flow' aspect of the taskflow arrow (next).
(right) The taskflows that would be created on the service were assigned to curved arrows that signified clearly what they were meat to - a flow. This was a flow from one task to the next.
(left) Apart from the form of the arrow employed, the colors of the arrows were also assigned to be: Orange, for the flow and, White for dependencies.
Services with tasks lists and a task flow defined between them, on the blueprint canvas
Solution part 3
Floating Controls
One of the other major modifications I made on the canvas was to introduce floating controls for services that were placed on the canvas. As opposed to in the previous version of CALM in which these operations were fixed in a toolbar, the most commonly used controls for (1) creating a dependency, (2) cloning a service definition, (3) managing the settings and, (4) deleting a service, were all brought together in a menu that appeared always above the service box.

Floating controls for the service appear right above the service when it is selected

Floating controls for a function task-flow appear at the centre of the flow arrow when either the service or the flow arrow is selected

Solution part 4
Layering of the substrate and service
Even within the service and substrate definition, the sense that had to be conveyed visually was that the service is running 'on' a substrate. This layering was visually represented as shown below.
Array of Machines
One of the key features of the cloud is scalability. This manifests technically in the form of an 'array' of machines, which is basically the same instance of a VM, duplicated, for a variety of purposes.
To represent an array, I created a variant, which is illustrated below.
Underlying approach
A tactility to the design
In the spirit of making it a consumer-grade experience, my intention with the design of the interface was to give the users a sense of tactility to the environment they were working in. In the blueprint canvas, the sense of tactility was provided by the skeuomorphic representation of the services (virtual machines). The user feels like he is moving around actual objects (virtual machines).
The blueprint canvas interface showing services added with dependencies and configuration of the selected service. On the bottom left is the layers panel which shows the Services, Functions and Application profiles.
A glass-pane to view the cloud's life through
With the sky as the metaphor, the Deployment Console shows the virtual machines to be 'breathing' alive or struggling if there would be an issue that might need attention. The console also contains all the operations defined in the designer. if an operation is currently running, the progress of the tasks can be seen in the inspector window.
A snapshot of the application console which shows the progress of a running app
Apart from the view which displayed virtual machines in a grid arrangement, the infra could also be viewed in its topological definition, right as it has been defined in the blueprint. The advantage of this view is that the operation defined can be seen more clearly, in context of the machine(s) on which it is currently running, along with the progress indication.
The topology of the function with the RUN of the function in progress
Below is the range of icons developed for different purposes
Detailing & Unification
Design System
In partnership with the visual designer on team CALM, I created a comprehensive and detailed style and pattern reference to communicate the elements of construction of the CALM interface to the development team.
The framework for the interface
An interface framework was also defined to keep clarity of communication over the nomenclature with the developers and managers of the project. Shown below are some aspects of this framework.