A Consumer-grade Experience for Cloud Orchestration
Product Designer • 2015 - 18
Setting up the cloud for an enterprise, and managing it at-scale can get cumbersome for DevOps personnels. CALM's effort is to provide a visual 'playground' for a topological definition of a blueprint for cloud infrastructure. Further, it must make it easy to know the state of your cloud.
I made a significant difference to CALM by:
1. Simplifying the product offerings
2. Creating a conceptual model from ground-up
3. Detailed and delightful visual design
•Design critiques with the team
•Testing prototypes and product with users
•Engineering handoff (via Zeplin) & deployment
CALM got acquired by Nutanix soon after the redesign with a high praise for the UX and visual design.
GLOSSARY OF TERMS
Service • Also known as an application. This is the bundle of code that is deployed to the cloud.
Substrate• The cloud provider on which the application runs.
Blueprint• A topological map which comprises of relationships between services and the tasks which run on them.
Service tasks• Purposeful tasks defined for running on the infrastructure or specific services for varying purposes.
Dependencies• Relationships between services defined by exchange of data between them.
Application Profile• A profile which decides the cloud on which the application/service will be deployed.
Flow• A set of tasks that can run across services
Diving into the community and the complexity
I started with research in the form of knowledge and perspective gathering from team CALM and industry professionals in understanding the cloud and the problem scope in detail.
Along with research and interviews, I started to test the then existing version. Feedback from DevOps experts in the industry became instrumental in shaping the next version of CALM. It started to move me towards many questions and answers/insights into shaping it better, not just incrementally but from a ground-up approach.
The key/critical insights that I gained from testing were:
Users were confused about the mode they were currently in - specifically, whether they were editing a blueprint or monitoring their infrastructure. The exact same visual environment was being used for blueprint creation and monitoring deployed infrastructure.
Substrate and Service definition and relationships were unclear. This resulted in confusion in the process of blueprint creation.
Service definitions and the functions' task lists were merged visually, so the visual of the service on the blueprint canvas wasn't clear.
Service dependencies and service task flows (operations) were illustrated using arrows styled identically.
There was fatigue for the user in the interface, due to the controls for objects on canvas being docked away in a corner.
Bifurcation of contexts visually
The Blueprint Designer • The environment wherein the blueprints would be defined/drawn
The Deployment Console • The environment (glass pane) wherein the deployed infrastructure could be monitored
Further, to impart visual character, I employed metaphors that inspired the visual design of these environments:
The Blueprint Designer adopted the blueprint sheet/paper as an infinite canvas on which the infrastructure could be 'sketched'.
The Deployment Console begged the eternal question: 'Where is the cloud?'. Amongst many answers, the simplest one was 'sky' or the infinite space, and hence space became the container of the virtual infrastructure.
Resolving service and substrate definition
A key problem that was exposed in the blueprint design context was that the users were unclear about the object they were dealing with, on the blueprint canvas.
At the outset, the canvas allowed the users to define services, tasks that would run on them, and, configuration for the cloud that they could be deployed on. However, these 3 contexts were difficult to navigate for the user visually.
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. This became one of the breakthrough challenges for the design of CALM.
Below, I've illustrated how I solved this:
a The visual of the service on the canvas displayed a name and service tasks. The object was a complex composite of 3 concepts:
3. Service tasks
b To move towards a better visualisation of this object, I began by rough visualisations of the concepts packed inside the initial visual.
c The visual was further resolved in 2 steps:
1. Separating the service from the service tasks, and,
2. Identifying that the service being of primary importance, needs to be the featured object on canvas
Layering of the substrate and service
The last need of the design of the service object was to represent the substrate (cloud) it would be deployed on.
This came to be informed by the fact that the service indeed is deployed 'on' or 'runs on' the cloud. In this sense, the service is the layer on top of the substrate.
This conceptual layering came together to combine and display the layer of the substrate in a peeking window on the bottom-right of the service.
An array of services
One of the key features of the cloud is scalability.
This manifests technically in the form of an 'array' of services, which is basically a service replicated. This could be for a variety of purposes.
To represent an array, I created a variant, which indicated multiples and duplicates.
Resolution of relationships and flows on canvas
A blueprint definition in CALM laid out the  dependencies between machines and,  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:
The first level of connection in a blueprint is the interdependencies between services.
The dependencies between services is a 'direct' one which directed me to employ a straight line for the representation of it.
'Flows' are defined between tasks across services.
They represent the movement of defined actions across services hence a bezier curve fits the mental model easily.
Additional to the contrast created by the straight line and bezier curves, I assigned white to the dependency line and orange to a flow.
White forms the base of the blueprint in combination with the white of the services.
Orange brings focus onto the flow when it is selected, for immediacy.
Introducing a workflow for blueprint creation
Along with the resolution of the design for the service definition and representations for dependencies and flows, a parallel effort was to make the process of creation of a blueprint more intuitive.
A firm understanding of the design of the blueprint in the light of CALM's abilities was that CALM would enable the definition of services, a set of tasks that would run on them and then finally this would be able to be deployed on the cloud of choice.
I brainstormed extensively with the product manager and chief architect of CALM to determine that the blueprint can be defined in 3 stages or 'layers', in the interest of having a persistent representation on the canvas. The 3 layers are:
Layer 1 • Services and Dependencies between them
Layer 2 • Functions (and tasks) that will run on the service
Layer 3 • Application Profiles of cloud providers
The interface matched the mental model of the layers in a blueprint, in the order they could be defined:
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 deployment configurations. Application profiles give DevOps the flexibility to keep this options open while running the blueprint.
In the v1 of CALM, operations that needed to be performed on services or service tasks were docked away in the top left corner of the screen. This caused fatigue for the user as well some dissociation from their context. Namely, these were:
(1) creating a dependency, (2) cloning a service definition, (3) managing the settings and, (4) deleting a service
I designed floating menus which would encapsulate these functions right next to the context where they belonged.
When it all came together
A simple and delightful interface to create cloud blueprints
The blueprint designed is a fairly vivid presentation but successfully brings together all elements and the layers of information for the users to be able to define blueprints with ease.
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.
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 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.
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.
What my collaborators have to say
"Aditya’s unique design approach got us to the core of the problem in the visualisation of cloud application architecture. At the end of a rigorous process of research, brainstorming and prototyping, he came up with a sophisticated design system for calm that was delightful and made perfect sense. Overall, it has been a sheer pleasure to work with him and I look forward to work with him on newer projects in the future."
"Aditya has a knack for simplifying complex technical concepts to relatable objects and then translating that understanding to a high fidelity prototype. We worked together on the interfaces and UX journeys of DevOps automation tool Calm.io (Acquired by Nutanix). Aditya delivered a new vision for the design system for the cloud backed by his first-hand research. The product was a success with users owing to its aesthetics and that it was intuitive and enjoyable."
Ashutosh Kumar, Product Manager, CALM.io