Roomie: AI Companion

Taming 0-to-1 chaos with scalable UX systems

Roomie: AI Companion

Context

In June 2025, Rec Room launched Roomie — an AI companion that instantly became the most sought-after feature in the game. The team was moving fast, shipping daily, but without a designer embedded to hold the experience bar.

I came in from the monetization team with one goal: drive revenue without breaking what made Roomie special.

RoleLead Product Designer, Monetization
TeamDirector of Design | 4 Engineers | 1 QA
PlatformMobile, VR, PC, Console
SkillsProduct Strategy | 0–1 Product Design | Systems Thinking | Monetization & Growth Design | UX Research & Testing | Cross-Functional Leadership
TimelineJune 2025
impact

Small bets. Big returns.

+12.4%
Earnings in tokens
+11.9%
DAU
+30.5%
Time spent with Roomie
EXPERIMENT

One hat. One week. Great signal.

Building a full customization system would take at least a month. We needed signal faster.

I knew from previous monetization work that a feature's entry point works best when it hits two things at once: high traffic and high intent to convert.


I evaluated three candidates against that framework: voice chat, the settings page, and the store. The settings page and storefront both cleared the bar.

The flow was simple: see the promo, click through, buy and equip in one tap.

Prototype: Roomie's hat experience

We shipped in a week. The hat became the #1 item in the ecosystem and stayed in the Top 10 for a full month. Token earnings lifted 12.4%. The demand was real.

DESIGN / CUSTOMIZATION

A system that offered granularity and scalability

With ten more exclusive items coming, we needed a real customization experience. I started with an in-world model — it felt immersive. But techinical constraints made it very expensive to achieve.


I made the call to pivot to a modal. It gave us room for both granularity and scalability: a default tab for Roomie itself, separate tabs for clothing and accessories, and item-specific controls like hat rotation.

Prototype: customization modal
DESIGN / SETTINGS REFACTOR

A scaffold that fixed the weak link

Once the customization flow was locked, I mapped the full user journey and realized the entry point was broken. The settings page was a laundry list that was increasingly difficult to parse.

Original Roomie Settings Page was a laundry list of unrelated controls
Original roomie settings page

Pitching a full refactor mid-sprint is a hard sell. I brought this user journey map to show where players dropped off and what it was costing the feature. Then I volunteered to build the front-end prefabs myself to shrink the engineering ask. The team said yes.

User journey map showing 'Settings' as the weak link
User journey map showing 'Settings' as the weak link

I split the architecture into two tabs, Customization and Experiences, and brought Roomie back to center with a live preview. Not just a cleanup, but a scaffold for everything Roomie would become.

Protoype: redesigned settings page
DESIGN / ENERGY

A usage tracker that felt alive

As Roomie's popularity grew, compute costs became a real constraint. Stakeholders pushed for usage limits. My job was to make that feel like part of Roomie's world — not some “money-grabbing” feature.


I called it “Energy”. A battery icon as the visual indicator. When energy ran low, Roomie wouldn't just stop — it would look tired. The metaphor did the work that a hard paywall couldn't.

Battery icon as the visual indicator. When energy ran low, Roomie would look tired.
Energy as the metaphor for Roomie's usage limits
DESIGN / MEMORY

Building trust through memory management.

Players could enable “Remember Conversation” and then review, search, and delete specific things Roomie knew about them.

This mattered because many Rec Room users are young kids. Some were using Roomie as a therapist, someone to tell things they didn't want anyone else to hear. The ability to delete those memories wasn't a privacy checkbox. It was trust and safety.

Protype: memory deletion flow
REFLECTION

A more native AI UX model?

The modal was the right call for our timeline. But a 2D settings screen is the most un-Roomie way to configure Roomie.


What I'd explore next: what if configuration happened in conversation? If a player says “I wish you'd stop bringing that up,” that's a deletion moment. It shouldn't require finding a menu.

Every decision was designed to make the next one easier. In a zero-to-one environment with no playbook, that's what I think design is actually for.

Curious to learn more?

Reach out to learn more about this project, or me, as a future partner at work ;)