Client: Docker
Timeline: October 2024- February 2025
Roles: Lead Product Designer
Prototypes:
Early 2024. Docker’s multi-year bet on its security platform Scout was falling short. The Executive team made a decisive pivot: generate new revenue through Docker Hub by monetizing storage and pull data.
The true strength of Hub lies in the content itself. Public repositories drive the lion’s share of usage, about 5.5 PB of pulls daily, while private repositories trail at roughly 0.85 PB. On storage, the balance flips. Private repositories are far heavier, around 21 PB in total, compared to the much lighter footprint of public repositories. Unlike pulls, which was being monitored, this storage data wasn’t exact as the measuring tool was still being built.
None of this usage was being directly monetized.
Hub monetization had three parts. Pulls to monitor usage. Storage to show consumption. Image Management to delete images.
The biggest challenge was the excecutive wanted this shipped fast.
Only 3% of users would be impacted, mostly enterprise accounts handled directly by sales.
The problem was Docker wanted a broad approach, surfacing this to everyone instead of targeting the top accounts that mattered. We tried to push back but it feel on deaf ears.
That left the other 97%, 26.6 million users, as our concern. Would they understand they weren’t affected, or would it trigger panic and backlash against Docker, which historically has happened? Communication and informing our users will be vital.
To kick things off I facilitated a brainstorm between the HubUX and the Registry team. The goal was to outline every possible pain point a user or admin might encounter with metering Pulls and Storage, then dot vote on which felt the hairiest.
We answered HMW statements and grouped patterns into Technical Challenges, Optimization and Cleanup, and Monitoring and Management.
I reduced these to core functionality and ran a workshop with leads from boths teams. We pulled from the backlog to shape the MVP, release 2, and beyond.
We started with Pulls because the data was ready and it was Docker’s largest expense. To reduce the blast radius, we targeted only org admins.
Before launch we worked with Docker Captains, the DevRel team, and Marketing to test the messaging and shape a campaign. The MVP itself was basic, focused on sharing information. It showed minimal data with the option to email a usage report. We also learned the data wasn’t on-demand but bucketed, so not as up to date as we wanted.
The MVP was basic so I moved on to validate the next release. Customer 0 and a few Docker Captains gave me a fast iteration loop that sped up design. Everything was ready to deploy, but stalled when Docker’s pricing and packaging was delayed.
This is what it was supposed to look like. The goal was for users to quickly scan the dashboard and know if they were in the green or red. With pricing undecided, we cut metering. It wasn’t a real v1, so we pivoted to another pillar of Hub monetization until a decision was made.
Image Management and Storage were closely linked. Storage tracked consumption, while Image Management gave Admins a way to clean up old or unused images. We worked on both, with most of the focus on tooling.
At first we assumed deleting an image would free space. It didn’t. Images were tied to index and manifest digests, so you had to delete the digest itself. A single digest could link to multiple images, and removing one could take out many, including some you didn’t intend. Think of it like a rolodex. Some cards stand alone, some are their own rolodex full of cards, and some connect into others.
I spent a lot of time with engineers trying to understand digests. I designed my way through it, getting feedback from both teams with each change. I was later told those designs helped the engineers better conceptualize the work ahead.
My goal was to communicate what an admin should delete and what that deletion could impact, including the removal of other images.
Again, this is what it was supposed to look like. With pricing and packaging still delayed and heavy technical constraints the registry team hit while building the metadata store, the first version looked nothing like this.
Around the same time I was also pulled from the HubUX team to join the new Docker Hardened Images team, Docker’s next big bet.
I tried to make sense of this work in a linear way, but it wasn’t. It was messy. We bounced between pillars, trying to make progress as pricing and packaging shifted and delayed.
Morale dropped. It was hard to watch because this was one of the best teams I’ve been part of. The Engineering Manager and I set up regular calls so the team could vent and know we were all in the same boat.
Product-wise, I wasn’t happy with how it ended. I was pulled from the team to focus on Docker’s new security bet, Docker Hardened Images, which was just getting off the ground. While it was an exciting opportunity, it left the team without a dedicated designer, and engineering had to make design decisions on their own.
Still, we got through it. It tested us.
Smooth seas don’t make good sailors.