People in the identity world worry a lot about the NASCAR problem.
that showing a large set of buttons will hurt conversion rates (because of the paradox of choice
) and confuse users who don't remember which IDP (identity provider) they used on a particular site+device combination.
I don't think that's a big problem nowadays.
That's because we're down to a fairly small set of viable identity providers (henceforth known as IDPs). Most of the others are either dead(MyOpenId
), new (Amazon Login
) or only useful in specific niches (GitHub, Instagram, Tumblr, LinkedIn etc).
If we look at Stack Overflow's data
we see that 5 IDPs are used by 98.6% of visitors but everybody has to deal with the cognitive load of choosing between the 12 buttons and 1 form field.
Reducing the set of buttons to 3 would still give users a choice whilst reducing cognitive load. By cutting down to just these 3 IDPs they'd have covered the vast majority (in Stack Overflow's case 92.02%) of potential users of their site and greatly simplified the experience.
However if you prioritise providing access for 100% of your users over providing the best possible experience for the majority then you have several alternative strategies available to you:
If your goal is optimising the percentage of users who sign-in and making sure those people get the best possible experience then here's what I suggest:
However there's still the situation where a user prefers different IDPs on different machines: for instance if they work in a company that blocks Facebook at the firewall or they prefer Google+ on Android but Facebook on iOS. For those users a naive NASCAR implementation leaves them with one account on your service per IDP.
The easiest solution to is to ask for the user's email address and use that to correlate all the accounts they use to login to your service. That way the user never has to worry about creating duplicate accounts. Of course this does restrict you to IDPs who can offer a verified email address.
The only IDP this excludes is Twitter. If you are using Twitter as an IDP then you'll have to either capture (and verify) the user's email address in a post-registration step.
Sometimes you have to do things the hard way. Usually it's because you have large numbers of accounts with unverified email addresses (for instance if you used a standard OpenID IDP or used Twitter without capturing and verifying email addresses) or you're migrating users from one IDP to another.
In that case you have to provide a 'connect flow.' This is where the user signs-in to your service with one IDP and you ask them to 'connect' with additional IDPs. Afterwards you know that the same person owns that set of accounts even if they have different email addresses associated with them.
The heuristics above mean that the NASCAR anti-pattern doesn't have to harm conversion rates or UX.
If you'd like to learn more about this stuff I'll be attending Over The Air 2013
where I'll be walking people through examples of these heuristics in production and talking about the multi-device multi-platform post-NASCAR future of identity. Join me.