You never get a second chance to make a first impression, and that’s especially true in mobile. One of the best ways to ensure no one comes back to your app is to make the time to value (TTV) too long. Specifically, the time it takes between launching an app and getting some value from it should be as short as possible. You should measure and track this over time as your app evolves; it’s an easy filter in applying cold-start and re-engagement opportunities.
On an app I was recently working on, we employed some common techniques to lower the TTV on first launch:
Tear down that sign-up wall
You can thank Apple for seeing more of this — they have started cracking down on apps that throw up login gates before a new user can see any content. A signup flow is at best annoying and at worst a huge headache for people that just want to see your app already. Instead, consider the pieces of content/functionality that you can promote before asking someone to commit to your app.
Skip the coach marks
Yeah, yeah, I wrote a post last year about how UI walkthroughs are sometimes justified in mobile. Even so, that should not excuse you from being lazy. It might take extra work and introduce more complexity, but it’s possible to gradually introduce coachmarks in your app as someone uncovers new screens/functionality. The alternative is that someone will spend time dismissing a mini-tutorial before they’re ready to absorb that information. As an alternative, keep track of the three things those coachmarks explain. If someone doesn’t tick the three boxes after n sessions in the app, maybe that’s a good opportunity to encourage them to use the awesome-yet-hidden advanced mode?
Be judicious with phone permissions
The process of asking for permission is very different between iOS and Android. In the latter, you get a laundry list of every permission the app might need in the future. Some people may breeze past this list and grant access. Others may wonder why a question/answer app needs permission to send text messages, as seen in this thread about Jelly. (It’s so that you can send a question to a friend via sms for answering).
In iOS, any attempt to use a native phone service (e.g., location, camera, microphone) prompts the user for permission at time of use. This generally makes sense — when I click the camera icon in an app I understand why it’s asking for permission to access my camera.
We’d like to use your Current Location
For the app we were building, we wanted to show a list of merchants and near the user. The precision of the search was not important: a user would want to see results that were close but not necessarily sorted by distance. We had a menu to provide searching and filtering options, which also included location. If you tapped on Current Location from this screen, we would prompt for location and if the user denied permission we simply wouldn’t use it. Since you could enter a City/State in the Location field it wasn’t necessary to stop.
We started a new user with this list of nearby merchants, but it bugged me that this meant either prompting for location permission before displaying any results or showing a non-local result set. Both options weren’t ideal. Instead we experimented with using the request’s IP address to geolocate the user. It wasn’t perfect, but got us in the right city without any prompting. Someone could still fine tune the results by granting permission to use their location, but they got a jump start on that process without the dialog. Plus, in the edge case that we got their IP’s location wrong, we were no worse than if we hadn’t tried at all.
It wasn’t a perfect solution, but I liked how quickly we could show relevant results to a new user. Ultimately, you’ll have to make your own calls on which prompts you need before delivering a meaningful experience. The decisions you make for your app are probably different than the ones Pinterest and Twitter make. I simply ask that you be thoughtful in how you first introduce a user to your app, and a low TTV will definitely help.
