01 The Problem
How do you get someone to trust a stranger with personal topics, and pay to talk to them on the phone?
FortuneCaller is a live fortune-telling service where Japanese clients browse professional tellers, buy session time, and speak by phone. Three portals and three mental models: client mobile web, teller dashboard, and admin desktop, each with different priorities.
The design problem was not "make it look modern." Western minimalism would have felt untrustworthy in this category. Competitors that led with price felt cheap. Stronger platforms led with experience, specialties, and social proof. The work was to design for density as a trust signal without making the interface unreadable.
Before any visual decisions were made, the focus was on flow logic. The wireframes existed to pressure-test one question: could a first-time user choose a teller and start a call without hesitation at any step? Every screen at this stage was treated as a hypothesis.
Early flow wireframes, pre-visual. Five screens covering the trust journey: teller list, profile, points purchase, pre-call confirmation, and in-call state. Each screen was kept only if it answered a navigation question the previous screen could not.
02 Who This Was Designed For
Three users. One product. Completely different jobs to be done.
A single component library served three portals, but density, language, and priority could not be identical across them.
Client
Anxious, browsing for the right person, not the cheapest. Needs credentials before commitment. Mobile web.
Teller
Managing availability, sessions, and earnings, often with limited technical fluency. Needs clarity under time pressure during live calls.
Admin
Oversight, disputes, teller onboarding, platform health. Needs dense data tables, not empty minimal layouts. Desktop.
The client optimizes for trust. The teller optimizes for workflow speed. Admin optimizes for control. One component library could not treat all three the same.
03 The Core Insight
Trust is built before the call, mostly on the teller profile.
"In this market, empty space does not feel premium. It feels like you are hiding something."
The shift that defined the product
Research across six Japanese fortune-telling competitors showed a consistent pattern. Platforms that pushed price first felt discount oriented. Platforms that pushed experience, specialty, and reviews first felt legitimate. Users were not asking for less information. They were asking for the right information in the right order.
Price matters, but it cannot lead. Payment should happen before the emotional moment of dialing. That is why the points system exists: it separates the payment decision from the call itself.
04 Key Design Decisions
The choices that shaped trust, payment, and density.
Not a tour of every screen. The four decisions worth explaining.
Decision 01
Credentials before price
Teller lists and profiles follow patterns users already trust from competitors: years active, specialty tags, review excerpts, session count. Price is visible but never the headline. I tested hierarchy against a price-first variant. It read as a bargain service, not a professional one.
Research across six Japanese competitors showed that platforms pushing price upfront felt cheap. Stronger platforms highlighted experience, specialties, and reviews first.
Decision 02
Density with structure, not minimalism
I did not strip content to look modern. I accepted density as a trust signal and grouped, spaced, and typed layouts so users could still scan. Section headers, card boundaries, and typographic scale do the work, not whitespace alone.
Decision 03
Points as a trust buffer
Users buy points first, then start calls. This mirrors familiar Japanese mobile commerce patterns and separates the payment decision from the emotional moment of calling. You are not entering card details while deciding whether to share something personal.
The points balance stays visible on the profile and pre-call screens, so users always know what a session will cost before they commit emotionally.
Decision 04
Three portals, one design language
The teller dashboard prioritizes session state and earnings, not marketing density. Admin gets data-heavy tables. Shared tokens keep it one product, but density level varies by role: client is trust rich, teller is action rich, admin is information rich.
I designed the user and teller portals end to end and owned flows across the admin portal. Each surface answered a different question, but the visual system stayed consistent.
05 Reflection
The profile was the product. I treated it like a detail.
FortuneCaller taught me that cross-cultural design is not about adding local flavor at the end. It is about questioning which of your own instincts are actually universal. My instinct to simplify was the wrong starting point for this category. The research gave me permission to design densely. What I did not fully act on was where that density mattered most, and how early that screen needed to be locked.
What Landed
Leading with credentials over price held up in review. Competitor patterns gave the client a reason to trust the hierarchy, not just my taste
The points system did more than mirror Japanese mobile commerce. It removed payment from the moment users were deciding whether to speak about something personal
Varying density by role kept three portals feeling like one product. Clients got trust-rich profiles. Tellers got action-focused session tools. Admin got the tables it actually needed
Starting from competitor audits before high-fidelity UI made the density decisions defensible. Evidence overrode instinct when the client pushed back on how full the screens looked
What I Would Redo
Prototype and test the teller profile first. It carries most of the conversion weight, but it was the last screen finalized because feedback cycles went to lower-stakes flows first
Design teller onboarding as its own flow. The dashboard assumes platform familiarity that first-time tellers do not have, and that gap only became visible late in the project
Run profile usability testing before visual polish, not after. I validated density in review sessions, but not whether users could actually scan and decide under real browsing pressure
Push back earlier on a culturally neutral brief. "Clean and simple" sounded reasonable in the kickoff. In this market it would have read as incomplete, and that should have been flagged in week one