Group Live Formats as a Participation and Session Value Engine

This case study shows how I designed live systems once participation was no longer centered on a single host. Across both social co-streaming and competitive PK, the core challenge was the same: make multi-person live interaction understandable, extensible, and worth joining.

The two projects were developed about five years apart and were not part of one continuous feature roadmap, but they reveal the same product-design capability through different live interaction goals. Group Call answered that question through social co-streaming. Group PK answered it through competitive live interaction.

The first project was Group Call during the COVID period. It turned one-to-many livestreaming into a shared-stage format for 1-9 hosts, with dynamic layouts, host handoff, and group gifting designed to make co-streaming socially sustainable instead of novelty-driven.

The second project was a later PK framework refactor. It reworked competitive live interaction around a reusable session architecture, and it was preceded by quantitative user research I led to identify adoption barriers, unmet format demand, and the structural changes needed to move beyond repetitive 1v1 battles.

Why One-to-Many Streaming Limited Participation and Session Value

The platform originally centered on single-streamer sessions and 1v1 PK, which limited interaction density and discoverability across streamers.

During the COVID period, both streamers and viewers needed stronger real-time social connection. This created a product opportunity: move from isolated broadcasts to shared-stage experiences where multiple streamers could interact in one session.

Early Group Call research also showed that demand was not only about novelty. Users were motivated by the chance to interact with streamers they liked and meet more people in one room, but they were also sensitive to missing solo-mode features, viewer neglect, performance issues, and camera-on pressure.

About five years later, the context had changed. Competitive livestream products from other platforms increased pressure to upgrade PK quickly, and the challenge was no longer just adding features. The product needed a resilient architecture that could absorb upcoming PK modules with controlled implementation cost.

This work delivered two group live systems built from the same framework thinking:

I was the product designer across both projects. In Group Call, I worked in a UI/UX split and focused on the interaction framework for multi-host livestreaming. In Group PK, I led quantitative user research and owned the interaction framework direction for the refactor.

Group Call System — Adaptive Layout Framework

I started Group Call from the layout system because most existing solutions were already making the wrong compromise. Fixed grids waste space on empty slots and shrink every tile to the same small size no matter who is actually present. I did not want the experience to feel like people were being squeezed into a template. So I built an adaptive 1-9 host framework that repartitioned the screen based on participant count and kept visual presence as equal as possible. That equal-presence logic later became one of the strongest parts of the framework.

Persistent Room Logic

Then I treated the room itself as the product, not the original host. That is why I designed Group Call as a handoff-capable room model. Hosting responsibility could transfer, and the session could continue even after the original host left. The current host always had a default successor and could manually reassign that handoff target; once the transfer happened, the new host received a visible label and moved into the anchor position. The point was to make the change feel like a room-state update rather than a new broadcast starting. I also expanded invite logic beyond the original broadcaster so both viewers and other streamers could become the next layer of participants and keep the room alive as people joined and left.

Group Interaction Economy

I also had to redesign the interaction economy, because single-recipient gifting logic no longer matched what the room was trying to do. Viewers might want to support one streamer directly, or they might want to support the energy of the whole room. Those are different intentions, so I made the gift target explicit and switchable between one selected streamer and everyone in the room. Survey feedback made the missing pieces pretty obvious too: lightweight interaction, viewer support behavior, and the camera-on barrier all had to be addressed as part of the same system.

PK Framework Refactor — Session Loop Redesign

For PK, I started by cleaning up the underlying state model. I mapped the old PK flow and newly developed PK features into one unified structure because I did not want the refactor to become another layer of modules stacked on top of a broken skeleton. From there, I designed a waiting-room-to-match-to-post-match loop so preheat, battle, and rematch stayed inside one continuous session. Any streamer who wanted to participate entered the waiting room first; once matching conditions were met, invited streamers were pulled into the same room, more like a custom game lobby than a hard jump into battle.

The most important change was what happened after the match. I sent streamers back to the waiting room instead of dropping them into solo live, because the old ending threw away the social energy that had just been built. “Play again” needed to stay inside the same loop, not come back as a fresh restart.

