← Back to all projects

Research + Product Design

DigitalOcean Managed Kubernetes

Setting users up for success when using one of our most complex products by providing them with the right content at the right time.

Role: I led research, product design, and UX writing across the project lifecycle. I collaborated with a junior designer and my cross-functional team.

Opportunity

We had a major business problem. Our new user retention rate and CSAT score were declining.

Investigation was necessary to understand what our users needed to achieve their goals. I identified three key problem areas for the business to pursue by synthesizing existing data inputs:

  • The way we define success didn’t match the reality of our users’ workflow. Creating a cluster doesn’t equate to success; Continued use does.

  • We were failing to help our new users reach tangible value after creating a Kubernetes cluster due to a lack of guidance.

  • Our users were looking to achieve specific goals and our experience didn’t acknowledge them as paths to get started.

User research

My initial analysis gave us a starting point, but we still had unknowns.

There were many ways to solve these problems but it was unclear what approach would effectively address them. The business was also making assumptions about what experienced Kubernetes users needed. Research goals were focused on understanding core tasks after provisioning a cluster, which Kubernetes concepts were need-to-know, the value of pre-built templates, and workflow differences between beginners and advanced users.

  • Template concept

    Hypothesis: Users are either exploring or creating a production-ready cluster so pre-configured clusters would help advance set up.

  • Personalization concept

    Hypothesis: Users are expecting us to understand their goals so we can provide more relevant next steps.

  • Onboarding concept

    Hypothesis: There are need-to-know and nice-to-know steps to get started and discerning the differences will impact our users’ success.

Key findings

I’m technical, but still need to learn
The needs of advanced Kubernetes and non-technical users were more shared than anticipated. Advanced users also use our control panel UI early in their journey and DigitalOcean-specific concepts are unfamiliar.

Am I doing this right?
Users expect us to facilitate a successful transition to their preferred API workflow and need more feedback on whether they are setting clusters up based on best practices.

“Production” isn’t one-size-fits-all
Agnostic of technical expertise, there was a desire to access more information on deploying specific types of workloads. A “production-ready” cluster configuration is very dependent on workload type.

External resources dictate expectations
Users frequently referenced learning resources outside of our ecosystem so acknowledging familiar concepts would provide clarity and boost confidence.

Clusters don’t exist in isolation
Set up includes adding shared resources such as load balancers and firewalls. Our lack of cross-product integration impedes discoverability and creates errors.

“You have ‘doctl’ which is used to save this config and add context to your machine. I found this very confusing.”

— Advanced Kubernetes user

“I ended up destroying and recreating clusters to get the gist. I thought maybe I screwed something up. ”

— Advanced Kubernetes user

Outcome

Research demystified assumptions, helped the business redefine our opportunity, and informed various workstreams.

A user’s success was contingent on a cross-channel experience that more accurately reflected their workflow. I worked closely with my cross-functional team on creating more use-case driven content and building an API experience that better facilitated getting started.

  • Goal-oriented guidance

    For first time users, I identified four discreet goals that guide users towards relevant content, tutorials, and methods of getting started.

  • Control panel onboarding

    I created onboarding content that focused on ensuring users can connect to their cluster and deploy their first workload while helping to build familiarity with managing them using the API.

  • API onboarding

    I worked with our engineers on creating an API experience that offered more system feedback on a successful cluster connection and guidance on next steps.

  • Operational guidance

    I redesigned a cluster’s overview to include pertinent status information, operations that aid in ensuring a cluster is configured with best practices, and contextual recommendations.

  • Awareness between resources

    To prevent confusion and errors, we better integrated with load balancers so users could view their status and troubleshoot if nodes weren’t accepting traffic.

  • Cluster blueprints

    The team created “blueprints” based on common workload types to help users scale to production-ready clusters. The first iteration published content to GitHub.

Key results

To more accurately measure success, we revised our definition of “activation." We established a new benchmark and observed an 11% increase.

Our CSAT score steadily increased again and qualitative responses about the difficulities of setting up a cluster for the first time were reduced.

We observed an increase in API usage. Users who successfully transition to the API early in their journey have a proven higher retention rate.

Continued improvements

We were successful in our efforts, but there was still room to evolve the end-to-end experience.

The team continued to iterate on the above projects and identified new workstreams to prioritize related to churn. New users become retained users who have their own unique set of problems that extend beyond the initial set up of a cluster. Reliability and proactive troubleshooting are critical needs for businesses running production workloads so new efforts have focused on these areas.

If you are interested in learning more about this work, reach out, and let’s chat.