How We Doubled Conversion and Boosted Retention for Docker Build Cloud
When Docker Build Cloud went live, we expected users to quickly experience its value: faster builds with remote caching and parallelization. But the data told a different story. Users were logging into Docker Cloud through the web portal—but weren’t trying the cloud builder. Even fewer were trying it twice, which, due to the cache warmup on the first build, meant they weren’t seeing the demonstrative value of the product. That meant they weren’t experiencing the core value prop—faster builds. Worse, it risked long-term retention.
Only 39% of users who logged in completed a build, and even fewer saw the second-build speedup, which is where the product really proves itself.
To reach value, a user had to:
This wasn’t a simple “click and go” flow. Even with documentation, too many users were stalling out early, either after the slideshow or before successfully configuring a build.We had strong intent—but weak conversion.
Our timeline was fixed. The public launch date wasn’t moving - and was fast approaching.Updates to Docker Desktop followed a longer release cadence, so we had to focus our efforts where we could iterate fast: the web experience.
That meant improving the onboarding flow, guidance, and UI through the web portal—all while balancing clarity, speed, and technical accuracy.
Over the course of five months, we led a tightly scoped, high-impact initiative to rebuild the web onboarding flow—anchored in user data, UX best practices, and fast delivery.
I partnered closely with Dr. Julia Wilson, a UX Researcher, to plan and run research while simultaneously leading design and acting as product manager for the web implementation work.This wasn’t a waterfall process. Research, design, and shipping happened in parallel, with constant iteration and feedback loops.
We prioritized designing and implementing low hanging fruit based on early feedback from Customer 0 and EAP users ahead of the public launch. Based on heuristics reviews and observed pain points, we mapped friction points in the funnel.
We conducted an analysis of in-product usage data, identifying weak spots in the funnel. For example, we found that only 50% of users went from creating a builder to actually viewing the instructions to install it within 5 minutes - so we were losing users because they couldn’t even find the instructions! Based on findings like this, we began the first set of iterative UI and UX improvements. In accordance with the finding above, we removed any need for users to navigate to instructions after creating a builder - we just opened the page automatically once a builder was created! This led to a >100 percent increase in the number of users who went from logging in to running a build within an hour. Other impactful changes included:
To complement the quantitative analysis with an in-depth qualitative perspective, Dr. Wilson led deep-dive interviews to understand the cognitive load and decision points users faced when creating their first builder. We uncovered more about the “why” behind funnel drop-off – like that users didn’t feel incentivized to run a second build, and they didn’t often have a test project ready to go.
Based on these findings, we:
Based on a larger pool of data, we implemented are bigger impvoement concepts in May and June, releasing powerful features to encourage users including:
“Iain and team have done some amazing work on the onboarding journey on the onboarding journey for Docker Build Cloud. THey worked fast, were happy to learn, iterate, and understand how to make the product better for developers.
The improvements have made our funnel a LOT healthier... They are a great sub-team who work well with each other, area lways proactive, and we see their impact every single day.
- Mat, Director of Product Management @Docker
This wasn’t just about improving one big number. It was about a lot of smaller numbers. We took a methodical approach of making iterative changes to progressively tackle a larger goal, rather than being overwhelmed by the abstract complexity of “improve the funnel.” This allowed us to uncover findings fast and ship fast - moving the needle rather than chasing perfection with one change.
By removing friction from several moments from the onboarding journey, we enabled more users to reach the product’s “aha” moment: experiencing first hand their builds completing up to 32 times faster.seeing just how much faster the second cloud build was.
That improved experience directly correlated with improved 7-day retention, validating that better onboarding drives deeper engagement.
Design and research need to operate in tandem: Our most effective changes came from overlapping cycles of insight and execution.
Ownership matters: Acting as both product designer and product manager let me move quickly, prioritize well, and ship continuously.
“Small” areas of friction are always more expensive than they first appear: Every unclear CTA, every step without guidance—it all adds up.
If you're shipping a technically powerful product, value must be demonstrated—not described. And demonstration only happens when onboarding clears the path.Start with actual user behavior. Design for that behavior. Then, a key point many miss: measure that behavior. And when needed, build the missing bridge between intent and action.That’s what we did here. And the results speak for themselves.
