A Consumer-grade Experience for Cloud Orchestration
Orchestrating an enterprise cloud is inevitably cumbersome. CALM took a visual approach to make it easier.
As the founding and sole designer, my role involved:
• User research & interviews
• Design critiques with the team
• Low-fidelity wireframes
• High-fidelity mockups
• Testing prototypes and product with users
• Engineering handoff
Outcomes
CALM got acqui-hired by Nutanix soon after the redesign with a high praise for the UX and visual design. I co-own the patent for CALM's marketplace architecture.
Diving into the community and the complexity
Starting with research
My first aim was to understand the cloud and the problem scope in detail. For this, I started gathering knowledge and perspective from within team CALM. alongside my own secondary research.
I also started to reach out into the industry to meet DevOps professionals at large corporations. I managed this through my existing network and by joining DevOps groups online. I gathered more knowledge and tested CALM v1 with them.
CALM's 3 user personas
1. The DevOps: The DevOps personnel is the one who sets up and manages the virtual infrastructure for the enterprise. Typically a master in computer applications, this person has knowledge very specific to the context of cloud.
2. Technical owner: This could be the lead developer on the team. Typically a software engineer who is proficient in languages and technical details that have to do with tying together the pieces of the virtual infrastructure.
3. Business owner: Typically someone in a leadership or management role. This person is likely to not have detailed information about the code or packages being deployed but intends to spin up infra using the Blueprints that the DevOps would have created.
Qualitative Research & Testing
I joined team CALM in the initial phase, so I had a working POC to test with real users. The feedback that I got from DevOps users in the industry became instrumental in shaping the next version of CALM from ground-up.
Screenshot of CALM v1 showing blueprint of an app comprised of services and a 'flow' created across them. On the right hand side (pane) is shown the configuration of a service.
Testing CALM's v1 UI revealed that there were some foundational issues such as confusing mental models, hierarchy of content and lack of clarity in terms of the design's architecture.
Redesign of the blueprint model
Research guided me to re-model the blueprint definition in 3 layers for scalability
Service Design on-Canvas
I separated out 2 concepts of [1] the function tasks’ list and [2] service. This was especially useful because functions apply across services.
From the older architecture based visual design to the new
Multi-cloud Blueprints
The cloud has evolved to run with services clustered across different clouds with their own configurations, and as CALM caught up to that, the design needed to evolve.
I also considered 2 broad approaches for representing blueprints with multi-service multi-substrate, and eventually settled with the 2nd approach of a snug-fit container.
Testing the new design
The foundation of this big redesign were [1] the new workflow and With a foundational change to the design in terms of the workflow and visual design, I prototyped blueprint creation and Application Console flows and recruited 4 users to test this prototype. I had the following questions in mind:
Does the workflow make sense to the user?
Is the representation of the service intuitive?
Are the representations of the relationships intuitive?
What does the user think about the aesthetics?
Results
The workflow and representations were fairly intuitive for all the 4 users and it made for a delightful aesthetic experience.
Some reactions to the redesigned CALM:
'Wow, this is really neat!'
'Never seen enterprise software this great looking!'
'This just makes sense!'
The Redesigned CALM
In the new thematics, CALM's design was vibrant with its design system and the colours of the ecosystem.
The blueprint canvas interface showing services added with dependencies and configuration of the selected service. The Blueprint layers panel shows the Services, Functions and Application profiles.
With the sky as the metaphor, the Deployment Console shows the virtual machines to having the same essence. 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 function
The user has the option to switch from the topological view (which follows the convention of the blueprint definition) to a grid view. A grid view can act as a more absolute granular view of the infrastructure.
The base grid view of the deployment showing service type its place in the array and cloud provider
The grid view itself has 3 zoom levels, across which the level of information varies. Especially useful for array type services, the zoom levels indicate the array no of the service to just the status, based on zoom level.
In the finer grid view, service provider shifts to the header
Grid view showing services with their array number and status of machines
The billing layer adds visibility about cost differentials for the currently running process.
Grid view with the billing layer showing differential of cost impact of the currently running function
And at the most zoomed out level, the user sees clusters in their state. Especially for enterprise cloud when a bird's eye view is required, this level works to troubleshoot quickly.
