Thread Replies & Communities Redesign

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.

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.

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.

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.

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.

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.

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.

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.