OSHIZ is an AI companion app where users explore the world of Idola, talk with AI characters, experience their stories, and go on dates as their relationships deepen over time.
As users explore the virtual world of Idola, they interact with characters through AI-powered conversations, stories, and shared dating experiences.
Each experience carries into the next, allowing their relationships with the characters to gradually deepen over time.
Project
OSHIZ
Category
AI Companion / Social Simulation
Role
Product Designer & Product Manager
Platform
iOS / Android
01 — EXPLORE
Step into a world that moves with you.
Idola follows the same flow of time as the real world. Through your phone, enter the world where your AI companion lives.
02 — MEET
Find her living her own day.
Your AI companion follows her own schedule and moves throughout Idola. Discover where she is and meet her as your paths cross.
03 — EXPERIENCE
Step into the moment with her.
See what she is doing, join her story, and turn each encounter into an experience you share together.
04 — DEEPEN
Stay connected beyond the moment.
Continue the relationship through DMs, share the small moments of everyday life, and grow closer over time.
CHALLENGE 01ACTIVATION · FUNNEL DESIGN
Users completed the experience once they started.The real drop happened before it began.
Special Date was one of OSHIZ's strongest premium experiences. But many users who earned access never reached it.
01 — 03BEHAVIORAL DIAGNOSIS
The content was working.Access to it was not.
OSHIZ's overall D1 retention was approximately 18%, making early value discovery the product's highest-priority problem.
Users who reached a Special Date showed approximately 70% D1 retention. This was a strong behavioral signal rather than proof that the experience directly caused retention.
Once users started a Special Date, approximately 90% completed it. The largest actionable drop appeared before the experience began: between receiving the ticket and using it.
Strong correlation, not causal attribution.
≈18%Overall D1 retentionProduct-wide baseline≈70%D1 retention among users who reached Special DateBehavioral signal, not causal proof≈50%Ticket recipients who never used the ticketLargest actionable drop≈90%Special Date completion after startingThe content itself was not the bottleneck
Special Date Funnel16:9
01Mission started
02Mission completed
03Ticket received
≈50%of ticket recipients did not use the ticketLARGEST ACTIONABLE DROP
04Ticket used
≈90%completed the Special Date after starting it
05Special Date completed
The reward had already been delivered.The next action had not.
02 — 03BEHAVIORAL EVIDENCE
A familiar metaphor did not create a discoverable action.
The ticket was designed as a gift that users could send to a character through DM.
Because sending a gift through conversation felt familiar, the original experience relied primarily on instructional copy.
PostHog events and session recordings showed a different reality. Users skipped the explanation, lost the context in which the reward had been earned, or could not reconstruct what they were expected to do next.
Before Journey Map3:2
01Complete mission
02Receive ticketWhere did the ticket go?
03Read instruction
04Leave the current contextIs it used from the inbox, inventory, or DM?
05Find the correct characterWhich character should receive it?
06Enter DM
07Open giftingCan I use it now?
08Find the ticket
09Send the giftWhat happens after I send it?
10Enter Special Date
Where the ticket was earnedLive product capture. The reward was granted here, while the action that used it lived somewhere else.
Users moved past instructional copy without reading it.
02
The reward and its next action appeared in different contexts.
03
Receiving the item did not make its usage location discoverable.
BEFORE
How might we explain how to use the ticket?
AFTER
How might we let users act before their intention disappears?
This was not an information shortage.It was a continuity problem.
03 — 03THE DESIGN DECISION
I reduced the distance between reward and action.
I explored three ways to reconnect users with the Special Date.
A push notification could bring users back later, but depended on them remembering the context. A multi-step showcase could explain the interface, but added more instructions to an already fragile journey.
The strongest direction was to preserve the user's current intention and move the next action closer to the moment of reward.
A/B/C Direction Comparison16:9
OPTION A
BACKGROUND PUSH
Re-engages later
Depends on return
Loses current context
OPTION B
MULTI-STEP COACH MARKS
Explains the interface
Adds cognitive load
Requires users to remember instructions
OPTION CSELECTED
DIRECT CONTEXTUAL TRANSITION
Preserves intention
Reduces navigation
Removes recall dependency
Final Special Date Access Flow16:9
01Mission complete
02Ticket acquired
03Immediate contextual CTA
04Character or date selection
05Ticket use
06Special Date
BEFORE
IMAGE PLACEHOLDER
Ticket acquired, no next action
Show the reward screen without a next action, next to the redesigned screen where the next action sits inside the reward moment.
Ratio
9:19.5
Required elements
Ticket acquisition confirmation
Instructional copy only
Close / confirm control
AFTER
IMAGE PLACEHOLDER
Ticket acquired with contextual CTA
Show the reward screen without a next action, next to the redesigned screen where the next action sits inside the reward moment.
Ratio
9:19.5
Required elements
Ticket acquisition confirmation
Primary CTA to use the ticket now
Character or date selection entry
Secondary control to use it later
+34%
relative improvementin ticket-use conversion
Reported as a relative improvement. A baseline conversion rate was not part of this dataset, so no before-and-after values are stated.
I did not redesign the experience users completed.I redesigned the path that prevented them from reaching it.
What changed in my design decisions
01
Instructions are rarely retained when they are separated from action.
02
Familiar real-world behavior does not guarantee digital discoverability.
03
Reducing cognitive distance can be stronger than adding guidance.
04
Behavioral correlation helps locate opportunity, but does not prove causation.
CHALLENGE 02“Zero to One” · PRODUCT VISION · EXPERIENCE ARCHITECTURE
We built autonomous AI characters.Users experienced another chatbot.
The product's most differentiated technology existed behind the interface. The redesign made that difference visible and explorable.
01 — 03THE PERCEPTION GAP
The intelligence was real.The world was not legible.
Behind the interface, OSHIZ characters had personalities, schedules, locations, relationships, and situational context.
They could move through the world according to time, place, weather, and events rather than waiting passively for a prompt.
But early users described the experience as similar to a conventional character chatbot. The product's most differentiated system existed on the server, while the user experience reduced it to a conversation window.
Invisible System vs. Visible Experience16:9
WHAT THE SYSTEM WAS DOING
Character personality
Autonomous schedule
Current location
Time
Weather
Relationship state
Situational event
Interaction with other characters
WHAT USERS COULD PERCEIVE
Open chat
Send message
Receive response
Repeat
Novelty
Long first interaction
No visible world accumulation
Weak reason to return
A long first conversation did not guaranteea reason to return tomorrow.
Observed as a product problem in OSHIZ, not stated as a pattern across the character-chat category.
02 — 03MENTAL MODEL
The product did not need more conversations.It needed a visible world model.
One possible response was to improve prompts, add more dialogue, or reward users for sending more messages. But each of those approaches would keep the character inside the chat window.
The deeper problem was not conversation quality alone. Users could not understand where the characters existed, what changed when they were away, or why returning could reveal a different experience.
BEFORE
How might we make character conversations more engaging?
AFTER
How might users understand that characters continue to live, move, and create events beyond the conversation?
Product principles
01
Show place, not only dialogue
Characters should visibly exist somewhere in the world.
02
Show time, not only history
The experience should respond to when the user enters the world.
03
Let users discover, not only receive
Players should encounter events through movement and exploration.
04
Support personal routes, not one predetermined sequence
Relationships should emerge through each player's encounters and choices.
Product Mental Model Redefinition16:9
CHAT-CENTERED PRODUCT
User↔Character conversation
From responding to a characterto participating in their world
WORLD-CENTERED PRODUCT
Time
Weather
Location
Character schedule
Player movement
Encounter
Shared event
Relationship
Conversation
BEFORE
01Onboarding
02Chat
03More Chat
AFTER
01Enter World
02Explore
03Meet
04Experience
05Continue Relationship
03 — 03EXPERIENCE ARCHITECTURE
Explore made the autonomous world observable.
I introduced Explore as the spatial layer of OSHIZ. Instead of explaining the world through onboarding copy, the map allowed players to understand it by moving through it.
Characters could appear in different places according to their schedules. Time and weather could change the context of encounters. Locations became stages for events rather than decorative backgrounds.
Characters have lives beyond the player.
The world changes even when the player is not chatting.
Returning can reveal a different place, moment, or relationship opportunity.
Explore World Structure16:9 or large map composition
Explore map — locations and character positionsWorld map · Location · Character position · Player movement
Location entry — place, weather, and available encounterLocation · Weather · Available encounter · Event entry point
Elements the composition must expose
World map
Location
Current time
Weather
Character position
Available encounter
Future or locked location
Player movement
Event entry point
Live captures anchor the structure. An annotated map composition replaces this slot.
OSHIZ Experience Loop4-step horizontal sequence
01
EXPLORE
Move through a world that follows its own time.
02
MEET
Find characters living through their schedules.
03
EXPERIENCE
Participate in events shaped by place and circumstance.
04
DEEPEN
Carry shared moments into conversations and relationships.
What the redesign changed
Made the autonomous system perceptible
Reframed the product around world participation
Translated hidden AI behavior into observable experience
Changed the product mental model from chat to world
The redesign changed the product's primary mental model:from opening a chatbot to entering a world.
What I learned
A differentiated technology has no product value until users can perceive and act on its difference.
Worldbuilding is not background lore. It is an interaction model that helps users understand what may change when they return.
CHALLENGE 03DESIGN SYSTEM · DESIGN ENGINEERING · AI-NATIVE WORKFLOW
The design system was documented.The implementation was still being reinterpreted.
I converted OSHIZ's complex interface system from static specifications into reusable, testable components.
01 — 02SYSTEM COMPLEXITY
A static specification could describe the system.It could not verify the system.
OSHIZ combined consumer-app navigation, game-like states, AI conversations, commerce, character relationships, rewards, and live content.
A component was rarely defined by appearance alone. Its behavior changed according to availability, ownership, relationship level, reward status, content state, and platform.
Figma captured the intended interface, but each handoff still required developers to reinterpret tokens, spacing, variants, and interactive states.
The problem was not missing documentation. The source of truth was not executable.
OSHIZ Design System Complexity Map16:9
SURFACE
Navigation
Character state
Chat and reply state
PROGRESSION
Relationship and level state
Reward and mission state
Store and costume state
FEEDBACK
Modal and toast state
Empty state
Loading state
CONDITION
Locked state
Completed state
Platform-specific state
BEFORE
How might we document every component more clearly?
AFTER
How might design decisions become testable in the environment where the product is built?
02 — 02DESIGN ENGINEERING
From visual specificationto living implementation
I converted the design system into reusable HTML and React components and documented their states in Storybook.
Rather than asking AI to recreate entire screens from screenshots, I created a repeatable workflow that connected component structure, implementation, visual comparison, and design review.
IMAGE PLACEHOLDER
Implemented Storybook components
Show production-ready components with their variants and states rendered in the browser.
Ratio
16:9
Required elements
Storybook sidebar with component hierarchy
A component rendered in multiple variants
Locked, loading, completed, and empty states side by side
Semantic token names visible in controls
Figma-to-Code Validation Loop16:9
01
Audit
Review existing components, states, variants, duplication, and inconsistencies.
02
Normalize
Define semantic tokens, naming rules, and predictable component structures.
03
Extract
Read Figma properties, spacing, typography, tokens, and component structures through an MCP-based workflow.
04
Implement
Build reusable HTML and React components using the product's existing code patterns.
05
Render
Capture the implemented component in the same viewport and state as the design reference.
06
Compare
Use visual diff results to locate spacing, layout, color, typography, and state discrepancies.
07
Refine
Correct the component while preserving semantic structure and reusable logic.
08
Publish
Document production-ready components, variants, and states in Storybook.
AI, System, and Designer Responsibility Matrix3-column editorial table
AI assists with
Token extraction
Initial component scaffolding
Repetitive code translation
Screenshot comparison
Visual discrepancy detection
The system enforces
Semantic tokens
Existing code patterns
Naming conventions
Supported variants
Reusable state logic
Repeatable visual validation
The designer decides
Product hierarchy
Interaction behavior
State logic
Accessibility
Edge cases
Final visual quality
Whether the implementation expresses the intended experience
AI accelerated translation.It did not replace design judgment.
Less time translating specifications.More time designing the product.
The coded system reduced repeated interpretation between design and frontend implementation.
Developers could begin with reusable, inspectable components instead of reconstructing the same visual rules for every feature.
As a designer, I could review real states in the browser, refine the final interaction directly, and spend more time on user problems and product decisions.
LIVING DOCUMENTATION
Components could be reviewed in their implemented states.
EARLIER FEEDBACK
Visual and structural gaps became visible before full feature integration.
CONSISTENT STATES
Variants and edge cases were shared across multiple product areas.
MORE PRODUCT TIME
Reducing repetitive specification and handoff work created more time for user and product decisions.
What I learned
The goal was not to remove Figma, developers, or design review.
Figma remained the strongest environment for exploring divergent directions. Code became the environment where selected decisions could be tested as real interfaces.
The system became strongest when both environments were connected through a repeatable validation loop.
I did not automate design.I automated the distance between a design decisionand its verification.
05CLOSING REFLECTION
What OSHIZ changed in how I design products
OSHIZ taught me that product value can disappear at three different layers.
A valuable experience can remain undiscovered. A differentiated system can remain invisible. A clear design decision can be lost during implementation.
Across all three challenges, my role was to reduce the distance:
between reward and action
between technology and user perception
between design intent and working product
I design the path that allows product valueto become visible, actionable, and measurable.
What this experience opened next
From returning tomorrow to starting today
Mel is a separate project from a different company. Read together, the two cases show how I approach both ends of an AI product journey: long-term relationship retention and first-session activation.
