Overview

The Collections feature in Kubecost allows users to get a unified view across costs in the Kubernetes and Cloud domains, ensuring that resource costs are deduplicated. Previously, users could create one Collection at a time and configure it with the desired filters. I wanted to create a more formulaic way that embraced scale. To accomplish this, I gathered our Product Manager and 4 engineers to ideate on a tool that would allow users to create collections in batches, while only providing the basic information needed. The Collection Builder feature follows a wizard user experience, guiding users through a series of steps concluding with the creation of a set number of Collections.

Product

Product Management

Currently, users with both small and large environments utilize Kubecost to monitor their Kubernetes and cloud costs. However, some features are too onerous for organizations with large environments causing these users to duplicate a specific action hundreds and in some cases thousands of times. I identified the need to scale our Collection creation by “living” in the feature, exploring its processes and asking “what do I do if I had 200 assets that I need to create collections for? Am I to continuously repeat this step?” I met with our customer success team to gather user feedback from support tickets, user suggestions and other notes regarding Collection creation. I was then able to confirm the frustration users held with creating Collections for larger environments. I got our Product Manager and 4 engineers on a call and we began to develop a solution for this problem.

Below is an excerpt from the Collections PRD I used to tailor the feature’s requirements, help keep it in scope and align all teams involved in the project.

UX

Developing the User Experience

The requirements gathered from the product stage provided a functional foundation for a theorized ux flow. From the PRD, I was able to easily identify must have components and behaviors for the feature.

Keeping engineering involved throughout the product stage also allowed me to best understand what was in-scope and feasible for our engineering team to undertake given the expected quick turn around for this feature, thus reducing complications surrounding what the API was and wasn’t capable of performing for a v1 and reducing the need to go back to the drawing board to account for these complications.

Below is an excerpt from the design outline defined in the PRD for transparency and team wide alignment.

UX

Design Iteration

Utilizing the previous user experience flow and PRD (for good measure) I began iterating on design layouts for the experience.

The low fidelity mock below was designed to give a basic idea of the critical requirements identified and how they might be presented.

I found this layout did not effectively utilize horizontal space. The results are the most important component for the top section, however the filters take up 60% of screen space leaving the results feeling like an afterthought.

(Do note, this mock was just to represent layout. As such, components such as the filters were not represented here.) The layout for this section could work. However there was little to differentiate the two sections. As a user, what identifier is there that tells me the bottom preview section is a result and response to the top section?

Final UX

I was able to design a layout that condensed the content in a functional, simplified manner.

Users are able to view the results and preview side by side, which will aid them in the build creation process. For Builders with multiple filter groups, users can collapse groups they are done working on to reduce vertical scroll and expand them if they need to revise a previous filter group.

Users are also given the ability to search and sort through preview collections to better identify collections to manually merge.

Users can specify or create categories for the Builder collection.

Users are shown “edit” on hover for collection items. (users are also shown “delete” on hover for filter groups)

Users are given the ability to specify the title rule, with copy that assists its process.

Users are presented with an active merge button to indicate items have been selected and ready to merge.

Fin

Measuring Success: Where do we go from here?

Kubecost employs a launch and learn process. With L&L, I’ll continue to monitor the feature and how users are responding to it. I’ll keep my ears open for feedback regarding the feature through tagged keywords coming in from the support channels, receiving information from customer success tickets and directly asking users to provide feedback. With the given feedback, I’ll utilize the next release cycle to improve ux, with a deeper user driven perspective. Over the next few months, I’ll keep the following KPI’s in mind to measure its success and how we can improve.