Designing Party Play across HypeHype

HypeHype had social features, but much of the experience was still solitary. Adding a friend involved unclear labels, weak feedback, and disconnected entry points. After connecting, players lacked clear ways to stay together across games, and relatively few games were designed around groups.

Our bet was that helping players form and keep more connections would give them more reasons to return. Within the dashboard cohort, players who already had friends also showed higher retention. That did not prove that adding friends would improve retention, but it gave us a useful direction to explore.

I organized the work into four initiatives. They separated first contact, ongoing relationships, group continuity, and content. The plan also made one dependency obvious: parties needed games that were actually worth playing together.

The product direction was to place players into parties automatically when they entered a game. The goal was to give solo players a group without first asking them to find and add strangers.

I proposed a party-entry panel that appeared as the game opened. It introduced the party system, showed who was in the party, and encouraged the group to start socializing. Early versions included suggested messages such as “Let’s go!” to make starting a conversation easier.

Testing showed that the panel was competing with the game. One tester repeatedly pressed “Let’s go!” because they thought it started the game or dismissed the panel. It actually sent a chat message. The party-entry panel, the game’s own prompts, and an automated tutorial were all asking for attention at the same time.

I iterated on the panel’s size, timing, and transition. The later design reduced the introduction’s visual weight and moved the ongoing party state into the persistent panel at the top of the interface. This kept party access available after the entry panel disappeared.

Making the introduction smaller only addressed the first few seconds. Players still needed to understand whether they were in a party, where everyone else was, and how to follow them when they moved.

I chose to keep the party visible in a persistent panel at the top of the app. It showed the group and gave players access to voice and other controls from Home, the feed, and games. I also designed the in-game party menu and states for joining, leaving, switching games, permissions, and errors.

The party and the current game were separate states. Leaving a game did not necessarily mean leaving the party, and members could end up in different games. The panel therefore needed to show both who was still in the group and where they were playing.

In one playtest, a player left a game, saw in the top panel that the rest of the party was still playing, and used it to rejoin them. In the survey, they specifically liked being able to see when party members changed games and join them easily.

Across playtests, internal testing, and my own audit, the live experience still had gaps. Party information could become stale. Joins failed or took too long. Some players entered an empty party or could not see the other members inside the game. Chat labels changed between contexts, and some notifications led to the feed instead of the friend’s game.

We were adding these flows to an interface that already had technical and UI debt. Existing controls competed with party objectives, game prompts, tutorials, and the concurrent AI pet project. Design and implementation moved in parallel, so some tests still reflected an older UI. That made iteration slower.

I worked with engineering to separate interface fixes from problems in matchmaking, game behavior, notifications, and voice. Some party states remained unreliable.

Automatic parties were meant to create a first encounter. The next question was how to keep the people worth playing with.

I chose to show a post-game prompt that suggested recent party members as friends. The timing mattered. Asking at the start meant asking players to add strangers. Asking after a shared game gave the request some context.

I also mapped the wider friend journey. The intended path was to meet someone in a party, play together, add them, and find or join them again later. That meant the work could not stop at the post-game prompt.

I redesigned the Friends page and friend-adding flows, then separated three actions that had been easy to confuse: adding someone as a friend, inviting someone already in the app into the current party, and joining a game that a friend was already playing. I placed each action closer to when it made sense instead of forcing everything through one page.

The released scope included automatic party joining, the persistent party panel with core voice controls, an in-game party menu, party invitations, the post-game friend prompt, the redesigned Friends page, and updated friend requests and friend-adding flows.

My project notes recorded the share of daily active users with at least one friend rising from 20% to 63%, at least two friends from 6% to 40%, and at least three friends from 3% to 29%. The available iOS dashboard for selected countries shows the same broader trend.

The first two initiatives targeted these metrics, but several releases affected the same journey. These included party changes, friend-adding updates, the invite-friends promotion, and the concurrent AI pet project. The increase cannot be assigned to one feature.

The project ended too soon to measure whether Party Play changed long-term retention.

The hardest problem was not another party screen. It was giving the party a good reason to exist.

My audit and the playtests exposed empty games, invisible party members, and content that was not designed for groups. None of the four testers in the latest round noticed the party goals. Some social games shipped, but games that were not designed for groups remained the most played. The interface alone could not turn those games into a shared experience.

Voice chat introduced another problem. Testers struggled with mute, volume, and leave controls, while sudden speech could be loud and unwanted. In one session, a player rejoined through the persistent panel, then tried to leave later parties after an unexpected voice experience.

If I did this again, I would start with a smaller, coherent release: reliable party and voice states, a small set of games built for groups, and clean measurement for each release. I would test that complete loop before expanding automatic parties across the platform. Now, when an experience depends on content or system reliability, I plan those dependencies from the start.