Overview
Poe was a single-user product: one person, one or more bots, one conversation. As the platform added group chats, the invite system became the first piece of infrastructure needed to make shared conversations actually work.
I led design across the full system: how users share invites, how new users join, and how the product handles the edge cases in between.
Challenge
Invites sound like a solved problem. But on Poe, we were starting from zero across several dimensions:
- No existing mental model for shared conversations
- No infrastructure for multi-user interactions
- Complex state combinations (logged in/out, existing/new user, inviter/invitee)
- Cross-platform constraints (web, iOS, Android)
Constraints
- Extremely low friction (growth-critical surface)
- Low engineering scope (lean team)
- Tight timeline (~3–4 months)
Research
Before exploring solutions, I audited how major social platforms handle:
- Invite links and sharing patterns
- Deep linking behavior (especially on iOS)
- App install flows
- Abuse prevention vs. ease of access
This helped ground internal discussions in industry norms, especially when making tradeoffs around friction and conversion.
Invite Paths
Two paths emerged for how someone could add others to a chat.
1 — Invite Links (Primary)
Shareable across platforms (iMessage, WhatsApp, etc.). Designed for growth and new user acquisition.
2 — Direct Adds via Followers (Secondary)
Leveraged an existing system. Designed for low-friction internal collaboration.
iOS Constraint
One technical constraint shaped the entire approach. On iOS, if a user doesn't have the app and taps an invite link, they're sent to the App Store. After installing, they can't be returned directly to the chat and have to navigate back to the original link source themselves.
Exploring Directions
Option A — Web-First
Users open the invite link, land on mobile web, sign up or log in, then join the chat from web before downloading the app.
Invite link in messaging app
Join chat (mobile web)
Sign in to Poe
Choose account
Chat joined (on mobile web)
Pros
- Users see value earlier
- Lower perceived friction
Cons
- Required maintaining a robust mobile web experience
- Weak control over conversion to app
- Limited push notification ability
- Legal concerns around exposing chat content before joining
Option B — App-First
The invite link sends users to download the app first. Friction is upfront; the experience after is fully native.
Pros
- Aligns with industry-standard patterns
- Full control over in-chat experience
- Unlocks notifications and retention loops
Cons
- Higher upfront friction
- Requires completing a multi-step flow
Decision
We chose Option B. An invite carries social context: it comes from someone you know, and users are more willing to complete a multi-step flow when that's true. It also unlocked notifications and a fully native experience, both important for long-term retention.
Direct Adds
For users already on Poe, we needed a lightweight way to add others. Instead of introducing a new system, I reused the existing follower graph.
Consent Model
If you follow someone, they can add you to a group chat.
Sorting the Follower List
Deciding how to order the follower list turned into a meaningful product question. We explored alphabetical, follow-time, and "likely to contact" ranking. We shipped follow-time sorting. Recency turned out to be a reasonable proxy for intent, and it reused existing infrastructure without added complexity.
Decision
We shipped follow-time sorting. It reused existing infrastructure, kept scope contained, and recency turned out to be a reasonable proxy for intent: who you followed most recently correlated better with who you actually wanted to message.
Internal launch
We launched internally and quickly saw friction. Not in the flows themselves, but in users' understanding of how the system worked.
- 1.Confusion around who you can add — Users didn't understand the follower-based permission model. We updated empty-state copy to explain the constraint directly.
- 2.Invite links were underemphasized — Users missed the primary growth mechanism entirely. We made the link the visual anchor of the share modal.
- 3.Bots didn't reply automatically — This broke a core expectation from the single-player experience. We added onboarding copy and an @mention affordance to set the right mental model.
Final Designs
The final spec across each surface.
Inviter
Both invite paths converge here: generating a shareable link or adding followers directly. Creating a chat via link happens optimistically; the chat exists before anyone joins, and members appear as they accept.
Invitee
The join experience branches by platform and login state. Web lands on a mobile interstitial; mobile routes through the App Store for new users. Both paths converge on the same in-app join modal.
Results
of chat joins came from invite links
of those joins were new users
of new-via-invite users messaged within 24 hours
engagement rate via direct adds (for comparison)
Key Takeaways
1 — Technical constraints are design inputs
The iOS deep link limitation wasn't a problem to work around. It was a parameter that shaped the entire direction. Treating it as a design input early meant we chose the right approach instead of optimizing the wrong one.
2 — Reuse beats reinvention
The consent model came from the existing follower graph. The list sort came from recency data that already existed. Working within what was already there kept scope tight and mental models familiar, with no new systems to explain.
3 — Behavior > UI
The biggest impact moments in this project didn't come from UI polish. They came from understanding how users think about permissions, trust, and value exchange. Getting those mental models right was the real design work.
Reflection
Good product design isn't just about what you build — it's about what you make possible next.
Invite flows are often treated as a growth feature. This one became infrastructure: the mechanism by which a solo product became something you could share.