Part II: Less Steps more Sign Ups
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 II in 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!
In the first part of this series we talked about how we removed the need for an email confirmation in our sign up flow – undoubtedly the single most disruptive step in any sign up flow as it sends your users away from your app and into the black hole that is their inbox.
In this article we’ll talk about how we went from this:
…and we’ll look at how we improved the all important first run experience inside our app.
Simplifying the Sign Up form
Our create account page was typical of a large percentage create account / sign up pages you’ll see today. The information being asked for is generally either required (a password) or at least very useful information (a first & last name). Obviously at Visible we need this information too, but what we don’t need to do, is ask for it before our users have even tried out our app!
Instead of asking for basic profile information, we decided instead we could use these inputs from our user to get information that will help them get setup in our app for their first run experience. We want to be asking ourselves every time we go to ask our user for information or to do something – is this helping our user get to their end goal? By taking a first and last name and a password, this is not directly helping our user towards their end goal. It’s nice to have a filled out profile but we can deal with that later and a password is only required for returning to our app if they so wish. If our users don’t see any benefit in our app in a first run, it’s unlikely they’ll want to come back anyway so we can deal with this later!
(To deal with the password we send our users a welcome email with a link that invites them to set their password. This does 2 things: it allows us to verify their email and they can then set their password once they’ve decided they want to return to our app.)
In the next step in our sign up flow, we ask our user to setup a company. Visible is all about helping companies tell the story around their data. So without a company to talk about, our users aren’t going to get very far. We ask for a company name and a website (which allows us to pull all the information we need for the company profile from AngelList and Clearbit).
Note: In a future release we aim to remove this step and take this straight from their company email! We also plan to allow the user to input their email address on the marketing site before clicking Get Started to further reduce friction.
At this point we have all the information we need to let our users into the app and we’ve only asked for three inputs (of which one is optional). This is still 3 more than we’d like but soon it will be only one! 🙂
The first run experience
What happens from here is crucial to your success in onboarding your users – the first run inside your app. You might be forgiven for asking for a password at least 12 characters long with an upper and lowercase letter, but if it’s not obvious what your user needs to do once their inside your app – there’s little hope you’ll retain even 10% of your visitors. And visitors is all they are if they don’t come back.
The first run experience unfortunately is often one of the most neglected and overlooked experiences in an app. It can become very difficult for you (regardless of your role or involvement with a product) to look at your app from a first time users perspective. It’s possible it’s even been quite some time since you’ve even signed up for your app and seen all those blank screens and even when you do, it will be all too obvious to you where to get started.
Luckily for us, we get a lot of sign ups everyday thanks to the very hard and excellent work of our Marketing team. But we could see from our analytics and our customer support requests that we had a lot of this hard work going to waste with users dropping off like Lemmings at every step of the way. If you don’t have this luxury of users coming to your app simply get some users in to use your product and do some testing with them. Note where they get confused.
Up until now we’ve been leaving our user in our app largely in the hope that they will figure it all out – the design and interface should be so clean, simple and clear that it should be obvious right? Unfortunately that’s not always going to be the case. For Visible, we require our user to do 4 things before they can really see the benefit of our product.
- 1. Create a Company
- 2. Get some data to track
- 3. Choose how to Visualize the data
- 4. Provide some context around the data.
Our sign up flow to this point has only taken them past step 1. That leaves a lot of work for our interface to keep things going and only after step 4 can we be confident that a user has seen the benefit of Visible.
Solving the problem
There are a number of ways to go about solving this problem. Many of which you will likely have seen in various apps and most of which you will have frantically skipped through as if their very presence on your screen was shortening your lifespan. Product walk throughs. They can take many forms. Modals with lovely illustrations, tooltips popping up around the app usually beside buttons begging you to push them, dummy content where the app is already full of content you haven’t created. Not all examples of these are bad and they have always been implemented with the best of intentions. To help our poor user through a difficult uphill climb towards that ‘aha’ moment in the product.
The best ones however, are at least interactive, require some meaningful input from the user and don’t just involve the meaningless clicking of a series of buttons. For Visible we designed a 3 step interactive walkthrough which takes our user along the shortest path towards fulfilling the value proposition of our product.
The desired outcome is to have a user that understands the steps involved in getting value from our app. Not one who has just learned in which order to click the buttons to get from A → Z. This also ‘future-proofs’ our setup guide as it’s not based on the location of a particular button on a given screen. It aims to provide a genuine engaging understanding of how to get setup in Visible.
And if a user does decide to skip our walk-through, we’ve created a setup guide that can be referenced (also dismissible) to tell them where is a good place to go next in our app.
The biggest takeaway we got from this process was to ensure that every time we think to ask for information from our user, we need to ask ourselves this question – will this information help us get our user towards their end goal? And not our end goal. A successful onboarding flow should not be measured by the user having completed all the steps in your onboarding flow. It should be measured by whether we helped our user achieve what they set out to achieve when they clicked that Get Started button on our marketing site.
A note on security
We already mentioned this in Part I but we can never be too secure. You should always invalidate all the sessions when you set or change the password. Imagine the following scenario: An attacker signs up with the victims emails, the victims (don’t ask us why) clicks the confirmation email and set his password. If you do not invalidate the sessions, the attacker now has a fully functional access to the victim’s account. Always invalidate all the sessions when you set or change the password!
In Part I we mentioned to invalidate the session on email confirmation if you asked for the password at signup. But now that we ask for the password alongside the email confirmation, we can greatly improve the UX. The user types the password they want, we set it, invalidate the sessions and use the password again to create a new session. This would have been impossible if the password was set at signup, we would have had to ask the user to login again (and no, it is absolutely not ok to store the password in localstorage ;).