A Consumer-grade Experience for Cloud Orchestration
Senior Designer 2015 - 18
As the only designer, I worked with the dev team, product managers and QA to lead the design of CALM (Cloud Application Lifecycle Management). I was deeply engaged with the different stakeholders in understanding the problem statements and intentions of CALM, research in the context, redefining the design brief from ground-up, the architecture of the new CALM down to the last detail in visual design to working with the dev team towards the highest quality in execution detail.
The design of CALM.io (Cloud Application Lifecycle Management) was one of the most frustrating, immersive and meditative experiences for me. Frustrating because virtual computing is an industry filled with opinions, jargons, acronyms and multiple references for the same thing. Immersive because I had very little idea and it was a sea of information for me to take a swim in and make sense of, for myself and, meditative because diving into the complexity brought me to a point where I arrived at a simple understanding of it eventually.
Problem statement
The DevOps team or personnels in an IT organisation are the ones who take care of the infrastructure setup and maintenance. This is a high-responsibility role for any software-based business, needless to say, and the job not easy. The key functions of a DevOps professional are:
1. Setup of the virtual infrastructure on the cloud of choice
2. Monitoring and maintenance of the infrastructure, with frequent operations that need to be performed for varied purposes.
For the above broadly 2 scenarios, there needed to be created a drawing space for the blueprint of the infrastructure and then, a console which allowed for the viewing of the virtual machines which were essentially my application. This gave rise to the metaphors of the blueprint canvas and the deployment console.
Issues identified
When I joined the team, v1 of CALM was already running as a POC with a few clients. The v1 had a few fundamental issues:
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
Solution part 1
Simplification of the product offerings
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. 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.
Solution part 2
Employment of metaphors
For the two environments, two metaphors revealed themselves during the visual thinking for the environments. 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.
A visualisation for the space and a blueprint canvas in which virtual infrastructure resides and is created respectively.
Solution part 3
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 4
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.
Dependency between services, shown on canvas
Services with tasks lists and a task flow defined between them, on the blueprint canvas
Solution part 5
Identification & Creation of Layers in the blueprint definition
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
Services
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
Functions
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 configurations. Application profiles give DevOps the flexibility to keep this options open while running the blueprint.
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

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
Style & Pattern Reference for CALM
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.