DESIGN SYSTEM · IBM
Cloud Object Storage Browser
From a product-specific fix to a reusable component shipped into IBM's Carbon design system.
ROLE
Design Lead
TOOLS
Figma, Adobe Illustrator
DURATION
4 months
OUTPUT
Carbon design system component
I found the problem. I also built the solution.
OVERVIEW
While redesigning IBM Cloud Data Engine, I noticed something: every IBM product that integrated with Cloud Object Storage had its own ad-hoc implementation of the same basic browsing interaction. The result was a fragmented, inconsistent experience — users trying to locate a storage bucket in one IBM product encountered a completely different interaction pattern in another.
Rather than solving it just for Data Engine, I made the case for a shared component, one that could be adopted across IBM's product suite and integrated into Carbon, IBM's internal design system. This case study is as much about design system thinking and cross-functional advocacy as it is about UI design.
MY ROLE
How this started
I was the design focal for this project from inception, which means I both identified the need and drove the solution. This wasn't a project handed to me by a product manager. I surfaced it, scoped it, got stakeholder alignment, and led the design through to design system integration.
The dual audience for this project, end users who need to browse COS intuitively and product teams across IBM who need to integrate the component reliably, shaped every design decision I made.
USERS
Designing for SQL developers in a data lake context
The primary user persona for the COS Browser within IBM Data Engine is Jenny, an SQL Developer working with data lakes.
Jenny's job
Jenny writes SQL statements to prepare unstructured or messy data for analysis. She works with ad-hoc queries to validate results, then automates them via API. A key part of her workflow involves defining metadata table structures for data stored in Cloud Object Storage, which means she needs to navigate COS frequently, within the context of her existing workflow.
KEY INSIGHT
Jenny doesn't want to leave her current task to manage storage. She wants COS browsing to be an embedded capability within the tools she's already using, not a context switch.
RESEARCH & BENCHMARK STUDY
Three things breaking the experience
Before designing, I spoke directly with development stakeholders across multiple IBM products to map their COS integration patterns, then ran an initial benchmark study. Three issues surfaced consistently.
01 — Discoverability failure
Users couldn't identify what data was queryable from COS. The COS URI-based querying model was unfamiliar — they expected named tables, not storage paths.
A Hopscotch tour existed to surface helpful SQL sample statements, but it failed to trigger reliably, hiding useful features behind a broken entry point. The product had helpful features that users never discovered.
03 — Broken onboarding
"Include a UI element like a side panel that enables users to connect to resources and find data they can query, similar to what AWS Athena and Google BigQuery offer."
— Stakeholder research synthesis
[ Benchmark study findings ]
Annotated user flow with pain points highlighted
02 — Missing resource explorer
AWS Athena and Google BigQuery both offer persistent side panels for browsing connected data sources. IBM offered nothing comparable, leaving users working blind.
DESIGN APPROACH
Component-first thinking
The core design challenge was not just creating a good browsing UI, it was designing something flexible enough to work across IBM's product ecosystem, while remaining consistent and predictable for users.
The browsing model
Depending on the use case, a user might only need to select a storage bucket, or they might need to navigate all the way down to specific objects or prefixes within a bucket. I designed the component to be depth-configurable: product teams integrating it can specify whether to stop at bucket level or allow full object/prefix exploration. All text strings are also fully customizable per product context.
[ Browsing hierarchy — bucket → prefix → object navigation ]
I established two non-negotiable principles from the start:
System-compliant
AWS Athena and Google BigQuery both offer persistent side panels for browsing connected data sources. IBM offered nothing comparable, leaving users working blind.
Context-agnostic
Users couldn't identify what data was queryable from COS. The COS URI-based querying model was unfamiliar; they expected named tables, not storage paths.
Four variants, one set of rules
IBM's Carbon design language defines specific UI containers for different interaction contexts. I designed four variants of the COS Browser, each with explicit usage rules, not guidelines, to ensure the component was used correctly across products.
COMPONENT VARIANTS
VARIANT
WHEN TO USE
CONSTRAINT
Modal
Side panel
Tearsheet
Inline
Bucket-level selection only, lightweight context
Bucket-level selection only, lightweight context
Layered workflows where a tearsheet is already active
Embedded within a page configuration flow
Cannot go deeper than bucket level
Cannot be used when a tearsheet is already open
Only valid stacked above another tearsheet
No overlay behavior, fully in-context browsing
WHY STRICT RULES MATTER
A shared component that's misused by product teams creates the same inconsistency problem it was designed to solve. Usage rules are part of the design.
Tearsheet
Side panel
Side panel
Inline
DE3SIGN SYSTEM INTEGRATION
Shipping into Carbon
Getting a component into IBM's Carbon design system is not just a design exercise, it's a cross-functional negotiation that requires treating the design language team as a distinct stakeholder with real constraints.
I produced a full documentation package that covered:
Component anatomy — labeled breakdown of every part with naming conventions aligned to Carbon standards
Usage guidelines — explicit do/don't patterns for each variant, written to prevent misuse by product teams unfamiliar with the nuances
Layout specifications — exact spacing, hierarchy rules, and customization parameters
Edge case behavior — empty states, long bucket names, loading states, and permission errors
[ Component anatomy diagram ]
Labeled breakdown of every part with Carbon naming conventions
[ Do/Don't usage guidelines ]
Modal variant do/don't examples from the final documentation
KEY LEARNING
Designing for a design system requires a different kind of empathy, not just for the end user, but for the developers and designers who will implement the component months or years later, without you in the room. Documentation is part of the UX.
TESTING FRAMEWORK
Setting up the next validation cycle
After delivering the component to Carbon, I defined a structured testing plan for product teams integrating the component in their own contexts. The framework covered four dimensions:
Discoverability
Can users find the component within the page context of the specific product they're using?
Task success
Can users complete the COS selection task i.e bucket, object, or prefix, without assistance?
Efficiency
Does the component reduce time-on-task compared to what existed before?
Information clarity
Is what's displayed sufficient for users to make confident selections?
This framework was documented and handed off as part of the design system package, so individual IBM product teams integrating the component would have a ready-made validation plan for their specific implementation context.
REFLECTIONS
What I'd take forward
The most important skill this project demanded was knowing when to zoom out. It would have been easy and faster to solve the COS browsing problem just for Data Engine. But the underlying issue was systemic, and a product-level fix would have left the broader ecosystem just as fragmented.
Advocating for a design system component requires a different kind of communication than advocating for a feature. You're not just persuading a product team, you're making a case to the stewards of a shared standard. Learning to speak that language, and to treat Carbon compliance as a constraint that makes the design better rather than just harder, was the defining growth area of this project.