Sang Han

Hamul

Hamul: Social-first voice and video communication for gamers

Hamul was a desktop app focused on making gaming with friends feel more social. Players wanted lightweight video, voice, and reactions that worked across games with minimal setup. Hamul created a communication layer built around presence, expression, and fast coordination for small groups.

ROLE

Product Designer

Team

CEO

Eng manager

3 Engineers

Timeline

June 2021 - May 2022

Tools

Figma, Adobe After Effects, Adobe Photoshop

The Problem

When I joined, Hamul had the bare minimum for video chat. The job was twofold:

raise usability and feature depth to compete in a crowded comms space, and
build a distinct identity that made Hamul feel social-first, not like another Discord clone.

We were shipping fast while the foundation was still being built. I had to design the infrastructure and the product in parallel without slowing engineering down.

The Discovery

Beyond Replication

Copying competitor features wasn’t a strategy. Hamul’s edge was social-first gaming communication: small interactions that create the feeling of being together, even when you’re not in the same game or even playing at the same time.

That became the north star: design for group dynamics, not just voice and video.

The Framework

Principles

Fun over Formality.

Prioritize creating an environment that fosters joy and laughter over a more formal approach.

Impact over Incremental.

Deliver unique features that captivate users, over incremental improvements.

Simplicity over Complexity.

Focus on intuitive user experience over advanced features that complicate interfaces.

Community over Individual.

Emphasize collaborative community building experiences over individual journeys.

Research approach

We didn’t have a dedicated UXR team, so I used lightweight research that matched our pace: competitor teardowns, guerrilla testing, and direct observation of users in the product.

One quote kept showing up in different forms:

“Sometimes I just want to hang out. I might be watching youtube while my friends are playing. I still want to socialize but not play.”

That shaped a key product truth: we weren’t only building for “in-game comms.” We were building for ambient social presence.

Key Bet #1: Make "start a party" the growth engine

The highest-leverage loop was parties. Party creators (producers) triggered the flywheel: a single party created activity for multiple users.

The problem: starting a party was high friction. On PC, getting two people in the same place at the same time is hard. If you don’t successfully form a party, you never experience the product’s value.

So I focused on removing uncertainty and making coordination easier.

What shipped

I added online presence inside the chat log, so users could see in real time if someone in the thread was active and ready to join.

Impact

That small change increased party 2+ DAU conversion by 8%, and improved our funnel conversion from 15% → 23%.

Key Bet #2: Build Messaging as relationship infrastructure

I built the messaging system from the ground up and set clear goals:

public chat should help people meet and coordinate quickly
private messaging should support longer-term relationships and repeat play

The tradeoff wasn’t “ephemeral vs saved.” It was speed vs depth. I prioritized a reliable core messaging UX first, then staged enhancements (links, attachments, GIFs) behind stability and performance work (pagination, navigation, long logs).

Key Bet #3: Homepage as a retention lever

Party creators drove retention, so the homepage had one job: get users into a party fast.

We aggressively surfaced active and popular parties with clear calls to action. I also designed the homepage to reorder itself based on a user’s behavior so the most-used actions stayed closest.

One constraint I held firm: the hero area stayed consistent, so the page never felt chaotic even as it adapted.

Prototypes

Prototypes were my main alignment tool. They let me validate interaction patterns quickly, move faster than static comps, and reduce ambiguity during engineering handoffs. I used prototypes to communicate the “feel” of the product early, then later to clarify edge cases and complex flows.