[2020 - 2026]
Increasing Participation and Interaction Through Group Live Systems
Designing reusable multi-host systems for social co-streaming and competitive PK.
I shifted live interaction beyond the single-host model into reusable group systems for social co-streaming and scalable competitive play.
ROLE
Product Designer
SCOPE
Group Call framework, PK architecture, interaction states
KEY IMPACT
Group Call validated multi-host participation, while Group PK established a research-backed path beyond legacy 1v1 play.
01
Overview
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.
02
Product Context
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.
03
Problem
04
Outcome
This work delivered two group live systems built from the same framework thinking:
Group Call: launched party livestream format with dynamic UI framework supporting 1-9 hosts in one session.
PK Refactor: rebuilt PK as a separate competitive interaction system, integrating existing and new PK modules into a scalable architecture supporting current 1v1/2v2 and future multi-party extensions.
05
Role & Scope
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.
OWNERSHIP
Group Call: multi-host layout system, room-state presentation, host handoff behavior, and gifting interaction logic. Group PK: waiting room loop, team-state presentation, score-visibility direction, and how new PK modules fit into one coherent interaction structure.
WORKING WITH
PM, UX, engineering — framework feasibility and implementation constraints.
06
Key Decisions
1
Group Live as an Open Social Format
2
Persistent Room with Host Handoff
3
Unified Competitive Session Architecture
4
Research-Driven PK Scope Expansion
07
Design Execution
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 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.
N-Player Ratio Simulator
Players (2–4)
Range −999 to 999, center = 0Ratio
- Proportional to raw scores
- Sum = 0 → equal split
- e.g. [3,5,2] → 30/50/20%
- Negative scores → 0%
- Non-negatives split proportionally
- Non-neg sum = 0 → equal split
- Closer to 0 → larger share
- Weight = 1/(|x|+ε)
- ε smooths extreme gaps
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.
08
Impact
Multi-host participation
20%+
Early Group Call streamer participation in the first launched stage
Session interaction value
+20%
Higher than solo sessions in total points received.
Send-all lift
+60%
Additional interaction-value growth after shipping the group gifting mechanic.
Invite acceptance
34%
With raise-hand acceptance at 57%, indicating meaningful willingness to join and continue group sessions.
Platform scope
Max 9 Streamer
The framework scaled live interaction beyond single-host sessions and created a shared architecture for future PK expansion.
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.
At the same time, the shared PK architecture reduced future expansion risk by turning group interaction into a reusable platform capability instead of a one-off feature set.
09
Reflection
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.
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.
✨
✨
Made with love, Framer, Codex, and Claude Code