Mayank Khanna

Cloudistics Ignite 2.0

Project Background

After building the Ignite MVP 1.0 and refining it to satisfy the needs of our initial customers, the Cloudistics UX team was tasked to accomplish the vision of the product's MVP 2.0.

The team comprised of Ame, Senior interaction designer and me as the second interaction designer.

Considering the nature of the product, the requirements for these features were driven by the company's senior management including the Chief technology officer (CTO), the Chief experience officer (CXO)/ VP of product and higher-level sales executives. The requirements were developed with years of engagement with subject matter experts and in-field sales representatives. High-level concepts around the overall functionality were validated with friendly customers that were using the product and were exposed to the product domain for several years.

Learn more about Cloudistics Ignite here.


Product Background:

The MVP 2.0 required the current product to conceptualized as two fundamental units: Infrastructure unit and Virtual Datacenter Unit. Both these units were bound within the organization unit.

The system in it's simplest form can be explained as follows:

In it's most complex form, the system is composed of complex relationships, dependencies, and hierarchies.
The concept diagram below illustrates the system in its entirety.

With the Ignite 2.0 MVP, we were tasked to introduce the concept of user roles wherein each role had specific privileges and access to certain areas of product functionality.
The four roles and their level of access are explained as follows:

For ease of explanation, I will refer to them as Infrastructure role and Virtual Datacenter (VDC) role. For ease of illustrating the work done in this project, I am indicating key parts of the product that were impacted.

A new user invitation flow

The Ignite MVP 1.0 required the user email to be invited into an organization. With the MVP 2.0, the user was supposed to be assigned a role and in case it was a VDC role, one or more VDCs had to be selected for the user before invitation.

Designing a self-serviced environment

The entire functionality was based around a fundamental product goal:

An infrastructure admin should be able to manage all the hardware resources within an organization and slice them as a set of resources for VDC managers to utilize for their application deployment needs.

To accomplish this, we had to rethink how a particular Virtual Datacenter was created. Earlier compute and storage resources were allocated to all datacenters in a single form and networks were available for use to all datacenters by default. Now networks were provided as a resource by the Infrastructure admin to the VDC manager.

In order to provide a clear overview of the resources available and the resources utilized in a particular VDC, the resources page was created. (A subset of this information used to be indicated in the previous version of the product and was located under a tab.)

Until the user completed the setup of a virtual datacenter, they could not use that environment in any manner. Hence, there was a need to inform them that the setup was incomplete and also highlight which aspect of the setup was missing.

Ensuring ease of use across these environments

While we were allowing the users to create these self-serviced environments we were challenged by the fact that all the new application creation flows got buried inside these navigation structures.
The product owners wanted to only allow object creation within the environment when the user was in that environment. I was able to convince the product team that such an approach would be too restrictive for our users and will cause breakdowns in the user experience. This meant that all our user flows for creating a particular object had to be mapped in detail and we had to ensure that we were covering all scenarios.

We also had to respect the following business rules:

  • An admin should be able to create an application from an enviornment's template in the same environment.
  • An admin should be able to create an application from an organization's template in any of the environments.
  • Key Takeaways

    The size of the project, the sense of product ownership, the integrated collaboration has had a profound impact on me as a product designer. The strict timelines, the pressure to constantly deliver while keeping the user experience at the forefront has taught me several things:

    • Designing/ building the user interface is a very small portion of the duties a designer at a startup fulfills. The ability to question and refine broad requirements, prioritize them and ensure the user needs are satisfied while keeping a high bar for the entire user experience plays a major role.
    • For a designer working at a startup, the best user experience is not always the answer. They need to present the best experience to the team but needs to scale it back in order to satisfy concerns such as technical constraints, development and QA effort required and the ability to keep the product flexible for the company's future roadmap.
    • If a designer wants the product to be developed with the same level of the detail with which it was designed, they need to ensure that the design is documented with the same level of detail. The level of detail can be ensured through a prototype, through several states of the UI or sometimes even plain text. The lack of tools/product licenses should not hinder a designer from representing their design in the best manner possible. Designers are owners of the holistic product experience- not a single screen or a single flow.