DataVerse - Making enterprise data findable, trustworthy and governable
RAKUTEN
UNIFIED DATA CATALOG / DATAVERSE
2026
Project Summary
PROJECT SUMMARY The brief looked like a catalogue. The real job was to make scattered enterprise data legible.
Unified Data Catalog, also known internally as DataVerse, was conceived as a central repository for Rakuten data teams to discover, understand, request and govern datasets across a distributed global ecosystem.
I joined as the principal designer from India and gradually moved beyond UX into product definition: shaping discovery, researching the market, documenting requirements and turning stakeholder ambiguity into a coherent product model.
Problem
Data existed everywhere. Confidence in finding the right data did not.
Teams relied on fragmented, often rudimentary ways to locate and understand data products. The harder problem was not merely search: users needed to know what a dataset meant, whether it was fresh, who owned it, whether they could use it and how to request access.
• Discovery was fragmented across systems, teams and tribal knowledge.
• Metadata quality was inconsistent, leaving users unsure whether they had found the right dataset.
• Access requests and governance steps were cumbersome and could spill into tools such as Jira.
• Global teams needed a shared view of ownership, lineage, sensitivity, freshness and intended use.
My Role
I started as the designer and ended up helping define what the product should be.
As Principal Designer, I owned the end-to-end UX direction while operating as a first-time, informal Product Owner for a substantial part of discovery.
• Planned and documented qualitative discovery with senior stakeholders across Europe, China, Japan and India.
• Mapped the core user roles: Data Owner, Data Consumer and Data Approver.
• Benchmarked emerging catalog products including Atlan, Alation and OpenMetadata.
• Worked through product briefs and PRD-style requirements with product leadership.
• Defined information architecture, workflows, wireframes, prototypes and handoff patterns.
• Created a local design workflow aligned with Rakuten’s centrally governed design language.
Outcomes
The strongest outcome was clarity: the organisation could see what a unified data experience needed to become.
Validated directionA coherent catalogue concept was shaped through stakeholder interviews and prototype feedback. | Defined product modelDiscovery, metadata, governance, access and lineage were brought into one connected experience. | Executive visibilityThe prototype reached teams beyond the original department and earned strong internal interest before funding constraints paused development. |
The project did not reach production. Rather than dress that up, this case study treats the validated concept, cross-functional alignment and product definition as the evidence.
INTENT
The goal was not another data screen. It was a dependable front door to Rakuten’s data estate.
The product intent was to let people answer a sequence of practical questions without detective work: What data exists? Is this the right dataset? Can I trust it? Who owns it? Can I access it? What happens upstream and downstream?
• Centralise dataset discovery without flattening domain context.
• Expose useful metadata at the moment of decision, not buried in documentation.
• Make governance visible enough to build trust without turning the interface into a policy manual.
• Support both data contribution and consumption, rather than optimising for search alone.
CHALLENGE
The difficult part was not UI density. It was negotiating a shared definition of ‘good data’.
A global operating model. Different regions and teams carried different assumptions about ownership, access, metadata and governance.
Incomplete metadata. Users repeatedly asked for clearer business context, technical descriptions, freshness, lineage and source information.
Governance friction. Broad requests, sensitivity rules and approval paths needed structure without making access unbearably bureaucratic.
A moving product boundary. Discovery quickly expanded into enrichment, classification, requests, approvals and data lineage.
APPROACH
Discovery came first because polishing the wrong catalogue would have been a very expensive form of neatness.
I used a deliberately product-heavy design process: understand the ecosystem, define the users, interrogate the market, translate findings into requirements, then prototype and refine with the people expected to use or govern the platform.
1. Frame Problem statement, product brief, target users and business context.
2. Research Stakeholder interviews and competitor review across modern data-catalog products.
3. Structure Information architecture, user roles, metadata model and key workflows.
4. Prototype Medium-to-high fidelity flows for discovery, enrichment, classification, requests and lineage.
5. Validate Iterative reviews, usability feedback and prioritisation before design handoff.
KEY WORK/ SOLUTIONS
The catalogue became a system of decisions, not a warehouse of table names.
Discover Data
Search, filtering and dataset summaries gave consumers a structured way to narrow thousands of assets and assess relevance.
Dataset intelligence
Details exposed ownership, quality, freshness, usage signals and lineage so users could judge trust before requesting access.
Enrichment & classification
Owners could add metadata, classify sensitivity and sharing rules, and prepare datasets for governed use.
Request workflows
Consumers and approvers could see request status, sensitivity context and workflow details in one place.
TRANSFORMATION
The shift was conceptual: from scattered access rituals to one shared product language for data.
There was no single incumbent interface to redesign. The transformation was from fragmented behaviours and partial tools toward a unified operating model.
FromKnowing who to ask, where to look and which system might contain the answer. | ToA catalogue that made datasets searchable, explainable and comparable. | And furtherA governed workflow connecting ownership, classification, access, lineage and ongoing stewardship. |
LEARNINGS
The project was paused, but it permanently changed how I approach product design.
Get users in before the interface hardens. The most valuable progress came from interviewing the people who owned, consumed and approved data before treating requirements as settled.
Enterprise UX is organisational design in disguise. Metadata, permissions and lineage are not merely interface features. They encode who is responsible, who decides and how trust moves through the organisation.
A strong concept still needs an economic runway. The product earned enthusiasm and validation, yet budget constraints ultimately stopped development. Product quality and organisational viability are separate gates.
