Mobile app playbook: account systems and social login

In last week’s post, we covered tips for building a usable app when you don’t have a dedicated design team, and tips for starting your app with a stable foundation.

The next few posts in this series will focus on common app services and components, and how we thought about our choices and tradeoffs when adding them into our own apps.

Part three: accounts and social login

With the exception of my BART trip planner, every single app on my phone features some kind of account system. Sure, the approach is different from app to app — some won’t let you access any features or content until you’ve created an account, while others rely on local data storage until you share information or sync your account to a remote source. But at the end of the day, each app offers the option, the ability to track who you are, manage your preferences, and remember your habits.

But people’s online identities generally aren’t static. They pick and choose who they want to be given the context of what your app does. In my case, some services get my email address; which address they get (work, personal, college, my first AOL account from 1995) varies. Others get different social identities. Others get my phone number.

As a person who uses apps, I care about:

• Control. Does creating an account enable the company to contact me? If so, how? What personal information am I sharing when I register or log in? Does this app have the ability to post as me, or contact my friends?
• Expediency. Exactly how much typing do I have to do one-handed on this 5” screen just to log into your app? This can be a major barrier for first time users, and for people who have forgotten their passwords.
• Sharing data. Is it convenient or a better experience for me if you have information about me from another app? Does it save me having to type more or fill out a profile (see “Expediency”)?

As an app developer, you should probably care about:

• Conversion rates. This is the big one. If people need an account to use your service, ideally 100% of those who open your app would create an account. We all know the conversion rate is not even close to that. More on this topic soon.
• Getting data you can use. What about user identity matters to you: their interests? Access to their social graph? A way to contact them? Distinguish between a need and what’s nice-to-have — and if you get their data, be sure that your customers get some value in exchange.
• Encouraging growth of your app. If you ask people to share your app with their friends, they’ll likely share using the same identity they’ve chosen to identify themselves to you. You may want people to log in first with their email address, but later want them to sign in with a social service in order to share more broadly. It’s not uncommon for apps to ask for multiple logins for that very reason.

From our own experience, here are a few tips for how best to meet everyone’s needs:

• Motivate the login. Let people know why you need them to log in. A simple sentence like, “Sign in to customize your FooBar experience!” goes a long way in persuading people it’s a good idea. If this is their first experience inside your app, you have to gain their trust. Justify any requests for data from other services and be crystal clear about why you’re doing with it.
• Give people options when you can. Earlier, I suggested you identify what information you really need from other services, and what’s just nice to have. Maybe all you need is a consistent identifier. In that case, you can give people a choice of how they log in, which improves conversion rates all around. This also opens doors for a broader range of people to use your app. Not everyone has social media accounts; not everyone has an email address. Don’t prevent these people from being able to use your app. We’ve seen that login with Digits bumps conversion rates to 85%, because every mobile user has a phone number.
• Allow a deferred secondary login. Maybe getting started in your app only requires a user identifier to save data, but sharing to a social network or inviting phone book contacts requires a specific type of login. In general, social conversions improve when you defer the prompt for people to login until the benefit is obvious (e.g., you clicked “Complete my profile using Twitter,” so you need to login with Twitter).

In Furni, you don’t need to log in to view furniture; you do if you want to save favorites or see items your friends liked.

• Persist sessions sensibly. In some cases, if a person is active daily, weekly, or even monthly, the activity is enough to keep a session alive. Other apps that require increased security, like banking apps, may require a login on every open, and end sessions if the app has been backgrounded too long. Decide how frequently you need people to log in, and, where appropriate for user security, consider using touch-screen friendly options like touch ID on iOS, one-click social buttons, or a custom pattern.
• Handle logout gracefully for all associated services and sessions. Some people prefer to log out of services when they aren’t using them; others may have multiple accounts in your app that they want to toggle between. Be sure that your app handles both scenarios.

That’s enough preaching. What did we do in practice when we built our own apps?

When we built Cannonball, we gave people the option to log in with Digits or Twitter, or skip login at the start so they could just start creating poems. We gave people options, check. Allowed deferred login, check. Persisted sessions sensibly, check. Made switching accounts straightforward, check.

It looks like we did OK, but if you’ve dug into the code for Cannonball, you may have noticed that even though the app features both Twitter and Digits login, the Twitter and Digits sessions are never used by any other piece of code outside the login controller.

In fact, Cannonball doesn’t even have a backend to store identity or the poems people created – it’s all just in a local DB and never synced anywhere. We did this for the sake of expediency, and also sample code readability: when teaching people to use Fabric, we shouldn’t make them learn 3-5 other tools just to get the sample running.

Furni was intended to demonstrate a more complete, “real world” app. People could browse content before using Digits to create an account; later they could include their Twitter handle to contact customer service, or their email address so the store can send them receipts. We didn’t bother writing a separate email login option; asking the user to let us pull the email address directly from Twitter saved us the trouble of building out an entry form. The app makes use of phone book contacts through Digits, and also sharing through Twitter.

So we followed our own best practices, but that meant we had a new problem to deal with: a tangle of optional login identities, and the requirement that we sync people’s data properly across devices.

Next week, we’ll dive into how we thought about designing a backend integration, handling account syncing, and more.

As always, Tweet your tips, opinions and questions to #MobileAppPlaybook — we’re listening!