Handling Alternate Scenarios for Multiple Sign-Up Options

 The Situation

Product Managers or Business Stakeholders have a ready to go list of Features they want to implement for a bunch of use cases related to a Problem or Opportunity. The approach for implementation is to cover the Primary flow or Common scenarios and to ignore the (sometimes myraid) Alternate Flows or Uncommon. The Alternate Flows are a consequence of combinations of implementation choices, environments and application settings. The key challenge is deciding the initial scope – i.e. which scenarios to cover and which to ignore in the face of no evidence.

Example

For a typical B2C or Consumer application Account Management is a key need consisting of Sign-Up, Sign-in, Sign-out, Change Password and Forgot Password features. The common implementation for Sign-up is providing three choices 

1. Sign-up with Facebook
2. Sign-up with Google
3. Sign-up with Email 

 Consequently, the three choices for Sign-in will be

1. Sign-in with Facebook
2. Sign-in with Google
3. Sign-in with Email

Simple and fair enough, isn't it? Okay, let see a couple of alternate scenarios that can happen

The Scenarios 

Main Scenario

User registers using one method and returns another time to use the same to Login (i.e. User remembers the Registration Type)

Alternate scenario1

Registers using one Social Sign-in method (say Facebook) logs out but returns to use another Social Sign-in method (say Google i.e When user doesn't remember registration type)

 
Implementation Choices

1. If the new social registration method also has the same email address as the one used during the first sign-up then we can have application consider it is a registered email and navigate user to the existing account 
2. If the new social registration method doesn't share the same email address as the one used during the first sign-up then we have no other choice but to create a new account for the same user. Now, should we try to avoid multiple accounts for the same customer?

Alternate scenario 2
Registers using one Social Login method, logs out but returns to use Email Login. This inevitably will lead to credentials mismatch prompt by the application  

Implementation Choices

1. Remind user to use the correct Sign-in method (based on Sign-up) along with prompt for credentials mismatch  
2. Remind user about the correct Sign-in method (based on Sign-up) only when the user attempts Forgot Password feature

The above alternate scenarios can be summarized as below

Signs-Up using	Returns & Signs-In using	Email associated with sign-up and sign-in accounts	Implementation Choice
Facebook	Google	Same	Sign-in to existing Account
Facebook	Google	Different	Create a new account
Facebook or Google	Email	Same, however the login will never be successful	Prompt user to use the correct Sign-in method in a appropriate screen

We might be inclined to say that these are rare scenarios that can be ignored since the chances are slim. Because, the assumption is that once a consumer logs into an application it is more than likely that the user will not bother to logout and if truly or correctly engaged will return to the app before the arbitrary Session-Timeout setting we enforce. Hence, the user will not have to sign-in again and the above situation will not arise.

Session-Timeout

This eventually leads to another decision – What should be the session time-out in an app? The general rule is that for a Mobile App no timeouts are enforced but for a Web App some timeout setting is used with the rationale that we are much more likely to share a Web App (desktop or laptop) with others whereas as much less likely to share a Mobile App (Smartphone). But if an Application has both Web and Mobile Apps how does that work? From my experience there is no technical constraint on enforcing separate timeout sessions and hence an independent time out setting customized for each app can be utilized.

A very popular restaurant recommendation and food delivery app (Zomato) that has both Web & Mobile tackled Scenario 3 (Social Sign-up followed by Email Login) by alerting user about Sign-Up method and providing the option to set a password for Sign-in using Email

The above solution assumes that user remembers the email address associated with the Social Account used for Sign-in. Since a welcome email from the App is usually triggered after Sign-up so it can be assumed that either the user will remember or will search Inboxes to confirm the email used for this App.

Conclusion

Being empathetic to needs of customers is fine but how do we know where to draw the line for the first cut of a feature when it comes to solving the need? Generally, keeping things simple is the norm i.e. Alternate Scenarios can be initially ignored until the utility of the Primary Flow has been validated. However, depending on the situation implementing Alternate Flows initially may be required.

In one of the apps that we built we provided 3 choices for Sign-up and Sign-in as mentioned above. Sign-in at the right moment was extremely important when required as timing was critical to deliver the product experience to end-user (Example:- Live Streaming). Hence, we had implement the Alternate Scenarios as well. Whereas, for another consumer web app although we provided the 3 choices, the timing of the sign-in was not extremely important. Hence, we ignored the Alternate Scenarios.