PRODUCT DESIGN · RETENTION · MESSAGING · LAUNCHED
Closing a 3-Year Feature Gap
Customers had asked for a reply feature for years. I led it from concept through launch inside a no-backend-changes box. After it shipped, 70% of enabled RingEX Message MAU sent replies within 30 days.
role
Design lead · Team of 8+
timeline
12+ months
platform
Desktop · Mobile
deliverables
Discovery · IxD · VxD · UI Verification
The constraint box
Limited engineering resources, no backend changes allowed, a tight timeline, and competing stakeholder needs. Every decision below was made inside that box.
// ROLE
What I owned
Design lead, team of 8+. I owned the interaction model.
- Quoting was not a reply feature. Customer evidence reopened scope.
- Side panel over full-screen. Against stakeholder preference.
- Moving reply object. Launch with no backend thread support.
// AFTER LAUNCH
// DECISION 01
Quoting was not a reply feature
Constraint. For years, quoting was the only way to respond to a specific message. Customers kept asking for threading. Several earlier designs were too complex to ship without compromising other work.
Alternatives. Stay with quoting, or ship a lightweight reference-reply that looked like Telegram and WhatsApp. We tested both a truncated reference and a digest view of replies to a post.
Decision. Quoting was insufficient: it cluttered the stream, let people edit others' messages, and still left a competitive gap. The first MVP concepts were too close to quoting. Customers said as much. That evidence is what I used to reopen scope for a real reply model — still without backend changes.
“Not sure how this is different from quoting. But I do like being able to view all the replies to my post in one place.”
Customer · remote usability
“If there are a lot of these in the conversation, especially the same post, it can still feel and look cluttered.”
Customer · remote usability
// DECISION 02
Side panel over full-screen, against stakeholder preference
Constraint. The team could not agree on how to show replies even after revisiting discovery. Full-screen was the stakeholder preference. Users reply while watching the main conversation.
Alternatives. Overlay drawer, full-screen takeover, or a side panel that leaves the stream visible. Beta made the cost of the overlay obvious: duplicated replies, stacked scrolling, and a drawer that stole context.
Decision. The stakeholder preference was full-screen. I pushed for the side panel because the evidence showed that preserving conversation context was more important than giving the thread more space. Replies live beside the conversation, not on top of it. I also cut reply trails after beta — customers experienced them as duplicates, the clutter threading was supposed to remove.
Evidence. Remote usability in customers' own environments (N = 7): enhance thread context, prefer tree organization over trails, and take as little screen from people who are not in the thread.
// DECISION 03
The moving reply object unlocked the backend limit
Constraint. True threading needed backend support we did not have. Unread Message Indicator tracks recency, not thread unreads. Waiting for platform work would have slipped the customer commitment.
Alternatives. Ship nothing until the backend could track thread unreads, or fake a thread model that engineering could not support.
Decision. Rather than wait for backend support that did not exist, I used the existing recency model as the system's source of truth and designed the reply object to move with it. New reply activity surfaces through Unread Message Indicator. That turned a backend limitation into a shippable interaction model.
// RESULT
The object that shipped
The moving reply object kept unreads honest. Cutting trails removed the clutter customers had called out.
// MY SPECIFIC DECISIONS
Reopened scope after the quoting-like MVP failed
Customer feedback on the first concepts was the leverage to stop polishing quoting and design an actual reply model — still inside the no-backend-changes box.
Side panel over full-screen, against stakeholder preference
The stakeholder preference was full-screen. I pushed the side panel because evidence showed that preserving conversation context mattered more than giving the thread more space. I cut reply trails for the same reason: they added the clutter threading was meant to reduce.
The moving reply object
Rather than wait for backend support that did not exist, I used the existing recency model as the source of truth and designed the reply object to move with it. That turned a backend limitation into a shippable interaction model.
// IMPACT
What changed after launch
Within 30 days, 5,269 of 7,530 enabled Message MAU had sent a reply. They averaged 24.3 replies per unique user. I can't attribute retention directly to the feature, but it removed a long-standing product gap that had surfaced repeatedly in competitive and customer conversations.
// NEXT
Threads, then AI
The durable direction: a dedicated threads space so reply objects leave the main stream, plus AI that summarizes a long thread and helps draft a reply. The interaction model had to exist before those features could sit on top of it.