Scaleway Bucket Versioning
Redesigning bucket versioning for adoption and trust.
Summary
This case study explores how we brought new life to Scaleway’s bucket versioning feature by addressing a critical UX gap. By surfacing versioning during the bucket creation flow, we made it easier for users to protect their data—while unlocking real business value.
The project shows how thoughtful UX decisions can solve real user pain points and transform an underused feature into a strategic lever for growth.
Timeline
December 2O23 - February 2024
Team
1 Product Designer, 1 Egineering Manager, 1 Product Manager, 1 UX Researcher, 5 Engineers
Role
Sole Designer — led the end-to-end design process: from exploring user needs and benchmarking competitors, to defining priorities, designing the experience, collaborating with engineering, and measuring success after release.
Key results
Better data control for users
New growth opportunities for the business
+15% versioning adoption in the first 3 months after release
Context
Versioning is key for protecting data, recovering deleted objects, and meeting compliance needs. At Scaleway, the feature existed, but was mostly invisible. It had to be manually activated deep in the settings—far from where users make critical setup decisions. As a result, adoption was low, and many users never took advantage of it.
Problem
When versioning isn’t activated, data can be lost, compliance becomes harder to ensure, and storage usage stays flat. This wasn’t just a UI issue—it exposed real risks for both users and the business.
Objectives
The goal was twofold: help users find and activate versioning more easily, and prepare for upcoming lifecycle rules to support cost management. On the business side, we aimed to boost adoption, increase storage usage, and unlock new revenue opportunities. In short, the challenge was to turn an underused feature into something useful, visible, and valuable.
User research
We spoke with users, reviewed support tickets, and looked at usage data.
Three clear pain points came up again and again:
Key finding #1
Poor visibility led to low activation
It was hidden deep in the settings.
Many users never saw it, never enabled it, and ended up losing data they couldn’t recover.
Key finding #2
People feared rising storage costs
Without lifecycle rules, users weren’t confident enabling versioning.
They didn’t want to store unlimited versions with no way to manage them.
Key finding #3
The UI gave no feedback
Users couldn’t see which objects had versions or had been deleted.
They didn’t know how to interact with versioning once it was on.
These insights shaped our solution.
Competitive landscape
As part of the research, we looked at how other major cloud providers handle versioning. While most offer strong features—like visible version history, lifecycle automation, and flexible retention rules—none enable versioning by default. At Scaleway, versioning was available but hard to access, lifecycle rules didn’t exist yet, and there was no clear way to view or manage object versions. These gaps helped us identify where the experience could be improved, and where users might feel stuck.
Challenges
This project wasn’t just about UI—it was about driving adoption for a hidden feature, with limited visibility and incomplete functionality. Here’s what we needed to solve.
Increase visibility without creating friction
We needed to integrate versioning naturally into the user flow—without overwhelming the setup process.
Encouraging adoption before the full feature was live
Lifecycle rules weren’t available yet, but we needed to help users activate versioning early, and trust that more was coming.
Keep the experience consistent and permission-aware
We had to reflect IAM logic clearly, without creating confusion or support overhead.
Constraints
We also had to work within the boundaries of the existing system, roadmap, and team capacity.
Lifecycle rules not ready
We had to design with them in mind—ensuring the UI would support automation later—without having them in place at launch.
Missing components in the design system
Some elements, like the Tip alert, didn’t exist. We had to design, validate, and document them for reuse.
Tight roadmap and limited engineering capacity
We had to scope carefully to fit within available dev time and avoid delaying higher-priority work.
Solution
Enable versioning from the start
We made versioning part of the creation flow. This small change made the feature visible at the right time, during setup. As a result, more users enabled it from the start.
Versioning is now part of the bucket creation flow, making it easier to activate from the start and improving adoption.
Quick access to version history
A toggle lets users show or hide object versions in one click. To support first-time users, a small popover highlights the toggle and explains what the view displays. This makes versioning easier to discover and understand—without breaking the flow or relying on documentation.
A popover explains that versioned objects exist, and invites users to turn on the toggle to see them.
Once the toggle is on, a new message introduces the version view and explains how object versions are grouped and displayed.
Browse versions with clarity
We added a tree view to show object versions. Each object now groups its versions in a clear view, making it easy to explore or restore them. When deleted, a marker shows the object is gone—but older versions stay accessible. Markers only appear when the toggle is on, and reflect how versioning works under the hood.
The tree view displays all available versions of an object, grouped under its filename. Users can explore, retrieve, or delete specific versions directly from this view.
A close-up view of the table.
When versioning is enabled and object versions are shown, a delete marker appears to indicate that the latest version was deleted. Previous versions remain accessible.
A clearer message at activation
We clarified the versioning activation message. The old modal focused only on storage costs, which created doubt. We updated it to include key benefits—like data protection and recovery—so users feel more confident enabling versioning.
From the bucket settings, users can activate versioning and immediately see its impact—covering data protection, recovery, and storage behavior.
V1
V2
Before vs. after: shifting the focus from cost to value.
Thinking about permissions
Some actions in Object Storage—like enabling or suspending versioning—depend on IAM permissions. We made sure the interface reflects that. When a user doesn’t have the right role, the action is disabled, and a tooltip explains why. This reduces confusion, builds trust, and helps keep the experience consistent across teams.
A clear view of versioning status and action.
Users can see whether versioning is enabled, suspended, or disabled—and take action directly from the settings.
When permissions are missing, the UI explains why.
The action is disabled, and a tooltip helps users understand that they need the right IAM role to manage versioning.
Manage versions with lifecycle rules
We added lifecycle rules to help users manage versioned data. They can now archive older versions, move them to cold storage, or automatically delete what’s no longer needed. This gives them better control over data retention while helping reduce costs.
The Lifecycle Rules tab introduces users to automated object management. When no rules are defined, the empty state highlights the benefits of lifecycle policies for cost optimization and retention control.
Users can create a lifecycle rule that applies to all objects in the bucket or target specific objects using filters like tags or prefixes—offering flexibility in how data is managed.
Lifecycle rules support multiple actions, such as expiring or archiving objects. Users can configure each action by selecting a rule and setting the number of days after which it should be triggered.
A clear overview displays all active lifecycle rules, making it easy to review, edit, enable/disable or delete existing policies and ensure consistent data management over time.
Users can expand a rule from the list to view its full configuration at a glance—including scope, actions, and timing—without leaving the page. This helps quickly review policies and understand their impact.
Cleaning up small UX issues along the way
Before I joined Scaleway, the interface used left-aligned toggles to activate rule options. That pattern didn’t match how users interacted with the form. Toggles suggest immediate change, while here, users were selecting options to configure. I replaced them with checkboxes, which better reflect selection and match common form behavior. This also made the layout easier to scan and more consistent—especially when showing related inputs like duration or storage class.
Before
After
The initial design used left-aligned toggles, suggesting instant actions and breaking layout conventions. In the improved version, checkboxes and aligned inputs offer a clearer, more consistent experience for selecting and configuring lifecycle rules.
Design system contribution
I designed a small “Tip” to appear during versioning setup. It explains what lifecycle rules do and how they help control storage costs. The component isn’t live yet—it will be shown once lifecycle rules become available. The goal is simple: help users understand the value of versioning and feel more confident enabling it. This “Tip” didn’t exist in the design system, so I created and documented it to make sure it’s ready when needed.
Designed and delivered to support contextual guidance within forms—this variant was created as part of the versioning project and is now available across products.
V1
V2
The first version of the UI focused on core versioning activation. In the next iteration, we will introduce a contextual “Tip” promoting lifecycle rules—helping users understand how to manage costs and see the long-term value of enabling versioning.
Results and impact
+15% versioning adoption in the first 3 months after release
Before the redesign, usage was low—users weren’t finding or activating the feature
Analytics and feedback both pointed to the same gap
What worked:
Adding versioning to the bucket creation flow made a clear difference
Early exposure led to stronger activation
Highlighting the benefits of versioning during setup helped users feel more confident about turning it on
What’s still in progress:
Lifecycle rules haven’t launched yet, which limits cost control use cases
Tree view and version display are not live, but early feedback shows strong interest
More impact is expected once these features go live.
Takeaways
This project helped me grow as a product designer.
Here’s what I took away from it:
People won’t use a feature if they can’t find it. Visibility matters.
Good design can solve real problems without adding complexity.
Timing is key. A well-placed message or setting makes a big difference.
Design systems need to adapt to real use cases. I had to build a new component to support this flow.
Thinking long-term helps. I made sure the UI would support future features like lifecycle rules.
Final thoughts
One key limitation was the gap between versioning and lifecycle rules. Versioning went live first, but the rules came later. This slowed adoption, especially for users focused on cost control. We used in-product messaging to explain what was coming, but without automation, some teams stayed cautious. Looking back, I would push to align both releases and add light onboarding to better explain the value from the start.