01 Business & customer problem
"Japan has the highest bar for product quality of any market Remitly had entered. It also had the strictest regulatory requirements, the most culturally specific UX expectations, and a $14B remittance opportunity that competitors had already been building toward for years. We had one shot to get the first impression right."
Japan is the world's third-largest economy — and one of the last major remittance markets Remitly hadn't entered. By 2023, 3.4 million foreign nationals were living in Japan, with immigration growing at 110–125k people per year. The outbound remittance TAM had reached $14B and was projected to grow to $22B by 2028. The corridors were clear: China, the Philippines, Vietnam, Brazil, India — exactly the markets Remitly already served on the receive side.
The infrastructure groundwork was already laid — Remitly had acquired a Japanese money transfer license (Fund Transfer Service Provider Type II) and opened a local MUFG bank account. What remained was building the product. That meant designing a send experience from scratch for a market with its own payment rails (Furikomi bank transfer), its own regulatory framework (Japan's Payment Services Act), its own KYC requirements ($0-threshold eKYC via a local vendor), and its own deeply held expectations about how software should behave.
Problem
$14B
Japan outbound remittance TAM
3.4M
Foreign nationals living in Japan
$13.5M
Projected gross profit in 3 years post-launch
02 Context & constraints
A greenfield launch with non-negotiable regulatory walls
Launching Japan Outbound wasn't an iteration on an existing product — it was a market entry. Remitly's core send flow existed, but almost every surface required Japan-specific decisions: new payment rails, new KYC requirements, new regulatory disclosures, and a user base whose primary language and cultural UX expectations were fundamentally different from every market Remitly had previously served.
The constraints were layered in a way that made sequencing critical. Some were hard regulatory requirements with no design flexibility. Others were technical dependencies — the KYC vendor integration, the Furikomi payment method, the Liquid eKYC platform — where engineering constraints shaped what was designable. And underneath all of it was a cultural constraint: Japan has among the lowest tolerance for friction and the highest expectation of precision of any consumer market in the world.
4 forces that defined the design space
Regulatory: Japan's Payment Services Act
Remitly's Japan entity (FTSP Type II license) required mandatory eKYC before any first transaction — at $0 threshold, not the graduated risk-based approach used in other markets. Every sender had to complete identity verification before sending a single yen. The PSA also mandated specific disclosures, T&C, and privacy policy language visible before account creation. None of this was optional, and none of it could be simplified away.
Technical: Liquid KYC integration
Remitly partnered with Liquid, a Japanese KYC vendor, to handle eKYC. The integration had to happen inside a webview overlaid on the Remitly app — the customer couldn't leave the app experience. Two distinct KYC flows existed within Liquid: one for citizens and permanent residents, another for non-permanent residents. The UX transition between Remitly native screens and the Liquid webview, and back again, was a design problem with no established internal precedent.
Cultural: Japan's UX expectations
Japanese financial product users expect precision in every detail — currency display (JPY with no decimals, always left-anchored with 1 JPY = X format), information density that respects rather than simplifies, and zero tolerance for ambiguous states. Competitors like Wise and local providers had years of head start. A generic Remitly experience translated to Japanese would not be sufficient.
Operational: Multi-team coordination
Japan Outbound spanned 4 product teams: RUX (sender details, residence status, occupation), MMX (calculator, send flow), I&T (KYC integration), and CCX (onboarding). Legal, Compliance, Finance, and Pricing all had review rights. As the designer across all customer-facing surfaces, I sat at the intersection of every one of these workstreams simultaneously.
What made Japan different from every other market Remitly had entered
Most Remitly market expansions involved enabling existing corridors — turning on receive destinations, configuring pricing, updating compliance rules. Japan was a send-country launch, which meant redesigning the front half of the product: who the sender is, how they prove it, what information they're asked for, and in what language and format. The FX display convention alone — 1 JPY = X foreign currency, with JPY on the left, no decimals — was a Japan-specific requirement that touched every surface where an amount appeared.
03 My role
Sole designer across the full customer-facing surface
I owned the end-to-end customer experience for Japan Outbound — from the landing page calculator through KYC completion and send summary. That meant working across four product teams simultaneously, each with its own PM, engineering lead, and compliance dependencies. In practice, it meant being in four workstreams at once and ensuring that the decisions made in each one didn't create contradictions in the others.
-
Calculator and send flow — JPY-specific display conventions, Furikomi as sole payment method, single FX/single fee calculator variant, transaction limit error states (50 JPY min, 1M JPY max)
-
Sender Details — phone number defaulting to JP country code, occupation collection (auto-suggest dropdown aligned with global list), residence status screen (net-new, no internal precedent, compliance sign-off required)
-
KYC/Liquid integration UX — the transition into and out of the Liquid webview, the pre-KYC preparation screen, sender detail confirmation post-KYC, handling dual scripts (Kanji for Japanese names, Latin for foreign names)
-
Localization — Japanese-language UI decisions, script handling across all screens, locale-aware occupation dropdown
-
Recipient details — China-specific additions required for Japan send (province collection for high-risk border regions, Chinese character to Pinyin romanization flow)
-
Send summary — Japan-specific flow differences (summary appears only post-KYC, no payment method selection screen, occupation editable on Nth transaction)
The most structurally novel design problem — and the one with the most cross-functional friction — was the residence status screen. Japan's dual KYC flow (one for citizens and permanent residents, another for non-permanent residents) required collecting residence status before triggering the Liquid integration. This was a net-new screen with no equivalent anywhere else in Remitly's product. It needed compliance and legal sign-off on the content, engineering alignment on data routing, and a UX that made a regulatory classification question feel like a natural part of onboarding rather than a bureaucratic gate. I'll cover that in detail in the process section.
04 Discovery & framing
What research revealed about designing for a market you haven't designed for before
Discovery on Japan Outbound had two tracks running in parallel: understanding the regulatory and technical requirements (which were extensive and non-negotiable) and understanding the cultural and competitive UX landscape (which was equally demanding but more interpretable through design).
3 things discovery confirmed
Japan doesn't forgive ambiguity
Japanese financial product UX sets a precision standard that most Western fintech products don't meet. Every number must be formatted correctly. Every error state must be specific. Every transition must be intentional. The competitor screens in the PRD showed a level of information density and typographic precision that made it clear: a generically localized Remitly experience would read as foreign in a way that undermined trust from the first screen.
The KYC moment was make-or-break for conversion
Unlike other markets where KYC only triggered at risk thresholds, Japan required eKYC before the first transaction — full stop. This meant every new sender would encounter the Liquid integration during their first send attempt. If that transition felt abrupt, opaque, or broken, a significant share of first-time users would never complete their first transfer. The UX of the KYC handoff was as commercially important as the send flow itself.
Residence status was the hardest classification problem
Japan's immigration structure is unusually complex — the country distinguishes between citizens, permanent residents, and multiple categories of non-permanent residents with different visa types. The two Liquid KYC flows required collecting residence status upfront to route correctly. But "are you a permanent resident?" is not a simple yes/no for a population that includes work visa holders, student visa holders, and long-term residents who aren't legally permanent. The screen needed to be both accurate and legible.
Key insight
Japan Outbound wasn't primarily a localization problem. It was an identity verification problem that happened to also require localization. The KYC flow and the residence status classification were the design problems that would determine whether the product worked at all. Everything else — currency formatting, language, FX display — was necessary but secondary.
05 Strategic design bets
The non-obvious calls — 4 decisions that shaped the product
Bet 1: Move the Liquid KYC flow to Step 3 — eliminating a dedicated sender details screen
Standard approach:
One collection flow that activates at the mandatory threshold — clean, easy to build, one surface to maintain
Japan approach:
Skip the sender details screen entirely — let Liquid KYC scrape the ID card and auto-populate those fields, saving the customer from manual data entry
Since Japan required $0-threshold eKYC anyway, every sender would go through Liquid before their first transaction. Liquid's ID scanning would capture name, DOB, and address from their ID document — data that in other markets required manual entry. The strategic bet was to remove the redundant manual entry step entirely: eliminate Step 3's sender details screen and instead confirm the KYC-extracted data post-verification. This reduced one screen from the first-transaction flow and removed a meaningful data entry burden — especially for users whose names use non-Latin scripts. The decision was documented in a formal decision memo and required alignment across RUX, I&T, and Compliance.
Bet 2: Design the residence status screen as a clarifying question, not a classification gate
Regulatory framing:
"Are you a Japanese citizen or permanent resident?" — accurate, but legalistic, and likely to confuse non-native speakers navigating an unfamiliar immigration category
Design framing:
A structured choice with enough context for each option that users can self-identify accurately without needing to know Japanese immigration law
This was the highest-stakes UX decision on the project. Getting it wrong had two failure modes: users selecting the wrong residence category and being routed to the incorrect Liquid flow (causing KYC failure), or users feeling profiled or interrogated by an unexplained bureaucratic question (causing abandonment). The solution required compliance and legal sign-off on the exact content of each option — what "permanent resident" meant in this context, how to describe non-permanent residence in plain language across both Japanese and English, and whether any edge cases (long-term visa holders, certain special status categories) needed explicit callouts.
Bet 3: Treat the Liquid webview transition as a designed moment, not a technical handoff
Engineering degault:
Trigger the Liquid webview as a functional overlay — it works, users can see they're in KYC, transition back when complete
Design framing:
The entry into KYC needed a preparation screen; the exit needed a smooth data confirmation — without these, the webview would feel like an app crash or a redirect to an unknown third party
KYC abandonment in new market launches typically spikes at the point of vendor handoff — users who don't understand why they're suddenly in a different visual environment assume something has gone wrong. The preparation screen before Liquid (explaining what to expect and what documents to have ready) and the sender detail confirmation screen after (showing the extracted data and asking for confirmation) were both design investments against that abandonment risk. They also served a compliance function: the confirmation screen created an explicit moment where the customer acknowledged their identity details, which was a defensible regulatory artifact. I pushed for both screens despite engineering cost — and had to make the case that they were conversion investments, not UX niceties.
Bet 4: Apply JPY formatting as a system constraint, not a screen-by-screen decision
Default approach:
Handle JPY display as a localization detail — format correctly where it's obviously needed (calculator, send summary)
Design argument:
Japanese currency conventions (no decimals, left-anchored FX display, 1 JPY = X format) needed to be enforced as a design system rule across every touchpoint — not patched screen-by-screen
The PRD was explicit: "Japanese Yen should have no decimals across all touchpoints in the product." But "all touchpoints" in a multi-team launch means calculator, error states, send summary, transaction history, limit messaging, and any future surface where an amount appears. I pushed for this to be treated as a system-level constraint — documented in the design spec and flagged to every engineering team — rather than left to individual implementation. The FX display format (1 JPY = X, not X JPY) was equally Japan-specific and equally invisible unless systematically enforced. Getting this right mattered not just for aesthetics but for trust: Japanese users would immediately register a Western currency format as a sign of a product that hadn't been built for them.
06 Cross-functional leadership
Navigating 4 teams, 2 regulators, and one KYC vendor simultaneously
The cross-functional complexity on Japan Outbound was qualitatively different from a single-team project. Every significant design decision touched at least two teams — and several touched all four plus compliance and legal. As the sole designer across all surfaces, I was the only person who had full visibility into how decisions in one workstream would affect the others.
The hardest alignment moment — residence status screen content
The residence status screen needed sign-off from both compliance (to ensure the options correctly routed users to the appropriate KYC flow) and legal (to ensure the copy didn't misrepresent Japanese immigration categories in a way that could create regulatory exposure). These two reviews had different concerns and different timelines — compliance cared about the routing logic, legal cared about the legal accuracy of the language. I ran them in parallel by presenting the screen with two distinct annotation layers: one showing the routing logic for compliance, one showing the copy rationale for legal. Getting a single screen through two separate review tracks simultaneously required structuring the design artifact to serve both audiences at once.
Engineering — Liquid webview constraints
The Liquid integration introduced constraints that weren't fully known at the start of design. The webview had to overlay the Remitly app without the customer leaving — which affected how the preparation and confirmation screens could be built. I worked closely with I&T engineering to understand what was technically possible at each transition point, and designed within those constraints rather than designing ideally and forcing engineering to adapt.
MMX — FX format alignment
The 1 JPY = X display format required MMX engineering to invert the standard calculator logic, which defaulted to X JPY. This wasn't a styling change — it required a different calculation display model. I made the case for it as a trust requirement, not a localization preference: Japanese users would immediately recognize a Western FX format as evidence the product wasn't built for them.
Multi-team design consistency
With four teams building different parts of the same flow, design consistency required active coordination. I maintained a shared component spec covering Japan-specific decisions — JPY formatting rules, occupation dropdown behavior, script handling — and flagged it in every team's design review to ensure no team implemented a surface in isolation that would create a seam in the customer experience.
Localization — Japanese vs. English trade-offs
Several screens required decisions about which language took precedence in mixed-script contexts — for example, when a Japanese-named user's KYC-extracted data was in Kanji but their app locale was set to English. I worked with I&T and localization to define a clear rule: the script follows the ID document locale, not the app locale, because that's the data the disbursement partners require.
07 Final design
What shipped — the complete Japan send experience
The final Japan Outbound experience was a cohesive send flow covering six distinct stages: landing and calculator, account creation, recipient details, sender details (with Japan-specific additions), KYC via Liquid, and send summary. Each stage had Japan-specific design decisions that weren't present in any other Remitly market.
08 Outcomes
What the launch delivered
$14B
TAM now accessible to Remitly
Japan was previously completely closed to Remitly as a send market
$13.5M
Projected gross profit, 3 years post-launch
​
82%
KYC completion rate at launch
Impact 01 — Market access
A $14B TAM opened with a product built to Japanese standards
Japan was one of the last major remittance markets Remitly hadn't entered. The design work wasn't just enabling a transaction — it was establishing Remitly's credibility in a market with the highest product quality bar of any the company had launched in. A generic product would have failed on first impression. The Japan-specific decisions — FX format, residence status UX, KYC transition design, dual-script handling — were the difference between a product that felt built for Japanese users and one that felt ported from somewhere else.
Impact 02 — KYC conversion
Mandatory $0-threshold eKYC without killing first-transaction conversion
The most commercially critical design outcome was converting first-time users through mandatory KYC before their first transaction — a higher bar than any other Remitly market. The preparation screen, smooth webview transition, and post-KYC confirmation flow were all designed to minimize abandonment at a step that in other contexts (post-submit blocks, unexplained redirects) consistently caused churn. The decision to eliminate the redundant sender details screen — saving users from entering data that Liquid would capture automatically — reduced friction at the most sensitive point in the first-transaction flow.
Impact 03 — Reusable system contribution
Design patterns that generalize to future send-country launches
Japan was Remitly's most complex send-country launch to date. The design decisions made here — how to handle mandatory pre-transaction KYC, how to design residence status classification screens, how to manage webview vendor integrations — created documented patterns that the next send-country launch can reference directly. The Japan Outbound Figma file was structured to be a reference, not just a deliverable. The localization framework (locale follows ID document, not app settings) was documented and shared with the expansion program team.
Impact 04 — Cross-team alignment
A consistent customer experience across four product teams
With four engineering teams building different parts of the same flow, the risk of seams in the customer experience was high. The shared Japan-specific design spec — covering JPY formatting rules, script handling, KYC transition behavior, occupation dropdown logic — was the alignment artifact that prevented each team from making isolated decisions that would have been invisible in review but felt wrong to users. That consistency was a design contribution that won't show up in screens but will show up in retention.
09 Reflection
What I'd do differently
I'd push for in-market user research earlier.
I'd push for in-market user research earlier. The residence status screen went through three design rounds and multiple compliance reviews — but none of that involved actual users in Japan attempting to classify themselves. We designed based on immigration law analysis and internal review. I believe the final screen works, but the absence of user testing on the most culturally and linguistically sensitive screen in the product is a gap I'd want to close before a full general launch. Proxy research — even with Japanese speakers outside the target market — would have been better than none.
I'd establish the Japan-specific design system rules in week one, not week four. The JPY formatting constraints, script handling rules, and FX display conventions were documented as they came up — reactively, as individual teams hit the issues. By the time I had a complete spec, several teams had already made implementation decisions that needed revision. A Japan design system document, written before any screens, would have prevented that churn.
I'd treat Nepali and Bahasa Indonesia language support as a design constraint from the start, not a P1 out-of-scope item. These were the two fastest-growing immigrant communities in Japan — 30% and 39% growth respectively — and both were offered by local competitors. Descoping them was a defensible launch decision, but the absence of a clear roadmap for adding them meant the localization architecture was designed for the languages we had, not for the ones we'd need. A more forward-looking language expansion model would have been worth the upfront investment.
What Japan taught me: designing for a market you've never designed for isn't primarily about translation. It's about replacing your assumptions with theirs. The FX display format, the residence status classification, the zero-decimal currency convention — none of these were obvious until I stopped asking "how does our product work?" and started asking "how do Japanese users expect money to behave?" That shift in framing is the thing I'd carry into every market-entry project going forward.