You do not need email confirmation in your sign up flow

Karel - March 4, 2016

In the last 2 months we started to revisit the first experience you get when you land on Visible. It led to a lot of great conversations and we learned a lot in the process. This is Part 1 of the story of our journey.

  • Part I: You do not need email confirmation in your sign up flow
  • Part II: Less steps more sign ups! (coming soon)

When we initially built Visible, we overcomplicated our sign up flow:

  1. Create an account with an email and password
  2. Thank you message: “Please confirm your account”
  3. Go to your inbox, click the “Confirm your email”
  4. Thank you message: “Please sign in”
  5. You still there? Now you can actually start using the app…

It might sound familiar to you. It is how many applications work today. Up until recently, we justified this terrible experience in the name of security and because, well… everyone is doing it! But guess what? There is a much better way!

Why do we even need email confirmation?

I have yet to find anyone telling me they like to receive email confirmations. For the user they are fucking annoying. They are needed to verify a user is the legitimate owner of the email they used to sign up. For Visible, this verification is important in couple places:

  1. A user can send Updates via Visible. We make it look like it comes from the user’s email address, making the Update more personal. However, this could lead to a user impersonating someone else. E.g.
  2. A user can also invite someone to join Visible. If we don’t confirm the invited user’s email, they would be able to see invites and entities associated with the unconfirmed email. Not very secure.

This is not the exhaustive list but this captures two major use cases: make sure the user is the rightful receiver of the data and that they are not impersonating someone else. Accounting for these uses cases we set out to reduce friction in our sign up flow without sacrificing privacy or security.

What does signing up look like without email confirmation?

  1. Create an account with an email and password
  2. That’s it… you’re in!

We reduced a 4 step process to 1. Previously, the user would have to go to their inbox and often the confirmation email can take time to arrive or even end up in spam causing them to hang around looking at their inbox pressing refresh frantically, or worse – get distracted by more pressing matters waiting in their inbox and not return to the app. Now you can experience our product right away.

How do you access the limited features then?

Well this is where you are going to blame me for the catchy title… you need an email confirmation :troll:. As soon as the user wants to take one of the limited actions mentioned above, we prompt them with a message explaining “For your security, because we really care for security, this feature is only available once you confirm your email.” For example, when an unconfirmed user wants to write an Update, we let them go through the entire experience – they can create the Update, choose who to send it to, add charts… but as soon as they click send, we show a message: “We send Updates as if they come from you personally. That’s why we need you to validate your email first. We just sent you an email confirmation.”

Email confirmation is still painful at this point, but at least the user understands why we need it. It is not an arbitrary requirement that you need to go through first hand. The beauty is that if the user doesn’t need our application, it was a quick in and out experience, no hard feelings and as little time wasted as possible!

Notes on security

This article is very focused on the user experience of the signup flow. You do need to be aware of the security concerns involved in building such a flow.

What if the user never confirms his email?
We will automatically log him out after 48 hours and send him another email to let him know. This gives an extra incentive to confirm his account in a timely fashion.

If you don’t validate the email, any user can signup as
Yes… but Visible will be very lonely for them! And it will only work for 48 hours. You can create accounts on behalf of others, but you won’t be able to do anything harmful. The good part is that these people will hear from Visible. The bad one is that it is not the best way to start a conversation. If Elon doesn’t care for Visible, he can just discard the confirmation email. And in the event he changes his mind some day and tries to sign up, he will get an error saying he already has an account. At this point, there is no other way but to reset the password and follow the instruction to change the password. While this is an issue, it is minor compared to the benefits. This issue could also be addressed by deleting old unconfirmed user accounts.

Another thing to note is that you move from an architecture where everything is gated to a 2-level gating. It adds extra work on your backend because depending on the action, you need to check if the user is authenticated and if the user is confirmed. It is not complicated but it is important to keep in mind all the time, especially as you add new features later on you will need to ask yourself: “should the user access this feature if he has not confirmed his email?”

When a user signs up for Visible we do not ask for a password. It is only when they click the confirmation email that we actually ask them to pick their password. We will cover this in greater detail in Part 2 of this series. If you require a password at signup, we think it is important to invalidate all user sessions on email confirmation. Imagine an attacker signing up with the victims emails and the victims (don’t ask me why) click the confirmation email. The attacker now have a fully functional session. We really recommend you invalidate all sessions, even if it means that your user will have to login again (which is why we don’t ask for the password, but more on that in Part 2).


We went from a 4 step process to 1 and we made the application resilient to email deliverability issues. We moved the pain closer to the actual benefit. And we let the user test our application with no strings attached. It definitely was some extra work but as the data suggests, it was well worth the effort!

[Update March 8th, 2016]

We got some great comments on Reddit and DesignerNews and wanted to address some of them here:

Is this a one-solution-fit-them-all?
No! Our intention is to share our experience. We do not pretend that this flow is the ultimate one or applies to every situation. We are B2B SasS and this flow makes sense in that context.

This is misleading, you give the sense that you are done after entering your email when in reality if I want to sign up from my computer and login on my phone, I can’t until I have confirmed my email and set my password. – joe_archer
That’s a great feedback and we definitely agree! We have added to our roadmap to better inform our users that we let them in to test the product but that we expect them to confirm their email to experience all the product’s features.

How having people sign up and only validate when they want to perform a restricted action is any different to allowing things publicly and making the user sign up to do the restricted stuff?
We think it is true for certain types of products. Visible let’s you create a company and store it’s business data. It feels weird to do that out of an account because it might give the feeling it is public. Letting users access the product publicly make a lot of sense for public facing products (like a forum) but feels weird to us for a private B2B SasS tool.

Also, we get the user’s email so we can try to reengage a user that churned. It can lead to some valuable information about how your product is being used.

Email confirmation is an expected step in a signup flow, it provides a sense of safety and privacy.
It is common and users probably don’t even think about it anymore. It does not mean it is a necessary step. Security and privacy should come first no matter what. That’s why it is critical you prevent impersonification and identity thefts. We did that by limiting any critical feature.

If you sign up as (someone already did), so what? You have access to absolutely nothing from Elon Musk, you can’t contact anyone or share your account or anything. You are locked in a fake account for 48 hours. What’s the point?

Security should always be a primary concern, but we think it is stupid to design interfaces for the 10 people that want to test our security versus the thousands that rightfully signup with their email. We designed our new flow for them and we think we provide a much better experience than before.

What if the user made a typo in their email?
This is a pain point that the traditional signup flow addresses slightly better because you can’t take any action unless you validated your email. Since we let you in, you can create some content that you will lose access to within 48 hours. Both flows kinda suck because you never receive the confirmation email. But how can we prevent users from losing their work?

We added to our roadmap to notify the user after a certain time of usage to confirm their email. It would be non-blocking but it gives the user a chance to review the email address and change it if there is a typo in it.

If the user waits 48 hours and the session is killed, our customer support team will be happy to assist. We can compare IPs for instance to make sure the user is the right person. Then we can update the email address and make sure the user gain access back to her work.