Product Pattern: Social Login

A product pattern is a general, reusable solution to a commonly occurring problem. They are intended to help you consider all use-cases (happy, sad) before breaking down into user stories.

At one point or another, you and your product team will begin debating the merits of using Facebook, Twitter or another platform for signing in. The gains to a reduced-friction experience are always accepted, but think carefully about the disadvantages. In the pattern below, I’ll use Facebook as an example, but the scenarios are the same for other platforms.

To think about first:

What assumptions are you making about signing-in via Facebook?

• I‘m assuming this will reduce friction of new user signup.
• I’m assuming that access to the social graph will encourage virality.

What user information do I need?

Do I really need the users email? What do I plan to do with it? (Users generally don’t like giving up their email addresses and will bail). What about their photo and friends list? According to research from Facebook, requesting four or more types of data leads to a sharp approval drop-off.

Really WSJ? A newspaper does not need to `Access my data any time`

How do I want to position this sign-up method vs. my existing methods?

Sign-up needs to be low-friction, don’t give your users an opportunity to be confused. Make one option have a heavier weight to nudge the user.

Coach.me uses the wording “Continue” to encourage FB sign-in. Fancy gives many options without encouragement

What the user is thinking:

• Why do they need so much info just to sign me in?
• Are they going to spam my email?
• Are they going to spam my friends with posts?
• What are they going to do with my data?

User Scenarios:

Happy Path:

• User opens your app, taps `Sign-in with Facebook`
• User is taken to Facebook, and approves your permission requests
• User is returned to your app, signed in, and sees their user profile and photo.

If a user already exists with the same email address, use this account and add the FB data.

http://facebooksdk.net/docs/phone/sso/

Sad path:

• User doesn’t give your app permission to any of the requested data. How would you message this?
• User only allows certain permissions (email but no friends list). How do you message this and fail gracefully?
• User returns later and taps ‘Reset Password`. They don’t have a password because they signed in via Facebook, how do you handle the messaging?
• User revokes access for you app to access Facebook data. Now your app thinks they are signed in, but is getting an error message from FB.

Recommendations:

• It’s best to tie your publish requests to an actual action. Wait until the user is publishing a Story to ask for permission vs. during the sign-up flow.
• Refresh their profile information regularly. Users may change their profile photo inside FB, and can become confused if you are showing the old photo or friends list.

Fail gracefully when:

• A user revokes permission to your app and they then return to your app. App thinks they are signed in, but they’re getting an error from FB.
  - The FB API is down. (happens more often than you think)
• If you already have a user with
  - What happens if a user only allows partial permissions (no email, but profile information). If your app

Analytics to Track:

• # of users that sign in using Facebook (daily/monthly)
• # of users that signed up via Facebook (daily/monthly)
• # of users that started the sign-up process, but didn’t follow through.

Do you see a commonly occurring product pattern that I should write about? Drop me a line in the comments area, or tweet to @nic