You shall not pass!

Eyowo was a service that made it easy for people to accept payments online. Its appeal, and primary unique selling point at the time was that it managed to consolidate the various possible means of electronic payments run by different companies into one interface. This greatly reduced the barrier of entry for potential e-commerce players in terms of cost and ease.

Soon enough, we identified opportunities to do interesting things with the service. We could determine people’s spending patterns based on what they buy, websites they buy from, and how often they shop online. Best of all, we can have this information available to the shopper. A bonus surely wouldn’t hurt. Right? Thing is the users had to login to view this information. How do we get them to set their passwords? An early implementation of the Eyowo payment page had a login/register interface that comes up before payments (the crux of why they got there) can be made. This was quickly thrown out of the window as a potential drop-off point and we settled with asking shoppers to provide their email address with every transaction - they could finish their registration later, if they wanted. No pressure.

This worked out pretty well - not the fact that people registered eventually to view their transaction history and other statistics, but that they didn’t have to. The last estimate of people who eventually did register was way less than 10%, but we ended up being praised for the friction-free checkout process. Another win for lowering entry barriers.

Now to typical new user registration processes. At the bare minimum, the job of the registration form is to collect information that will help identify and (authorize) the user to your website at a later date. What is important to you however, and the user is the use of your service itself. If we could junk the registration/login process and still be able to keep user data, roles, permissions, etc organized, why wouldn’t we? But we can’t - that’s a job for God. How can we make this process friction free however? That’s a noble and worthy goal.

Most user on-boarding processes on the web today can be put into any of the following categories:

1. Fill a sign up form > Wait for email with verification link > Click verification link > Login > You’re in.
2. Fill a sign up form > Login > You’re in with reduced functionality > Verify later at your convenience.

With the first, the user has to jump through hoops before they can see what your website, service or whatever has to offer. Eyowo registration process took this form. There are 3 drop off points in that scenario. A percentage of signups will close your page and not come back after filling the form. Another percentage of those who think ok, its fine.. I’ll click the verification link later will forget to do so. Yet another percentage will not enter their usernames and password at the login page that comes up after they click the link. These numbers might not be significant. Truth is, I have no idea what the average is and I will not pretend to do so. But was it your plan to drop potential users before they even had the chance to see your application? No? Ok. Let’s fix this.

First, I believe the login requirement at any point after the registration process is unnecessary. It’s simply an inconvenience. There are arguments that its an confirmation that the user still remembers the details they just set, but didn’t they just set it? Some of them are forgetful? Implement a forgot password feature.

Secondly, having to wait for a verification link is essentially putting a step in the on-boarding process in the user’s court. You can’t transition around it. The only thing you can do is tell them to check their inbox. The flow isn’t smooth. They have to use an entirely different application to move on. Why? The reason they were on the sign up page in the first place was to try out (and perhaps eventually use) your application, remember? Never forget that.

That brings us to the third category:
Fill a sign up form > You’re in with reduced functionality > Verify later at your convenience.

This is as easy as it gets and it’s a good thing a number of developers already employ this strategy. Services like Stripe, Twitter, Amazon, PayPal, readily come to mind. Some try to meld Category 1 into Category 3 by requiring you to verify your Identity via a phone call, which is fine as the user remains on the page for the duration of the confirmation. Let’s called this Category 4. The only problem with this is the the phone call might not come in delayed for whatever reason, at which point the user may have closed the page and moved on. I went ahead to do a quick survey of twenty websites I could think of and here’s what I found:

Category 1 #

1. Microsoft Azure - The flow was botched. I had to start over after the email confirmation as the page that opened was simply an acknowledgement.
2. Xero
3. Slack
4. Heroku

Note: None of these sites required the extra login step after clicking the confirmation link.

Category 2 #

NONE. Thankfully, people are getting less stupid.

Category 3 #

1. Stripe
2. Twitter
3. Amazon*
4. PayPal*
5. Tumblr
6. Pipedrive*
7. Boundary*
8. Cloudflare*
9. IMDb
10. Bitbucket
11. Trello
12. Devcenter.co
13. Evernote*
14. Digital Ocean - So crippled its mostly unusable, but you’re logged in, which is something.

Category 4 #

1. Amazon Web Services - My phone didn’t ring in the first 15 minutes. It was instant on the second try.
2. GMail
3. Twilio
4. Callbase.co

Examining ~20 websites doesn’t make a great survey by any strech, but it gives you the idea. Businesses are beginning to realise the less the friction of on-boarding, the better for everyone.

*These sites completely skipped the verification process. Evernote was extreme. The registration and login form are the same save the buttons, and registration takes you straight to your first note.