We've all been there - trying to get back to the group at a festival, meeting up with friends at a crowded place or event. Messages don't deliver because the area is crowded, calls can't be heard clearly because it's too loud. The experience is clunky and unnecessary.
Speaking to consumers uncovered this problem, which isn't well served with existing solutions from Apple (Find My Friends) and WhatsApp (location sharing). The iOS Find My Friends feature was described as feeling too permanent, that the controls were hidden, and that it was the kind of thing that you forgot to set up when you needed it, and would forget to turn off when you no longer needed it. WhatsApp location sharing was considered useful, but wasn't suitable for meeting more than one person, and was only deemed useful for very brief situations - but not for continued access over any length of time.
Importantly - both of these solutions were highly dependent on mobile data and GPS, rendering them virtually useless in densely populated/heavily built up areas, or anywhere that cellular data was poor.
The solution is a social location sharing app, which allows users to share their location with contacts or groups of contacts, for time/event-limited periods. Uniquely, this would not be dependent on mobile networks - allowing for a service that works in all environments.
For any such service to be valuable, it cannot be merely dependent on mobile connectivity, it must be designed for 'extreme environments' (i.e. no connection) in order to provide benefit when it is truly needed.
To this end, I drove an agenda of 'progressive enhancement' - designing a service that would work adequately in unconnected situations, with functionality improving as more connectivity becomes available. As the device connects to different types of data source (e.g. GSM, GPS), we add the additional information to the existing map, enhancing and making the information more accurate.
At its most extreme level, this uses some unconventional approaches, including triangulation of relative positions using Bluetooth signal strength, something that is entirely network connectivity independent, and only improves as more people are connected (perfect for festivals).
Through this approach, the app always provides info and so there is always a benefit to the user, especially when they need it most.
Testing of paper prototypes and interviews about location sharing really pulled out how careful people are about sharing their location - it is a very sensitive and intimate subject, and one that needs to be handled clearly and transparently.
To handle this, I designed a permissions-based system, where a user sends and receives requests, which have to be accepted in order for sharing to begin.
Tracking is always both ways - which reassures users through a mutual exchange.
At any time, location sharing can be ended, which will end the sharing entirely for both users, or if a group, then the user ending the sharing will exit the group.
Designed for play. Elements such as a thermometer are immediately easy to understand, with temperature being used as a playful measure of distance for many children ("warmer... hot... boiling"). This lends itself to hide-and-seek style play, as does the nature of the compass screen. A playful approach makes the product more memorable, and more importantly, social, so that users want to try it out with friends.
My ethnography work highlighted that existing mapping visuals (Google Maps, Citymapper) are visually intensive and cluttered, and tend to require a high level of eye contact for the user to gather the information needed from the screen. With this in mind, I created a very stripped back design to allow for the user to pull out key information in quick glances, without intense study, allowing them to navigate through a crowded or busy place without having their head down looking at their phone.
Part of the growth model depended on leveraging partnerships with brands, festivals, and embedding an SDK into other services. This is because a mesh-based service relies heavily on achieving critical mass within a given proximity - without it, there is less information to power the location technology. By offering a location SDK, all users with the technology would help make each other's relative positions more accurate - something which would be beneficial for other location-driven services (from event apps to Citymapper), and would be beneficial for Friend Finder.