Rakuten Group · iOS · Android

I don't get to choose the constraints. I choose what happens inside them.

Rakuten wanted to bundle free music into its mobile plans. The labels wouldn't allow unlimited streaming, so the plan launched with a five-hour monthly cap. This is what I designed inside that constraint.

Role UX DesignerUI Designer (separately)
Company Rakuten Group
Platform iOS · Android
Duration 12 months
Team 6PdM, PjM, Sales & Marketing, UX, UI, Engineering

01 — Problem Definition

Rakuten Music's growth
had plateaued

Subscriber numbers weren't growing at the rate the business needed. The question assigned to the team: how do we grow members?

Before jumping to solutions, I analysed how competitors had achieved scale — and one pattern stood out clearly.

Finding 01

Platform-owned services win

Apple Music grows through Apple devices. LINE MUSIC grows through LINE's 95M+ Japanese users. Services with platform distribution dramatically outperform standalone apps.

Finding 02

Rakuten has an untapped asset

Rakuten Mobile had millions of subscribers. No mechanism existed to convert them into Rakuten Music users. This was a zero-cost acquisition channel sitting idle.

Finding 03

I checked whether a cap would even hurt

Before the team committed to a time-limited plan, I pulled three months of play-time data on the users who mattered most — people already on both Rakuten Mobile and Rakuten Music. Almost none of them came close to five hours a month. A cap that most users would never reach isn't a restriction. It's a conversion trigger aimed only at the few who would.

02 — Strategy & Key Decision

The team had a direction. I made it a decision.

The free-tier model didn't start with me. The on-demand direction — instead of the ad-supported, shuffle-only model Spotify and Amazon use — was already the team's working assumption when the project landed on my desk. What I owned was the evidence: a full teardown of free-plan mechanics, upgrade paths, and pricing across Spotify, Apple Music, LINE Music, and Amazon Music. On-demand was the one thing LINE Music had dropped in the Japanese market — the analysis confirmed the instinct was right, not just convenient. That's what turned a shared leaning into a committed decision: the team aligned on on-demand not because it felt right, but because the evidence held.

Then the labels rejected unlimited streaming outright. Knowing "unlimited" wouldn't survive another round, the team went back with three options — unlimited, ten hours, five. Five is what cleared. The cap wasn't a design decision. It was a negotiation outcome I had to design around.

✕ Option A — Not Chosen

Shuffle + Ads model

Spotify / Amazon style

  • Ads degrade UX — contradicts Rakuten's brand quality standards
  • Shuffle-only feels like a downgrade for users coming from other services
  • Ad revenue infrastructure would require separate build investment
✓ Option B — Chosen

On-demand + Time limit

Any track, on-demand, up to a monthly hour limit

  • On-demand is a differentiator in the Japanese market (LINE Music had dropped it)
  • Data confirmed light users rarely hit the limit — so the cap feels invisible until it drives conversion
  • No ads = clean UX, consistent with brand

What I could and couldn't decide

I didn't choose the time-limit model, and I didn't set it at five hours — that's where the label negotiations landed, not where we wanted them to. What I could decide was everything downstream: whether a five-hour ceiling would feel like a wall or stay invisible. The rest of this case study is that part.

03 — Design Solution

How do you mark a track as restricted
without ever saying it's restricted?

Every label but one cleared the five-hour plan. The last one refused — their catalogue would be 30-second previews only — with one added requirement: users must never be able to tell which label was missing. This created a UX problem: users needed to know which tracks were free vs. 30-second preview, without the reason being explicit.

The solution: a Premium icon system that signals upgrade potential rather than restriction. I originated the concept and created wireframes; a UI designer executed the visual designs from those wireframes. I supervised and directed throughout — running an internal survey when the team disagreed on execution, and selecting the final variant based on recognition data.

Crown icon
Rejected

Crown

The crown read as "pay more, get the luxury tier." But the actual upgrade path was from the free Bundle Plan to the Rakuten Card/Mobile member plan — priced below Standard with no feature difference beyond price, and cheaper than the equivalent plans from major competitors. A crown oversold what upgrading meant: it wasn't a splurge, it was members claiming a price advantage they already qualified for. That mismatch was the wrong signal to send.

Star icon
Rejected

Star only

My hypothesis going in was that a plain star risked being read as "favorite" rather than "premium" — and the recognition test confirmed it. Multiple respondents described the star-only icon as looking like a bookmark or favorite marker, not an upgrade signal.

Star-in-circle icon
Selected

Star-in-circle

