IBM Cloud

Helping devops users manage their workloads and compute resources.

Duration: July 2017 - Present

Teammates: Spencer Reynolds & Micah Linnemeier

My Role: UX Research, UX Design, Visual Design



In the past year I've worked with an awesome team of ux designers, front-end and backend devs, and project managers on the IBM Cloud Kubernetes Service, a compute solution for devops users. Select projects are shown below.

Mutli-zone Worker Pools


Devops engineers need a way to make sure the application deployment process is smooth, and that the company’s applications are always up and running. Application downtime means profit loss, lower customer trust, and the dread of having to explain to their boss what went wrong! To ensure that their containers are highly available, devops engineers have to make backup clusters in multiple locations, in case datacenters in 1 location go down. Our task is to help our users better manage these clusters in different locations.


With only 1 competitor, Google, having implemented worker pools as a technology, I read through their docs and explored their offering as part of the initial secondary research. Using that knowlegde, I met with subject matter experts, our developers, and internal users to fill any gaps in my knowledge.


Our devops users create multiple clusters for high application availability, but each cluster is often underutilized, causing unnecessarily high costs. They have to manage the connection and load balancing between the clusters manually. Creating new clusters and scaling up existing ones is also limited by there can only be 1 machine type and 1 zone per cluster.


Spencer and I tested our prototypes with 6 users, mapped out the feedback we gathered on each page that we received it on, and discussed neccessary changes together before I made updates in the sketch file.


Our solution allows users to create high availability multi-zone clusters, pay less for more utilization, and spin up the same workers faster with pools.

Users like Rohan can now add multiple pools to each cluster, allowing different flavors of machine types to take workloads together:

Click into each pool to see the workers it's made up of:

Error prevention - when the user tries to delete workers instead of resizing a pool, we warn them that this would unbalance the pool (causing the workloads to schedule unevenly across zones):

Even if their pool becomes unbalanced, they can easily rebalance the pool, which creates workers in the needed zones to make sure each zone has an equal number of workers:

Without having to reconfigure a new cluster, users can now quickly scale up their existing worker pools by number of zones or number of workers per zone:


IBM Cloud improves App Availability with Multizone Kubernetes Clusters for AI, BlockChain and IoT - Tech Sutram


Building a cloud for AI with Kubernetes, DevOps and scale - Jason McGee, VP & CTO IBM Cloud


Improving App Availability with Multizone Clusters - IBM Blog

Helm Charts


Kubernetes is pretty complex with all the objects that need to be handled ― such as ConfigMaps, services, pods, persistent volumes, releases, etc. Traditionally, for developers to set up an application (or a piece of an application) from scratch, it would take hours to stitch all the pieces together and run tests to ensure it's production ready. For the users of our service, creating a cluster (with mutli-zone worker pools) is just the start, but much still has to be done to get to productive use! The goal was to simplify application deployment for much needed functionality.


Get familiar with the domain and technology

This was the first project I shipped at IBM, so to start I did a lot of research on Helm charts and why people use them. I watched youtube video tutorials geared towards devs new to helm to see what kinds of things they were interested in learning, and what foundational knowledge they already had.

Build empathy with users

As someone new to Helm (and coding) I went into the command line, deployed helm charts myself, ran into errors, and debugged from forums. I went to talks at Kubernetes conferences to learn from the products in the industry, see what problems are being solved, talk to real users and find out what questions they’re asking.

Map out the existing state with painpoints

Through interviewing users, I learned about their workflows, and mapped out the end to end journey to see where their pain points are.

Test prototypes with users

To get real user feedback, I sent over 50 emails to recruit users that used Helm to give feedback on my designs. I communicated the feedback my team of OM + devs to justify design decisions and move the project forward.

Make it easy for devs to consume

I learned that showing a bunch of screens to devs is like screaming "Look at all the work you have to do!". Thus, I started separating out all of the actual functionality i wanted into CRUD format; "the new UI essentially requires these Create, Read, Update, and Delete functionalities on these X objects."

Figure out what parts are released

I balanced requests from project managers + deadlines and bandwidths for development + user value to determine what pieces make sense to be shipped together. I chunked off the entirety of the work into cupcake, birthday cake, and wedding cake pieces. We're currently working on the birthday cake.

Aligning with the rest of IBM Cloud

Since IBM is so big, I met with people from the private cloud team, cloud catalog team, carbon design system team, and content teams to avoid redundant efforts and inconsistencies.


Helm charts offer a simple way to package all the Kubernetes resources into one simple "directory" of files that surfaces what can be configured. I like to think of it like baking - you can buy and measure out all the ingredients, or just use a box of cake mix. With one command, users can deploy a fully functioning app. Users can then customize and build on top of this base, simplifying and speeding up the process to get up and running. Through our UI, a new user who just created a cluster can now get a database, a monitoring tool, another IBM service, etc by browsing and deploying a chart that meets their needs.

Users can browse for charts based on the category of solution they're looking for. Users who know the exact chart they want to use can simply search for it.

Users can click on any chart to see the readme. This is typically the first thing devs look at before installing a chart. They can see

Users can configure each chart directly in the UI, and install it to their desired cluster. This method is for our "ops" persona, less of the developer. By advertising the configurable parameters (and filling in defaults), users can bypass scanning the other parts of the values.yaml file.

Installing a chart creates a release. Every edit made to the chart (ie. editing the app code & pushing a new image) will create a new release. If 1 release fails to deploy, users can correct that error easily by rolling back to a previous working version instead of tracking/undoing all of the changes made.

Additional projects and images will be shown once they're shipped. Thanks for stopping by! :)



My other projects and responsibilities include:


Cloud Platform Logging

Designed a way for users to set up and manage their logs via IBM Cloud. Announced


Cloud Platform Monitoring

Designed a way for users to set up and manage the health of their cluster and apps via IBM Cloud. Announced


Guided User Assistance

Helping users confidently advance through their chosen journey on IBM Cloud without needing additional support. I worked on the entry into Kubernetes use case.


Open Sesame

With a team of 7, designed an experience that helps 3rd party solution providers discover how to sell their services to potential customers via IBM, and gain real value over time.


Critique Culture

I'm responsible for facilitating critiques within the Kubernetes design team, as well as group critiques across 3 teams.



I'm responsible for setting up the sponsor user program for the Kubernetes team. (Sponsor users = research participants at companies that use our service) This aided with getting valuable feedback throughout the design process for our service.