OneData
01 PROJECT SUMMARY
The brief sounded like a portal. The real job was defining the product behind it.
OneData was conceived as a one-stop platform for finding and accessing data products across Rakuten’s wider cloud ecosystem. Existing capabilities lived across different services, menus and technical contexts; the opportunity was to make them legible as one coherent offer.
Operating from Rakuten India, the group’s product and innovation hub, I worked as the principal designer and stretched well beyond interface design. I led discovery, shaped the product model, aligned stakeholders, wrote user stories and PRD-level requirements, scoped the MVP and drove the experience into high-fidelity flows. In practice, it became a Principal Designer role with a product-owner-shaped shadow.
02 PROBLEM
Rakuten had data capabilities. What it lacked was a usable front door.
Users had to navigate a scattered service landscape to understand what existed, what they already had access to, and where to go next. That fragmentation made service discovery harder and placed organisational knowledge ahead of user intent.
Data and machine-learning pipelines were important but fragmented and difficult to manage at scale.
Users needed a clearer distinction between all services, subscribed services and data-specific offerings.
The MVP had to balance an ambitious platform vision with engineering, design-system and delivery constraints.
New patterns still needed to feel native to Rakuten Cloud and the Horizon Design System.
03 MY ROLE
I was designing the system, but also helping decide what the system should be.
Principal Designer, India. End-to-end ownership across product discovery and experience definition.
Ran discovery and synthesised stakeholder needs into a shared product model.
Defined information architecture, user flows, service-discovery logic and high-fidelity experience patterns.
Created user stories, feature scope and PRD-level requirements to support product and engineering decisions.
Aligned with engineering, product stakeholders and Horizon Design System owners across the MVP roadmap.
04 OUTCOMES
The most useful outcome was clarity: a broad platform ambition became something teams could build and debate.
A coherent product modelConnected All Services, My Services and a dedicated OneData marketplace into one discoverable system. | An MVP teams could reason aboutTranslated the vision into prioritised scope, user stories, flows and delivery dependencies. | A credible enterprise UX directionExtended Rakuten Cloud patterns without creating an isolated sub-product or design language. |
The initiative was later paused during build-versus-buy discussions, so I do not claim adoption, revenue or usage metrics that were never realised.
05 INTENT
Shift the question from “where is the tool?” to “what do I need to get done?”
The experience needed to work for users with very different levels of technical knowledge, from business users exploring available services to data engineers moving directly into pipelines and platform actions. OneData therefore had to behave less like another nested menu and more like a marketplace for data capabilities.
The product intent was simple: make discovery, evaluation and access feel like one journey rather than three separate systems.
06 CHALLENGES
Enterprise platform work is mostly a negotiation between ambition, architecture and ownership.
Fragmented mental models: infrastructure, cloud services and data products were organised around internal structures rather than user intent.
Scope pressure: the backlog included direct access, global search, service detail, dashboards, empty states, sandbox concepts and more.
Cross-team dependencies: UX, API work, infrastructure, system architecture, UI development and QA moved on different clocks.
System governance: OneData needed a distinct role while remaining recognisably part of Rakuten Cloud.
Roadmap planning exposed dependencies across product, UX and engineering instead of treating design as a parallel track.
07 APPROACH
Discovery first. Screens only after the product’s logic stopped wobbling.
I used stakeholder input, existing platform behaviour, user stories, competitive references and Horizon constraints to frame the product before polishing UI. The working question was not “what screen comes next?”, but “what decision is the user trying to make, and what information or action unlocks it?”
Mapped key user types and jobs across business users, data engineers, analysts and platform engineers.
Modelled the journey from service discovery to service evaluation, subscription and operational access.
Converted findings into a feature-scope matrix with availability, priority, rationale and references.
Reviewed designs against realistic data, scalability, empty states, error handling, hierarchy and terminology.
08 KEY WORK / SOLUTIONS
The interface work followed four product decisions, not a procession of prettier screens.
1. Reframed the information architecture
The existing menu treated OneData as another nested destination. I proposed a clearer hierarchy that gave it a recognisable place inside Rakuten Cloud while preserving the broader service model.
2. Connected discovery, ownership and action
The user flow separated three useful modes: browse all services, return to subscribed services, or enter OneData for data-specific discovery. Service details then became the decision surface for use cases, screenshots, pricing and access.
3. Made MVP trade-offs visible
I turned a sprawling wish list into a prioritised feature model. Direct service access and global search were treated as core needs, while concepts such as dashboards and sandbox access could be graded out of scope for the MVP. Even empty states, illustrations and icon needs were tracked as product dependencies rather than late polish.
Feature scope mapped availability, priority, rationale and references.
Dashboard and empty-state requirements made explicit rather than hiding them in UI cleanup.
4. Designed with the system, not against it
High-fidelity work reused Horizon components and Rakuten Cloud patterns wherever possible. New structures were introduced only where OneData genuinely needed a different behaviour, such as marketplace discovery, subscription states, quick actions and data-focused service landing patterns.
Representative high-fidelity coverage across the service journey.
09 TRANSFORMATION
The shift was not “old screen to new screen”. It was scattered capability to a coherent product model.
Before Data services were distributed across product boundaries, menus and technical contexts. | Shift OneData introduced a clearer marketplace model, shared journey and explicit service hierarchy. | After Teams had a defined MVP concept connecting discovery, evaluation, subscription and direct action. |
That transformation matters even though the initiative did not reach full production. The design work created a shared language for what OneData was, who it served and how it should fit inside the Rakuten Cloud ecosystem.
10 LEARNINGS
A sound product direction can still lose to timing, governance or strategy. That is part of the work.
Create organisational pull earlyWhen a platform crosses ownership boundaries, stakeholder alignment is not ceremony. It is part of the product architecture. | IA is product strategyNaming, grouping and access models shape comprehension and adoption long before visual polish becomes relevant. | Principal design lives between disciplinesDiscovery, prioritisation, requirements and delivery alignment can create as much leverage as the interface itself. |
OneData was eventually paused while Rakuten weighed build-versus-buy options. The project sharpened my view that senior product design is partly about making trade-offs visible and keeping user evidence alive when decisions move upward.