When the team couldn't agree, I ran a recognition test with 30 Rakuten Mobile users who didn't yet use Rakuten Music — an unbiased sample with no prior exposure to any of the three concepts. The result was decisive enough to end the internal debate immediately: star-in-circle was the clear majority pick, consistently read as "premium / good value" rather than "restricted" or "favorite." (Specific figures kept confidential, but the margin wasn't close.)

This was an internal recognition test, not an external user study — the release timeline didn't allow for one. I'd have preferred real users, but an unbiased internal sample was the fastest way to settle the disagreement without delaying launch.

Three Rakuten Music screens showing the in-app journey: track list, player during a 30-second preview, and the upsell Web View
The abstract flow, made concrete — track list, 30-second preview in the player, and the contextual upsell Web View.
The Premium circle-star icon applied consistently across track rows, album tiles, and playlist rows in the Rakuten Music app
The same Premium icon, applied consistently across track rows, albums, and playlists — a reusable system, not a one-off label.

01

Premium icon system

Icons placed on tracks, albums, and playlist rows — indicating Premium access without naming the excluded distributor. Tapping triggers a 30-second preview and opens a web view upsell. Originated by me, variants selected via internal survey after team disagreement.

02

End-to-end flow ownership

I designed the complete user journey across platforms: Rakuten Mobile LP → sign-up → onboarding → in-app experience → upsell moment. No other role owned this cross-platform continuity.

03

Contextual upsell trigger

Upsell surfaces at the natural moment of desire — when a user taps a premium track mid-listen — rather than interrupting discovery. This screen appears only after users have already signaled intent to upgrade.

04

Cross-functional alignment

Worked closely with the PdM through continuous alignment, and bridged between the UI designer and engineering on spec handoff.

04 — Impact

The channel brought them in.
The design decided who upgraded.

The bundle plan launched into Rakuten Music's strongest growth period. These results came from channel strategy, pricing, and design working together — each caption below marks the specific link in that chain my design work owned.

+55.2%
Member growth YoY

Growth concentrated in the bundle channel — I designed its entire entry experience, from carrier LP to onboarding.

+17.7%
MAU YoY

Engagement with the on-demand free tier — the model my play-time analysis of light users helped validate.

+3.2pt
Free → Paid conversion

Most free users never hit the playback cap — conversion was driven by the Premium icon system and contextual upsell I designed.

+4.9%
Paid subscribers YoY

Downstream of the conversion lift — sustained by the upgrade flow I designed end to end.

05 — End-to-End Flow

Four parties, one experience that had to look simple

Every constraint in this project came from somewhere else — a label's catalogue rights, Mobile's ownership of the plan's messaging, engineering's capacity. None of those parties were talking to each other by default. My job was translating between them so the user never saw the seams.

Catching what nobody had specced for

During internal QA, I found a problem no one had specced for: one label's tracks — now 30-second previews only — were flooding the real-time ranking, the first thing users saw on Home. For Bundle Plan users, the top of the app looked like a wall of upgrade prompts. I flagged it, got PM sign-off, and had a spec for a filtered ranking — excluding preview-only tracks for this segment — in front of engineering within days. It shipped in under two weeks.

Negotiating for visibility inside someone else's pitch

Rakuten Mobile's "Saikyo Plan" bundled dozens of perks — Music was one line among them, and Mobile's own landing page treated it that way. Getting real visibility there meant negotiating directly with the Mobile team, on a page I didn't own and couldn't design myself.

Designing the decision, not just the name

I named it "Bundle Plan." Having watched an earlier Rakuten tier get renamed under legal pressure after launch, I went into this project treating naming as a design decision, not an afterthought. I brought the PM three candidates: one referencing the ecosystem angle, one naming the specific partner service directly — a deliberate decoy, since it would break the moment a second partner joined — and "Bundle Plan," short enough for ad copy, plain enough to survive legal review, and generic enough to scale as the partner list grew. The comparison did the work; "Bundle Plan" was the obvious choice once the other two were on the table.

After an early test build slipped the original release date, I started a self-initiated priority tracker — shared with the PM — and ran weekly syncs with engineering to keep delivery visible going forward.

06 — Reflection

What I'd revisit

No project lands perfectly. Looking back, there are areas I'd approach differently — and lessons that shaped how I work now.

What didn't go as planned

Onboarding was scoped out. Under pressure to hit the release date, anything beyond core functionality was deprioritized. But for bundle plan users, onboarding wasn't a nice-to-have — it was the only place to explain what the Premium icon system actually meant. We tried to cover it on the website, but that's not where users are when they need to understand it.

What I'd do differently

At the time, I didn't fully grasp the importance of onboarding. After moving to the US and using American apps daily, I noticed how much more intentionally onboarding is designed here compared to Japan. Instead of "figure it out as you go," users are shown exactly what experience awaits them — which builds desire before they even start. If I'd had that perspective then, I would have fought to keep onboarding in scope, framing it not as an extra feature but as the only place where the plan's value could actually land.

More Case Studies

02
UX Strategy Discovery B2C

Rakuten Music — UX Redesign

Reframed discovery from algorithmic recommendations to a curation-led model across an 8-year product evolution.

Lead UX 2017 — 2025
03
AI Workflow Systems Design Solo Build

How I Redesigned My Design Process with AI

Rebuilt my design-to-ship workflow around a two-gate, verification-first system — then proved it building and shipping an AI product alone.

Solo-Built 2026
← Back to all case studies