MessageParty: Chat With People Around You

MessageParty allows users to chat with people in their physical proximity without exchanging contact info. We launched at YC DemoDay and quickly had over 10,000 people download our app. My role on the team was that of a rapid prototype designer, engineer, and evaluator.

The thought came to me of “Why do I need to have peoples’ contact info to send them a message?”. This sparked my idea for an app that would allow you to broadcast messages to people around you.

Our target use cases were anytime people were physically grouped by a shared experience such as in/at conferences, classrooms, concerts, sports games, bars, festivals, and cafes. Alright, so then it came down to translating this idea into an app.

103-1038526_iphone-4s-template-white-iphone-4-template.png

103-1038526_iphone-4s-template-white-iphone-4-template-1.png

Our strange promo video.

Our strange promo video.

A UX Approach: Location-Pinned Chat Rooms

My opinion was divergent from the consensus when it came how to translate this idea into an app. The consensus quickly developed around the idea of having chat rooms which users could create, pinned to the user’s location at the time of creation, accessible by others near that location. The approach of using chat rooms certainly had its advantages: it borrowed well-known mental models from the internet and group SMS. It’s easy to understand. You can clearly see all the people who are members of that chat room, who can read your message, and who cannot. It also means that in a space in which multiple shared experiences are happening (imagine a large conference, festival, or university) that chat rooms could be created to separate messaging happening at the different stages, halls, or classrooms.

However, this approach is not without drawbacks. First, when you want to send a message, you need to make sure there is a chat room for you to do that in. You could create that chat room, but then what do you want to call it? What is the scope/context for the conversations you want to have? Thinking about this is a bit of friction getting in your way. Secondly, and partly as a result, allowing people to create and name chat rooms felt like it could result in the general user experience being one of navigating a confusing junkyard of chat rooms. This would have the user not sure about which one to open to post and view messages, and thus resulting in the diffusion of any potential critical mass there could have been behind communicating unambiguously with people in your same location.

“The people I want to reach might be in a different chat room. If I can’t be assured that people located around me will see my message, then what’s the point?”

An Alternative UX Approach: Messages Travel Like Voice

An alternative approach would be to make it so that there are no chat rooms at all. Instead imagine, as if in the real world, you just shouted your message. Who would hear you? It depends on the type of space you’re in: in a classroom, probably everybody in that room. At a sports game, probably only the people in your section. That’s the design for MessageParty I wanted to build. You would open the app and type your message. No decision making needed.

What messages do you see? By having you set the “listening” radius to match that of your space, you would see just the messages from the space that you’re in (be it a classroom or a concert). In a large space such as a sports stadium, due to the number of people on the app, it could be that the chatter level is too high for there to be a meaningful conversation happening between everyone. (Have you ever been in a chat room with 20 people typing at once?). To handle this, the app could “quiet” people’s messages that come from geolocations past the radius at which meaningful conversations can take place (which is probably closer to that in which, on average, one person is typing at a time). “Quieting” messages could be implemented through many alternative mechanisms such as hiding them completely or by reducing their visibility (through diminished color and/or font size).

This model of having messages “travel like voice” isn’t without downsides, though. For example, because a two-dimensional user-defined “listening” radius is used to filter visible messages, problems arise when separate physical gatherings take place above or below one another in multi-story buildings. Those conversations would all merge into one. Another problem arises because “listening” radii would rarely ever perfectly map to room shape, due to the fact that rooms typically aren’t circular and because people rarely situate themselves in their exact center. As a result, in spaces where multiple events are going on in separate, abutting rooms, users wouldn’t be able to perfectly exclude messages outside their room without potentially excluding some of the messages from within it. Another complication arises from the fact that no two users’ “listening” radii would perfectly overlap; this would result in a user potentially replying to a message that others don’t see, resulting in a confusing conversation flow for some people.

The Approaches Compared

The drawbacks of the design where users create Location-Pinned Chat Rooms **and the drawbacks of the design where Messages Travel Like Voice are both weighty. But one key difference is when in the product lifecycle these downsides most hamper the effectiveness of the app.