When I first joined ObjectRocket we were in the beginning phase of launching a new platform named Mission Control and with that a new instance create flow where users could spin up a new instance with the least amount of effort and the most amount of flexibility. The goal was to afford more functionality, cleaner design and a high level of support integration for our most important feature. In my first months I was tasked with researching and designing this flow in order to create a seamless and modern environment for current and potential users. Little did I realize that this would effectively become the one feature I come back to over and over again in an effort to improve and streamline it through iterative testing and redesign. This was the start of a long and thorough research and design process all with you, our end user, in mind. In this post, I walk through the steps that got us to where we are today.
What Exactly IS the Instance Create Flow?
The instance create flow is a process that directs users through a selection of customized options to get an instance up and running.
- Users begin by choosing one of the many services we provide such as Elasticsearch, CockroachDB, MongoDB, Redis, PostgreSQL, or TimescaleDB.
- Then users choose a cloud provider (AWS, GCP, Rackspace) and a Region.
- Afterwards they can configure and customize the instance by choosing their total capacity which includes different storage and memory options.
- Then the user moves onto the next step where they can manage firewall access by authorizing an IP to connect because initially, we default to blocking all access in order to secure the instance.
- The last and final step is fun because the user can name their instance based on whatever naming conventions they like! For example, some users prefer to name their instance based on the service they’ve chosen or if the instance is a testing environment. Then they get to the good part where they spin that instance up, get their connection and get moving!
I’m probably getting ahead of myself in telling this story because my excitement in detailing the create instance flow is from where we are now, instead of where we were at the beginning of my position with ObjectRocket.
Narrator: she is.
Our initial excitement convinced us to get this feature out the door so I had to rely on competitive analysis, interviews with support staff to gauge common user issues, and investigate the Material UI framework which provided the backbone for Mission Control. My initial concern was to get something modular, easy to use, and within branding standards out the door so that we could gain momentum on development.
I started from the beginning like any User Researcher does by meeting with the stakeholders to expose their hopes and dreams for the platform. I asked them point-blank “where do you see this product in 5 years” which can be intimidating if there’s no big picture or cohesive message. The answers varied depending on who I talked to but it was clear that everyone’s goal was to deliver something intuitive and implement it efficiently with Material UI. This framework was made to support a stable, mobile-first platform with modular design capability for all devices and all types of users so this aligned well with our goals.
Where is the gap and how can ObjectRocket deliver it?
The next step was to check out our competitors to see what they were up to. I focused on marketing linguistics, branding profiles and general design because I wanted to get an idea of how they presented themselves. By studying these profiles I was able to get a better understanding of the common features their users have come to expect and how we could deliver the same in a more efficient manner while respecting our own goals and branding. Throughout this process of evaluation I kept asking myself, “where is the gap?”, of which I meant – “what is the competition lacking and how can ObjectRocket deliver it?”
Here’s what I found:
- Familiarity: Our competitors generally offered the same options during the create flow process which were all grouped in the same manner. First, the user was presented with Services, then Cloud providers, then regions, and etc.. The important thing to note here was that this was suggesting our users expected a certain type of grouping of elements in a predictive order throughout the flow.
- Billing: Generally the credit card aspect was different depending on which competitor I focused on though it was clear that the general idea was to draw users in by offering a free trial or a round of free credits that were automatically debited towards their activity. When offering free credits or a free trial, the user was either prompted in the beginning to add their credit card for overages; or their data was expired and deleted while they endured multiple rounds of emails threatening the removal.
- Communication, Messaging and Support: Our competitors offered some form of instructional messaging throughout the process though they depended on a chat feature or documentation for extended support. It was clear that they suggested their users preferred and expected some level of DIY, though I was skeptical to project that onto our own users without proper research.
- Mobility: Our competitors generally lacked any flexibility in presenting their product to users with multiple device viewports in mind. In layman’s terms, they designed and built for the Desktop audience and were ignoring their mobile users.
The lack of mobile-friendly environments irked me the most because a lot of my independent graduate research done during my time at UT Austin suggested that we are all moving towards a portable digital lifestyle. I’ve always been a proponent of developing with the portable user in mind because it opens the door to more opportunities and flexibility for everyone. It’s inclusionary, and why would you ever want to exclude anyone from potentially absorbing your product?
Narrator: This must have been the “gap” she was referring to.
Yes Narrator, yes it was. Well, it was part of the gap. The other parts were looking at when we asked our users for their billing information and communicating our passion for 100% customer support.
Finally, it was time to take what I learned and have a go at the initial designs for the instance create flow. I started with what Material UI offered, customized it with our branding colors and punched it up by incorporating a summary area with little rockets pulled from our logo (fig. 1).
Figure 1: The original create instance flow design
After a couple rounds of engineering feedback, the feature was built; but since design is a never-ending iterative process we planned to run a few research sessions with the Rackspace Experience Design (RED) team after launch.
Meanwhile, we had a launch party to present the new feature along with cake, champagne and stickers. I remember being there and picking the feature apart because I just wasn’t happy with it and I knew I could have done much better. A couple months went by and Mission Control evolved to incorporate more features, capabilities and services. ObjectRocket happily added CockroachDB and TimescaleDB to our offerings which was fantastic but all I could think about was how to improve the instance create flow.
We came up on the summer months and were graced with a research intern who was tasked with interviewing users on the create flow. The feedback revealed an inefficient design and confusing micro-functionalities inside the flow so we documented everything and implemented updates to the live feature.
One particularly confusing process was the step designated to manage the Firewall access and add IPs. Originally we wanted to add in a few micro-processes such as the ability to add any IP, or add multiple IPs, or skip the entire process altogether. Overall it was too confusing because there was so much we let the user do that they didn’t know what exactly needed to get done in that step.
Another confusing step was visualizing the number of Nodes allocated when the user selects the capacity they prefer (fig. 2). In early testing the users expressed confusion over why the graphic was there and what it was supposed to tell them.
Figure 2: Representing the nodes in graphic form
I went back to the drawing board and decided to do a full redesign. It was time to show the potential in this process.
Narrator: Next time on “Finding the Gap”, our author starts all over again.