I don’t believe email confirmation or password confirmation are desirable in web apps for early-stage startups.
We wrote and maintain a user authentication and authorization Rails engine called Clearance. It serves a narrow focus for users to sign up, sign in, sign out, and reset their password, all using their email address and a password of their choice.
Clearance is almost 3 years old but we still use it on almost all of our projects. Each new project is an opportunity to re-evaluate what’s good and what sucks about Clearance.
Early on, our goal was mostly a great experience for developers, seen in things like:
- Generated Cucumber features
- Shoulda test helpers
Lately, our goal is a great experience for users, seen in things like:
- No email confirmation
- No password confirmation
- No 403 Forbidden status code (while technically correct, Chrome and other browsers display a scary screen for 403s)
- HTML5 email fields (so iPhone users and others get the @ sign on their keyboard)
- Lowercasing all emails (so iPhone users whose keyboard defaults the first letter to uppercase can still sign in without confusion)
See the CHANGELOG for more. The most unusual decisions were the confirmation decisions.
When you sign up, you’re interacting with the product for the first time. Maybe you’ve heard good things from friends and have skimmed the landing page. Now, you want to try it. Your purpose is to get your hands on it.
So, you enter your email and password, then press “sign up”. If you’re presented with a screen like “please check your email to confirm your account”, you’re kind of bummed.
Maybe you have GMail open in another tab or maybe you’re an ⌘+Tab master and you flick over to Mail.app real quick, see the confirmation email, open it, click the confirmation link, which opens a new tab in your browser, signing you in and presenting you with a screen like “thanks for confirming your account”.
You just took about five actions, made about three decisions, and this is if you’re very savvy and already have your email client open. That, to me, is a burden. Why would you want to get your relationship started with a potential customer by burdening them?
We have numbers that show you lose customers this way. In one example, we have a consumer app with 9,204 email sign ups, but only 4,607 confirmations.
That’s a 50% conversion rate between a user declaring their intent to try the product and actually trying it.
By removing the email confirmation step, our conversion rate goes to 100%. Meanwhile, the user has only had to enter two fields, press “enter” or a “sign up” button, and they’re immediately signed in and using the product.
We think what we’ve provided now is a good user experience but you could argue that making sure the app can easily recover when someone mistypes their email address is also providing a good user experience.
For the moment, I’m trying to not let edge cases dictate how the majority of users interact with the library.
It’s not a problem yet. As an early-stage startup, your problem is attracting, converting, and retaining users. Focus on that problem first, and deal with spam later.
Have you ever enjoyed typing your password twice when you signed up for a product? The answer for most people is “no”, and that should drive this decision.
By default, Clearance signs users in for a year. How often will people need to use their password? It depends on your app, but likely very rarely.
There’s also a password reset, which incidentally does rely on email confirmation. In this case, I hope the extra steps evoke more of a feeling of “that makes sense, they’re securing my account for me, someone who’s invested time into their product”.
We’ll continue to test how people feel about the experience in each real product where we use Clearance. If my hypothesis that people feel good about the email confirmation on password reset turns out to be incorrect, I’ll experiment with the default copy in the flash messages and email body to see if we can move the needle on user’s feelings that way before changing the feature.
I’m excited about these user experience-driven changes to our open source library and I hope you’ll put them to the test.