OSHIZ · AI COMPANION
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
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.
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.
Step into the moment with her.
See what she is doing, join her story, and turn each encounter into an experience you share together.
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.
Before the measured segmentMission started→Mission completed
Indexed to 100 ticket recipients
- 01Ticket received100
- 02Ticket used≈50
- 03Special Date completed≈45
Measured cohortDid not continue
The reward had already been delivered.The next action had not.
The path as it shipped
Three screens to receive the ticket.Half of them stopped here.
TICKET RECEIVED
≈50%Half of the users who reached this screen never reached the next one.
The path as it shipped
The other half still had five screens to go.
TICKET USED
SPECIAL DATE
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.
01DM entry
02Tooltip appears
Session Recording ObservationsThree editorial observation cards
01
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.
This was not an information shortage.It was a continuity problem.
How might we explain how to use the ticket?
How might we let users act before their intention disappears?
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.
The redesigned path
Act now, or return later without losing the next step.
BEFORE8 screens · 2 context changes
AFTER2 guided paths · next action preserved
+34%
Ticket-use conversionimprovement
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.
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.
How might we make character conversations more engaging?
How might users understand that characters continue to live, move, and create events beyond the conversation?
Product principles
Show place, not only dialogue
Characters should visibly exist somewhere in the world.
Show time, not only history
The experience should respond to when the user enters the world.
Let users discover, not only receive
Players should encounter events through movement and exploration.
Support personal routes, not one predetermined sequence
Relationships should emerge through each player's encounters and choices.
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.
Elements the composition must expose
- World map
- Location
- Current time
- Weather
- Character position
- Available encounter
- Future or locked location
- Player movement
- Event entry point
- 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.
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
How might we document every component more clearly?
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.
- 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.
02 — 02FROM MANUAL REVIEW TO AUTOMATED VISUAL QA
The workflow reduced the timebetween implementation and approval.
AI-assisted coding made the first implementation faster, but visual review became a new bottleneck.
I previously compared implemented screens against Figma by hand and explained differences in spacing, color, typography, and layout one by one. Small discrepancies often led to several rounds of subjective feedback.
We replaced that review with a repeatable visual QA loop: capture the implementation at the reference viewport, compare it with the design, and use a pixel-diff heatmap to locate discrepancies.
Developers could correct visible differences directly, reducing repeated interpretation and shortening the path to design-review quality.
DESIGN REFERENCE
The source screen defined in Figma.
FIRST IMPLEMENTATION
A functional first build with visible differences.
PIXEL DIFF
A heatmap exposing differences in spacing, position, and color.
REFINED IMPLEMENTATION
The refined screen after targeted corrections.
Before / After workflow
| BEFORE | AFTER | |
|---|---|---|
| Review | Manual visual comparison | Automated reference comparison |
| Feedback | Subjective written corrections | Pixel-level discrepancy detection |
| Iteration | Repeated designer–developer review | Targeted revision from visual diff |
| Approval | Full-screen reinspection | Focused validation of changed areas |
| Impact | Time saved by AI was lost in QA | Shorter implementation and review cycle |
Team impact
SHORTER DEVELOPMENT CYCLE
Visual discrepancies were identified before manual design review, reducing the time developers spent interpreting and revising feedback.
FEWER FEEDBACK LOOPS
Developers could correct measurable differences directly instead of waiting for repeated screen-by-screen comments.
EARLIER QUALITY CONTROL
Layout, spacing, color, and component-state issues became visible before full feature integration.
MORE PRODUCT TIME
Reducing repetitive implementation review created more time for interaction design, edge cases, and product decisions.
AI assists with
- Token extraction
- Initial component scaffolding
- Repetitive code translation
- Screenshot capture
- Pixel-diff generation
- Visual discrepancy detection
The system enforces
- Semantic tokens
- Existing code patterns
- Naming conventions
- Supported variants
- Reusable state logic
- Repeatable visual validation
- Reference viewport consistency
- Repeatable screenshot conditions
- Visual comparison thresholds
The designer decides
- Product hierarchy
- Interaction behavior
- State logic
- Accessibility
- Edge cases
- Final visual quality
- Which visual differences are defects
- Which differences are acceptable rendering variance
- Whether the implementation expresses the intended experience
AI accelerated translation.It did not replace design judgment.
Less time translating and correcting specifications.More time designing the product.
The coded system and visual validation loop reduced repeated interpretation between design and frontend implementation.
Developers could begin with reusable components and use visual differences to refine the implementation without waiting for repeated manual reviews.
As a designer, I could validate real states in the browser, focus review on meaningful discrepancies, and spend more time on interaction behavior, edge cases, and product decisions.
Components could be reviewed in their implemented states.
Visual and structural gaps became visible before full feature integration.
Variants and edge cases were shared across multiple product areas.
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
Next project · 02 / 04MelAI activation · Conversation UX · 2025From 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.