The purpose of this post is to describe my journey building and launching a social app at Stanford- describing my assumptions, what I did, learnings, and providing a narrative for others interested in building social apps in a post-Facebook post-Snapchat world (tldr: It’s really really hard).
On college campuses everywhere, students see friends multiple times a day, every day. There’s a bit of planning (albeit not much) with meeting up with friends on a campus. At Stanford, the entire campus is walkable in ~15 minutes so the path to seeing a friend is normally as follows (steps 2 and 3 interchangeable):
- Discover mutual availability
- Pick a location/activity
- Pick a time
- Last minute messaging- “I just got here, do you want me to order you anything?”
My hypothesis is that if friends could know where their friends were without having to actively ask, they could see them more often. With location sharing, there’s a tradeoff between privacy and convenience. I had bet that as it was 2015, college students (18–22 year olds) would finally be comfortable with a persistent, always-on location based social app. I leveraged the background location tracking on iOS as well as continually-improving battery life of iPhones to build Outmap.
Outmap showed you where your friends were, on a map, all the time, accurate to the past 10 minutes. I was able to build this in a way that only used ~10% of the battery per day, which is significant but not crippling, and ignored by most.
Here is what the 1.0 looked like. I built this over a few weekends in Fall 2015:
The goal with Outmap was to help friends spontaneously see each other more frequently. There is a ton of downtime on college campuses such as hour-long gaps between classes. People want to see their friends, however the activation energy necessary to find out who is available, where they are, and if they want to meet up is significantly high that people miss out on potential meetups constantly. Simply put, social planning has not been improved by technology beyond increasing the rate of communication (via messenger and chat platforms). The psychological barrier to finding a last-minute lunch buddy is quite significant.
The primary psychological barrier is fear of rejection. Planning a last-minute hangout with any one person is unlikely to happen as it requires the confluence of availability and to a lesser extent, location. Because texting an individual friend at the last minute is likely to result in rejection (non-malicious), people just won’t do it. No one wants to be that person who is constantly hitting other’s up to hangout and frequently being told no, not out of dislike but out of difficulty in synching up.
Down To Lunch, an iOS app, was launched around this time and it offered a one-tap way to find if other friends are available, by blasting all of your friends on the app. What they gained in simplicity however was lost by the negative signaling of pressing the button. Mass notification blasts are not personal and signal desperation. While the virality of their clever (but sneaky) SMS-based invite system allowed the app to propagate around Stanford (and the rest of the country), users did not actually press the button regularly after their first-use (based on my observation of ~100 students at Stanford).
So with the 1.0 version that I built, once it was on the App Store, I went around my dorm (Burbank!), knocking on doors and getting people to download the app. I didn’t just ask them to. I took their phone, found it on the App Store, downloaded the app, and watched over their shoulder as they went through the onboarding process. This quickly unveiled some usability difficulties and signup bugs. Additionally, in a dining hall I approached tables where I knew at least one of the people sitting and did the same with them. This was infectious and spread Outmap amongst that table. After a few hours of hustling, close to 100 people had downloaded and started using Outmap. This method of getting the first batch of users was insanely effective as the community was very interconnected. So even though the absolute user base was miniscule, the users knew many of the other first people that had downloaded the app. Outmap used users’ contact books to automatically friend them with their contacts that already had the app. Average number of friends for this first batch of 100 users: 12.
I conducted a bunch of usability interviews (thank you Sam, Emily, Henry, Cody, and many more) to understand what value users saw in Outmap, what they were using it for, what new features they’d like to see, and any usability flaws they encountered. At this point I was mainly trying to sync up my understanding of what Outmap helps with with what users were actually using it for. Many times there was a chasm between the two. Talking to users is the only way to reconcile this gap in understanding. Also useful was looking at analytics and usage data. While the numbers were too small (hundreds of users) to come to any conclusions about long-term retention and usage, pairing the actual app usage data with the qualitative stories heard in interviews was very effective at uncovering interesting uses.
An unintended consequence of a map-centric interface (as opposed to a Newsfeed-like stream) is the lack of imposed directionality on content. Maps do not impose a single direction of scrolling and feeding information- users can pan in any direction they please. Because of this, users can’t consuming information serially. Seeing a bunch of profile pictures spread through a map was a bit overwhelming for some users. The Flurry analytics showed that 30% of app-opens were resulting in brief panning around the map and then closing the app. I had a hunch that users were not fully digesting the information in front of them. Because they could see all of the content on one screen, they felt they had “caught up”- that feeling of satisfaction after clearing notifications, or reaching the point on Newsfeed where you are seeing recycled posts.
The option I settled on to enforce “full digestion” of the content was obfuscating who was at each location on a map. Instead of showing a recognizable profile picture directly on the map, Outmap showed an emoji. Users could change their emoji to indicate their current “status”. This is how they would be represented on a map. In order for a user to see who was at a location, they would have to tap on the emoji to see the lightweight profile card that would pop-up. This led to users zooming in more on the map, panning around more, and tapping on all of the emojis around the map. Because they had to see the name and profile picture one at a time they were able to take the few seconds to digest, “John is at the dining hall right now”. As a result, there were many more “pings” sent to request hangouts.This was a very counterintuitive design decision as conventional thought would point to maximum “efficiency” in conveying information to users- but it increased the Pings sent by 15x and increased average time spent on app from 42 sec to 4 minutes.
Here’s what this product iteration looked like:
Ultimately 1/3 of the students in my Freshman class at Stanford were users of Outmap! One of the more entertaining uses was when fraternities used it to track pledges during Rush events. This was an awesome learning experience that taught me much more about customer development and shipping a product than previous apps. I took these learnings and pursued onwards with Key, that elaborated on the core experiential insights from Outmap