ObjectRocket was founded in 2012 to tackle a serious problem in cloud infrastructure - the need to effortlessly scale a Database on demand, and efficiently run MongoDB instances. They began with their initial app which hosted MongoDB as a main service offering and led to their initial success. The next step was aimed at integrating ElasticSearch and Redis data stores - but by the time 2018 rolled around their platform was buggy and dependent on ancient coding - so it was getting harder and harder to support new services.
The goal was to build a new app named Mission Control, to manage a (seemingly) endless amount of services while slowly phasing out their existing platform. They didn’t have an exact deadline because they were still building the engineering team and working on licenses to sell MongoDB, ElasticSearch and Redis on their new platform.
Ideally my first step was to collect all the assets they already had which included some previous Low-Fi sketches of Mission Control from an outside agency and their branding book. After a few one-on-one chats I realized that they just weren’t happy with the Low-Fi deliverables. They thought that the low-fi’s were too similar to what they were trying to get away from in their current environment.
However, they liked that they had a group at their disposal instead of waiting on the Rackspace research team to fit them into their schedule. They also appreciated the overall architecture and some of the finer interface solutions that the agency came up with.
I knew we needed to test early but with monetary issues and the delay in getting on the schedule for the Rackspace research team - I decided to move forward with my own limited research and get them to an MVP. In the background I put together a Research Roadmap which outlined the testing that needed to be done in full detail when we were able to get some help.
I also met with marketing to review their tracking analytics to find out where the drop-off was, which was actually during the Create Instance flow when they were asked for a payment method. I also put together a quick list of High Impact, Low Effort action items to prioritize for the MVP. Number one on that list was the Instance Create Flow which was the main funnel for all signups and sales.
With keeping the concept of future flexibility in mind I wanted to make sure that whatever we did for the MVP was expandable for the long term integration plan. The executive team were looking at integrating CockroachDB down the line as an offering in Mission Control which added a new level of complexity. It wasn’t just offering CDB, but the concept of certification management and manipulation as well as defining micro user roles with specific capabilities.
I setup a few whiteboarding sessions with the engineering team doing discovery because I knew I had to fully understand how it would be managed within Mission Control. I had to understand the basics of managing the Product and the mechanical steps involved.
The biggest challenge in this integration was getting the verbiage correct because there were so many unique situations for a user to be in. What if they had an expired certificate with associated users? Or how would we inform them that they needed to create or rotate a CA?
I worked through this by keeping the lines of communication open with engineering, breaking apart the design process so that I could focus on one journey at a time, doing regular design reviews, and even some ideation sessions with the engineers to get them excited. They didn’t mind doing it because it was a fun way to spend time and they loved to teach.
By now I had a pretty good idea of where we were going with Mission Control so I took a step back and wanted to see how the branding would be implemented. My goal was to create some standardization by showcasing how it would be implemented using the Materials framework. The engineers had already started building the more common features like a sign-on screen so I needed to give them documentation they could refer to on a constant basis.
I had some time before the engineers would start touching the front-end because they were focused on getting the API up and running - so I figured it was a great time to look around and see what the cool kids were doing. In our initial chats they named a few competitors right off the bat, who they believed were more successful or had lured some of their customer base away.
I broke the list in two, with the deciding factor being if a competitor offered more or less than 50% of the exact same services. This revealed the top two Direct competitors - AWS and Microsoft Azure. Under that umbrella I focused on some very specific features that the stakeholders consistently asked for - one of which was a main dashboard showcasing the latest activity. They were convinced that this was the key to retention and return visits.
The problem with comparing yourself to companies as big as Amazon and Microsoft is that they truly can offer almost everything under the sun, which might not be a great basis of comparison because that balloon is too big. But I wanted to provide some insights into what I found and how ObjectRocket could do things differently.
Overall they could minimize the burden by leveraging convenience beyond the 24/7 support they constantly advertised. They could also boost communication by incorporating quality content such as clear documentation which would build trust. They could also maximize support by making it known how efficient they are at supporting the health of the Products they offer by minimal downtime and errors. Last but not least they could differentiate themselves by being transparent in the cost of their support by restructuring into tiers.
Some recommended enhancements I presented included providing real-time data visualization, curated shortcuts, personalized learning resources, a sandbox environment for testing scenarios, and informative webcasts announcing new feature rollouts.
At this point the engineers were getting antsy so it was time to get the Hi-Fi comps going for the MVP items. First on that list was the Instance Create flow. I thought back to their comments about the Low-Fi’s being boring and the credit card drop-off.
I attempted to solve these issues by punching up the interface with the branding and setting up a step-by-step funnel to get the user invested in building their instance. Step 1 would give them some customization, step 2 would automate some of the offerings into packages, and step 3 would cover IP access for security. A custom experience, with transparent features in clear verbiage, that helps them sleep at night.
Finally the Rackspace research team had time to work with us, which was great timing because Mission Control just launched and we had something tangible to test with. I set up a few initial meetings with their team to review and collaborate on the Research Roadmap and come up with a timeline to get User Testing done on the Instance Create flow.
It kinda took off from there. We worked together and met up regularly to talk direction, collaborate on the user journey, edit the interview script, and review feedback after each user testing session.
We talked to 12 people but by the 7th person we were seeing a pattern in feedback where a majority of the users felt confused by certain areas of the flow, and even more deterred from spinning up an instance once they were asked for a credit card. Some of the users were already customers and didn’t see a reason to add in their credit card information. Other users stopped short of entering that information because they didn’t see the value in committing to us with payment - from the fact that they weren’t sure what they were purchasing.
Overall I wanted to reorganize the flow to help make it more coherent, give the users some more options while keeping them on-task, and adversely - narrow their options to avoid forcing them into a side-quest. Most overwhelmingly, the users mentioned that they would name their instance based on the customization options - so I decided to move that step to the end.
This was all compiled into a CEI (customer experience index) which I presented to my fellow engineers so I could show exactly what pain points the users were hitting. I also included suggestions on how to solve these problems while also harnessing the flexibility of what was already built. If I could reuse components that were already made then it would reduce engineering hours and get the new redesign up faster.
Now that I had the greenlight to do this, along with an engineer and three 2-week sprints, I set to task solving these top problems. First off I wanted to clean up the interface and take more advantage of the whitespace. Then I ideated with the engineering team to see how we could deliver services sooner than expected while also drumming up interest - so we figured that we could release a product on the Beta version of a cloud provider.
That firewall section in step 4 was something of an eyesore so I simplified it by reducing the amount of IP’s that a user could enter - which was an infinite number - down to just 1 number. We needed to respect their goal of getting an instance spun up by reducing the amount of work they had to do. I took it a step further and automated that field so it would be automatically populated based on the users’ location, but also editable in case they had a specific IP to use.
I moved the Naming field down to the end so that they could name it based on their selections. And in the summary I opened it up to showcase their specific selections in more detail, offered transparency by adding Terms of Service where applicable, and even injecting impulse buys like the more expensive enterprise-level support.
In regards to the post-credit card incentive, I wanted to implement a gifted sign-up credit which they could use immediately towards their purchase. I also made sure to add verbiage in the credit card form notifying them that they would only be charged after the credits have been used up.
After I was finished with this stage we had a reorganization and I was moved to another team to focus on cloud native development. After a while it was found that supporting CockroachDB was too expensive and they didn’t have enough sign-ups so they decided to End-Of-Life Mission Control. The metrics I was able to gather for success post-release were mainly quantitative in that there was a significant increase in new sign-ups and a reduced drop-off rate during the Create Instance Flow.
Looking back at the designs now, I really would like to take another crack at improving the overall experience for the users on the smaller functionalities such as adding Nodes or managing the CA’s in the CockroachDB flow. I’m happy with the results we got from the user testing sessions and that I was able to implement my changes. If I were able to re-test that credit card section I would have been able to discover additional qualitative feedback.