Team and Match Architecture

I treated team architecture the same way. In phase 1 it mainly needed to support 2v2, but I kept the model elastic so one side could later expand to 3 members for 1v3 without redefining the whole flow. I also kept the visual grouping logic future-proof: teammates shared side and color treatment, while free-for-all formats like 1v1v1v1 were treated as a separate all-versus-all state instead of being awkwardly forced into the two-team model. At the same time, I had to absorb new PK capabilities without triggering unnecessary engineering rework. To make the score-to-percentage logic concrete, I built a ratio simulator (below) covering negative-score and multi-group edge cases. Engineering had a working reference instead of having to interpret spec text. Unlike Group Call, PK host transition followed system-default assignment rather than manual selection, because battle-state continuity needed to stay more rigid and predictable.

Research-Driven Scope Expansion

The research work was what let me push the refactor beyond cleanup. I led the PK quantitative study from questionnaire design to report delivery, then translated the findings directly into roadmap priorities like UX smoothness, matching quality, collaborative formats, and score participation beyond pure gift competition. More importantly, the research gave me the confidence to stop optimizing legacy 1v1 by default. It showed that users wanted richer, more social PK formats.

That is also why I brought real-time score visibility and ranking-style feedback into shipped scope even though they were not in the original plan. To close the loop, I added post-launch VOC tracking so we could later check whether those design decisions actually improved sentiment and acceptance.

Group Call

Group PK

What This Indicates

Group Call showed that multi-host formats can increase both participation and in-session value, rather than simply adding more people to the same broadcast model.

Group PK's clearest wins were in high-value viewer engagement: total points and average spend per gifter increased substantially across markets. But viewer count moved in different directions across regions, and comment rates declined across the board, pointing to a participation quality shift rather than a broad adoption lift. The architecture worked: matching held up, about half of early adopters returned in week 2, and the session loop held together. The open question is whether the format can expand its floor beyond the high-engagement minority it currently activates.

What worked well

The most important shift was recognizing that once a live system involves multiple people joining, leaving, switching roles, and continuing the session together, the real design object is no longer an individual screen. The real work becomes defining the smallest possible set of core mechanics that can keep the system understandable while minimizing edge cases. That framing helped both Group Call and PK become more extensible than if they had been treated as a series of isolated flows.

What was challenging

Refactoring inside an existing feature framework was consistently difficult because many flow and UI decisions had to follow larger structural constraints. Once one part of the system conflicted with that framework, the question rarely stayed local. It quickly turned into whether adjacent features also needed to change, and if they did not, whether those untouched parts would create new constraints for future projects. That made system cleanup and dependency cost just as important as the immediate feature scope.

The Group PK launch also surfaced a tension I did not fully anticipate. The waiting room was a deliberate architectural decision, the connective tissue between pre-match setup, battle, and rematch. But post-launch VOC skewed heavily negative, and a significant portion of it centered on the waiting room: users found the flow more complex than before and couldn't see why the waiting room needed to exist. The architecture logic was sound; the problem was that the value of that structural change never became legible to users in the product itself. The two markets also performed differently: one showed positive viewer and spend movement, while the other's viewer count and spend rate both declined. That divergence wasn't fully explained by the data we had, which made post-launch prioritization harder than it should have been.

What to improve next

If I did this again, I would push earlier for a stronger single source of truth across functions. In complex projects like this, critical decisions, edge-case handling, and framework assumptions tend to scatter across PM docs, design files, chat threads, and engineering discussions. Consolidating those decisions earlier would reduce interpretation gaps, make trade-offs easier to track, and lower rework as the system expands.

I would also treat the user-facing communication of structural decisions as a design problem in its own right, not an afterthought. The waiting room made sense as an architecture choice, but making that choice feel obvious to users, not just internally justified, required more intentional UX work than it received. When a structural refactor creates new UI vocabulary that users haven't seen before, the design job isn't done when the system is coherent. It's done when the system is readable.