[DigitalOcean] LaunchKits
- Jenna Kuck-Chang
- Jan 24
- 5 min read
Updated: Feb 13
Overview
DigitalOcean is a cloud infrastructure provider offering simple and scalable solutions to deploy and manage infra resources for developers, startups, and SMBs.
Timeline:
Q1 & Q2 2023
Team
Myself as the lead designer
PMs from Growth and Marketplace
Engineering team (Growth and Marketplace)
The problem
Creating a complete infrastructure setup on DigitalOcean requires individually creating the resources and then manually connecting them.
For example, imagine you want to create a web app, which is a very common use case. You have to go through 8 pages, combing through almost 30 user inputs that add up to hundreds of options.
This creates 3 main pain points:
Time-consuming: Experienced users, especially agencies often create and connect the same resources over and over again for each client project
Complex: Less experienced and/or technical users don’t understand what resources they need and how to configure them properly
Lack of clarity: Resources must be put in the same project to get a unified view of infra and even then, there is no summary of the total cost.
LaunchKits aimed to address these challenges by providing a cohesive, low-effort experience via pre-configured “kits” based on industry best practices.
The vision
I started with blue-sky vision and spent about a week designing lowfi wireframes.
User flow
The user experience was structured around three primary actions (discover, create & manage) to break the work into manageable chunks and to identify areas needing more design thinking or iteration.
1. Discover - "Empty State" overview
All DigitalOcean resources have an “empty state” page that acts as a marketing touchpoint, providing key details like setup considerations and pricing. These pages have been shown to increase resource creation conversions by up to 20%.
"Empty State" details
Cover wide range of use cases
There is a wide range of use cases from e-commerce to analytics that LaunchKits could cover. I proposed we identify top 10-20 infra structures popular with customers to cover a wide area.
To help find what they need, users can filter by use case then sort things like price and number of resources and specify if there are any resources that must be included in the kit.
Create your own kit
If the kits offered don’t work, users could opt to create their own or we could create a template from resources in an existing project.
2. Create experience
Low user effort
All kits should support 1-click create, defaulting with industry best-practice and recommendations from internal subject matter experts.
Loading - Waiting for resources to be created
Since resources take different amounts of time to create, it’s important to show progress so users know things are still working. We can do this by keeping them in a loading state until everything is created or an error occurs, or by showing a progress bar with real-time updates.
3. Manage experience
Since projects are the only way that resources can be grouped, after resources are created and connected automatically, users will be taken to a newly created project page.
The reality
The first step was to create a proof-of-concept by starting with one kit - a high availability web app (2 Droplets, 1 load balancer, 1 database).
Simplifying configuration options
Each resource (Droplets, load balancers, database) had its own complex configuration process, often overwhelming users with technical decisions.
To simplify the setup, I created a defaults strategy that minimized user input by:
Setting default selections based on best practices from internal experts and high-performing customers who build web apps.
Identifying and standardizing common configurations for easy management and to automate resource connections.
I led a workshop with engineering and product stakeholders to align on these decisions. The outcome was a streamlined one-page configuration flow, where users could create their kit with a single click.
For those needing more control, each resource can be "edited” to allow access to detailed settings, ensuring flexibility without adding friction. This reduced setup from ~30 configuration options to just 3–4 key decisions, significantly simplifying the process.
The biggest hurdle was that due to the technical complexity, setting up the back end for the proof-of-concept took a lot longer than expected. This meant the timelines for this were now tight, and decisions had to be made that balanced speed with quality and usability.
The biggest decision made was to launch with just one kit - the high availability web app.
Based on how long the proof-of-concept took, there wasn’t enough time to do the due diligence with other infrastructure setups. The hypothesis was that this would still provide a bare-bones, quick start that allows users to add things on top like a caching layer or message queue.
Impact 1: Lack of multiple kits reduces product discoverability
No “empty state” page
The lack of multiple kits significantly reduced the discoverability of LaunchKits. Originally, a variety of kits would have justified an empty state where users could browse options, making it easier to understand the value of LaunchKits before committing to creation. With only one kit available, that empty state was removed, forcing users to engage with the creation and management process to grasp its limitations—missing a key opportunity to set expectations upfront.
Navigation challenges
This issue was further compounded by navigation challenges. There were already discussions on how to position a multi-resource solution like LaunchKits when DigitalOcean’s existing framework was built around single-resource. With just one kit, it was even harder to justify a prominent placement, burying LaunchKits within specific pages and reducing organic discovery.
Impact 2: Push to cut progress indicators
One of the biggest experience risks was the push to cut create progress indicators, which were crucial for tracking multi-resource creation holistically and handling errors. Without progress visibility, there was no way to know if resources aren't showing up due to longer create times or fails
Despite continuously advocating for a better experience and proposing multiple solutions, I faced consistent push back. To forecast the impact of this decision, I proposed that we do 2 weeks of internal testing. The results were clear:unsure if their kit was still in progress or had failed, users would attempt to recreate the stack, leaving behind fragmented, partially created kits. This caused confusion and unnecessary usage and cost.
Quotes from internal feedback:
I leveraged this feedback to reinforce my earlier recommendation, demonstrating the need for a clear creation status and error handling to prevent user frustration.
Prototype of initial release
Results
LaunchKits had a brief runtime from June to August 2023.
Usage metrics
While we saw an average of 45 users visiting the create page daily, only 61 stacks were created by 52 users. More tellingly, 90% of these stacks were deleted within an average of 42 hours, suggesting users were exploring rather than adopting the solution for production use.
User feedback
I conducted several user interviews with users who engaged with LaunchKits. While all generally praised the experience for being simple and straight forward, it also highlighted several critical gaps in our initial release.
The single generic stack option proved too limiting, with users consistently requesting more customization capabilities – particularly around VPC configurations, droplet counts, and database settings. This was the top request in the in-product survey as well.
Technical issues
Technical challenges also emerged, with a concerning 30% resource creation failure rate that we struggled to effectively track and resolve.
At the end, we had built a technical proof of concept rather than a solution that fit seamlessly into users' workflows. This realization, combined with the feedback, low adoption rates and technical issues, led to the decision to sunset LaunchKits.
Takeaways
If you're building for everyone, you're building for no one
Not narrowing down on the user segment we're building this for led to an offering that is too generic to be used by anyone.
If I were to do this project again, I would push for targeting specific segments to start with so that we can tailor the offerings to better meet their requirements and deliver a more compelling solution, increasing the likelihood of adoption and satisfaction.