Thread Replies & Communities Redesign

Community managers were losing control of their platforms at scale. Conversations were impossible to follow, moderation was reactive and slow, and in enterprise sales calls, the missing feature was appearing on contract requirement lists. I designed the first threaded reply system end-to-end — starting with what the data showed users actually needed, which was not always what they asked for.

Understanding what good looks like before designing anything

I started by auditing six competing platforms: Reddit, Discourse, Khoros, Higher Logic, Vanilla Forums, and Salesforce Communities. Each made different tradeoffs — Reddit's unlimited nesting creates depth but loses casual users, Discourse's two-level model is clean but constrains conversation depth, and the enterprise options carry years of legacy UI debt.

The audit exposed one consistent gap: none had prioritised mobile. Most were desktop products retrofitted to smaller screens. That became our strategic differentiator — design mobile-first from the start rather than bolt it on later.

Two user groups, two different problems

I ran structured research with two distinct groups: community members and community managers. The most significant finding was not about threading at all — it was discoverability. Community members could not find replies to their own posts. Community managers could not identify which conversations needed moderation. The flat feed buried signal in noise for everyone.

Mobile told a separate story. A significant portion of access was happening on mobile, but the experience had never been designed for it — users would read but rarely reply, and when they did, the broken composition experience led to incomplete posts and abandoned threads.

Using Figma Make to test direction with clients before committing

Given how UI-heavy threading is, we needed real client feedback before committing to a design direction. I used Figma Make to generate interactive prototypes quickly — functional enough to test core interactions without implying final decisions. We explored different nesting levels, action discoverability, and overall thread readability across three validation rounds.

Two gaps surfaced that directly changed the design: clients needed a quick way to mark a reply as the best answer inline, and the reply affordance on the root post was not obvious enough. Both were fixed before we committed to the final direction.

The bounded threading model and what mobile forced us to do better

We explored three structural directions: deep Reddit-style nesting, flat two-level threading, and a bounded model with contextual expansion. The bounded model won because it treated the thread as a unit of content — root post, direct replies, replies to replies, no further recursion. That finite structure made everything downstream cleaner.

Mobile was the hardest design problem. With a full action set in a constrained space, we had to be ruthless about what was primary. We stripped all non-essential labels and moved secondary actions into contextual menus. That discipline made the desktop design better too.

What broke in testing and a scope expansion we did not plan for

Usability testing surfaced one issue: on mobile, users understood how to reply once they found the affordance — but finding it was not intuitive enough. The reply count indicator was too subtle. Two direct fixes: more prominent reply count with a consistent position, and the collapsed state updated to show the replier's avatar.

The larger issue emerged during engineering review. The admin panel had been designed for a flat-post world. Rather than ship a broken moderator experience, we split the admin work: V1 covered essentials, advanced features in a post-launch phase. It delayed nothing.

Shipped to all enterprise accounts in beta, then globally

Thread Replies shipped alongside the V1 admin improvements, giving community managers the ability to view and act on threaded content from the control panel for the first time. Client feedback was strongly positive, particularly from accounts that had flagged threading as a contractual requirement.

The project was cited in my FY26 performance review, which returned an Unmatched Excellence rating — the highest in the organisation.

Mapping the member experience to the moderator side

Post-launch, I redesigned the admin experience properly. The core challenge: every community-side feature needed a corresponding moderator affordance. The solution was a two-column layout — the right column shows the thread exactly as a member sees it, with an expanded moderator action set. The left column provides topic metadata and a Content Moderation section that surfaces new, reported, and pending content in a single scannable list.

The AI-assisted moderation phase — currently in development — addresses speed. Moderators have to manually review all content, and small teams cannot keep pace with active communities. The AI layer will surface likely policy-violating content proactively before it gets reported.

What I would do differently

The biggest lesson was scope alignment with engineering early in the process. We had significant design freedom at the start but did not align tightly enough on what was feasible within the implementation timeline. A number of ideas made it far into the design phase before being cut or deferred.

In hindsight: build a clear must-have vs nice-to-have framework earlier, and bring engineering into those conversations before design work gets too advanced.