Project Overview
Containership Cloud is a centralized dashboard for users to manage their Kubernetes infrastructure across any and all clouds, as well as on-premise. There was an early recognition that having a good user experience would be tantamount in acquiring new users and retaining current clients.
My Contributions
I lead the design work both on the UI and UX front for the entire SaaS platform. I was tasked with creating a design system that would be an extendable base to build on top of, implementing industry best-practices, working with existing users to implement any necessary features, and continuously optimizing the product based on new requirements, analytics, and user sessions.
Component Driven Design
As the only designer working in a team of engineers, it was very easy to see a scenario where I would be the bottleneck. So, early on we decided to build out a component library that would eventually turn into the design system for our entire SaaS platform. This enabled the engineers to limit the recreation of components, gave them the autonomy to build out simple flows, and created a collaborative toolset that we could continuously optimize.

We took the atomic approach and built out the very basic atoms: buttons, labels, fonts, and inputs. From there we were able to build out more complex flows that would eventually become reusable components that would be implemented across the platform; including our resource table, metrics graphs, logging interface, and cluster creation flow.
Cluster Creation
One of our key differentiators was the fact that we enabled users to create Kubernetes clusters on any major cloud provider, and giving them the same experience while doing so. There were many challenges that came along with this, each cloud provider had different requirements to spin up their virtual machines, users did not trust us with their cloud credentials as a 3rd party, important information wasn't clear from the beginning, creating highly-available clusters was challenging, and much more.

Cluster creation was an ongoing optimization challenge. I worked directly with the CTO and VP of Engineering to understand exactly what the requirements were and translated them into a way the user could easily understand. This is where my background in eCommerce came into play. I was able to take a similar goal, get user to convert, and instead of purchasing a pair of pants or shoes, we were helping them create a HA Kubernetes cluster. The Cluster Creation flow consisted of 7 steps: Providers, Regions, Kubernetes Options, Master Pools, Worker Pools, Plugins, and Summary. This was our conversion funnel, each step we attempted to make as pain-free as possible—by filling in our recommended option and enabling the user to quickly customize it and change it to fit their needs. We provided other usability optimizations a few being keyboard shortcuts to quickly navigate, recommended IPs for your VPC and subnets, as well as displaying VM prices so you know exactly what your monthly payments were.

Even with all of the optimizations occasional blips would still occur, so I personally worked with users and reviewed their sessions to find pain-points and figure out the best path forward to mitigate them.

Resource Table
The resource table was truly an incredibly powerful addition to the platform. However, it was not perfect from day one. My objective here was to take what was a complex YAML file, distill what was important, and provide users a clean experience to view their resource details. Initially, we (meaning I) made the mistake of trying to pull out the information I deemed important and provide the users with a very clean, and spacious, UI to view those details. We quickly realized this is not what the user wanted. They might be relying on other key details that we weren't pulling, additionally they had a lot more resources than we anticipated, so we needed a change.

This was the genesis of the resource table. I know, you might be thinking "Big deal, it's just a table", and normally I'd agree with you, however we were able to ingest an incredible amount of data and present it in a grokkable way. The resource table normalized the data and allowed users to add new columns to view what was important to them, enabling them to search for their specific resources, granular filtering, and sorting.

Due to the fact that the table was designed in such an extendable and customizable way, we were able to use it throughout the Containership Cloud platform in a variety of ways including RBAC, clusters, nodes, and of course for Kubernetes resources. Each one required some customizing, but because the base component was robust the updates were minor and greatly improved the experience for each flow. For example, the cluster status bar changes whenever there is an issue with a node on the cluster, users get a readable description based on the roles they've created, and resources have editable labels they can interact with.
Monitoring and Metrics
Day two operations were an important part, and unique offering, for our platform. The majority of vendors typically assist in cluster creation and then tell the user to install kubectl or simply give them external links to other tooling, like the k8s dashboard, Prometheus, and Redis. However, we wanted to make sure that our experience was the best all-in-one Kubernetes offering available so we decided to integrate these tools into our product.

I was in charge of ensuring that each tool worked as expected, but remained on brand and had a consistent experience with the rest of our platform. The first thing we tackled was bringing in Prometheus metrics, and displaying usage charts in a useful way that users could glance at and be provided with useful information. Once again we didn't want to limit them to just CPU usage, or to a couple of resources. So, we had to make a robust component that would be able to take in lots of data sources. We decided on showing two different types of graphs, circle graphs for allocated memory and CPU, and line charts for real-time utilization. We then allowed the users to toggle through any of the different metrics they might be interested in seeing, CPU, GPU, memory, and networking information.

This lead to us creating our own custom metrics-based autoscaler, Cerebral. By utilizing our extendable components we were able to quickly customize it to fit our needs. With autoscaling we needed to show the user the min and max thresholds they were willing to allow their cluster resources to be. We had to show them the existing and historical metrics and then provide them a way to easily change those thresholds.

Other key day two features were the activity feed, and logging. With the activity feed you could see exactly who was doing what on your cluster, combining this with our RBAC integration, you have a robust auditing and security suite. Also with our built-in logs, we provided users with a clear and decipherable way to see what was happening in each one of their containers individually—or as a group on their nodes.
The Future
Regretfully, as of September 2019 Containership has ceased operations. While it has been a tough transition, I've learned so much along the way and will cherish the friendships I've made with a group of incredibly talented people. I bring this all up, because there were some really cool features in the works that I wanted someone to see.

Dark Mode
The obligatory dark theme was getting ready to be released for Containership, working hard with the engineers, we were creating a sleek dark theme that was still WCAG compliant and accessible.

This was a key feature that I was really excited for, we were finally gearing up to release federation capabilities. That meant instead of having managing and deploying to individual clusters, users could deploy federated resources and they would be distributed throughout all of their clusters.

Interested in working together?

Say Hello