How to build kick-ass user registration flows for your product?

User Registration and Onboarding requires huge design and deliberation efforts. When you start thinking about a user registration page, it consists of 4–6 fields:

• First Name
• Last name
• Email Address
• Password/Confirm Password
• Phone

How hard can it be, right? Let us begin by taking a step back and asking ourselves why we need user registration on the platform:

• We need a way to identify users in our product — This could be for analytics, understanding user behaviour, using the first name in emails or even identifying a user on the platform for other users.
• We need the names for documents like Invoices, Delivery address labels etc.
• You need to authenticate the user — You don’t want unauthorised users doing things on your product like compromising data security & creating junk data on your platform.
• You need to assign roles to the user on the product so that they can only do what they are supposed to do.

Before you begin with the registration flow, you need to map out the entry points. Let us take a few examples to understand when the user is required to enter the registration/login flow:

• For an e-commerce site — the user doesn’t need to log in to browse, search or add products to the cart. Yet, they will need to login to checkout the products from the cart and buy. The site needs to get the customer’s name, address, phone number for delivery & invoicing.
• For an education site like Udemy — the user doesn’t need to register to browse courses or even preview them. To start a course they will need to create an account and log in.
• For any SaaS web application — The user can access the website without logging in. To access the product features it is a must create an account. This account holder could be an administrator who invites other users. Or, it could be a self-registration workflow.
• For on-premise deployed enterprise applications — User onboarding happens as part of the implementation. New users are created and administered by someone in the IT department.

Registration can happen at various points during the user’s journey on your product. You will need to map these out. Some numbers say that upon seeing a registration page, 51% are likely to abandon the website/flow. That’s a pretty big number and I’ve seen bigger ones on some other sites. Larger abandonment rates tend to be for sites that ask for more data without a clear purpose. More about this later.

DO NOT ask the user to register unless it absolutely required. I know marketing needs it but don’t impede user flows.

In TalFinder, we have candidates submitting coding tasks to employers. The employer invites the candidates using an email address. We ask the user for his/her first & last name, allow them to work on the task and submit it for review. We ask for the name so that we can identify the person for the recruiter and the hiring manager. It would be pretty nasty to see a code submission from an email like doomcreator666@gmail.com.

Never ask the user for more information than you need.

I get about 15 messages a day, a vast majority of these messages remain unread. They are promotions from food delivery companies, clothing stores, investment companies and others. Now, if I see a site with a registration page that asks me for my number, I leave.

A good reason to ask the user to register is to provide a better experience for returning flows.

A returning flow is one where the user returns to the application several times to finish a task. Every time the user returns to the system he/she shouldn’t have to start from scratch. Some examples:

• A user taking a course on a platform
• A user who has added items to the cart but hasn’t checked out yet. — A user setting up infrastructure on the cloud.
• In our product, the code dares are full-scale development like tasks. It’s almost as if someone was coding to build out a user story in a sprint. The workspace needs to keep syncing to the cloud so that the developer can resume where he/she left off. We expect the developer to finish in more than one sitting.

The product can handle the experience in a few different ways for unregistered users:

1. Assign the user a token with a fixed validity — The token can be part of a URL and the user can resume the flow using the URL. For this method, you will need an email address so that you can mail a URL to the user.
2. Assign the user a temp password — To resume from where the user left off, the system assigns the user a temp password. The user can enter this password/Unique identifier to resume. Think of WebEx or GoToMeeting where the user enters the meeting ID after clicking on the link. Again, an email address is mandatory for sending the user this information.
3. Present the user a registration option on exit — If you ask someone for information at the wrong time, they will leave. You should ask them the information at an opportune time where the reason is likely to be self-explanatory . For example, If the user wants to leave the system for the time being and return later. The user won’t redo everything from scratch so asking for minimal details is fine. They can log back in & resume, this is the advantage for the user.

Always show the user a context. This creates a sense of purpose.

Sometimes, we click on links that people have shared, they could be links to something on an e-commerce site like a shoe on sale OR say, a post on LinkedIn. On click of the link, the user is prompted for a login/registration before accessing the actual content. This results in bounce rates going up but what is more annoying is when the page/application has lost the context of the destination link post login/registration. Always show the user why they are there. A context is very important. We are in a state of perpetual distraction with messages, links, emails popping up everywhere. A user should never be left on a page without knowing why they got there. There are a few solutions to overcome this:

1. Always specify a relevant redirect URL to which the user needs to go post login/registration.
2. Use deep links so that the user sees what they need to and login only to complete an action. You can use branch for deep linking, I’m sure there are a lot of good products that do this.
3. Show the user a hint of why they are logging in. See example below, this was our first mock-up for TalFinder registration:

Our first registration mockup

Use social logins to reduce friction. It makes the registration process easy.

This requires you to implement OAuth2 — a framework that enables applications to obtain limited access to user accounts on an HTTP service. You can read a good primer here.

When to send a confirmation prompt link to the user’s mailbox?

The answer is easy. How did the user get to your registration page? If an existing user of the platform invited a new user by mail, the new user has come from a trusted source. The confirm prompt can be optional for the user to continue with the journey. On the other hand, if the user went through a self-registration process, you would want them to confirm. You need to take a call based on your exposure if you want the confirmation to happen first.

If you are collecting email addresses or any personal information from users, ensure that you have a privacy policy in place. This is a legal requirement. While it is a lengthy and expensive process to get a perfect one in place, it is easy to draft a generic one. Find another product in a similar space, copy the policy and make edits to tailor it to your requirements. When a very professional one becomes necessary, outsource it to a legal team. Until then, it’s about saving money and being practical.

A side note: Modern web applications need robust identity management systems. If you are smart, you won’t hand write this but use an IDM or an identity manager which manages this. There are several off-the-shelf products that do this and many of them are open source. You can take them begin customising them for your needs. Some great examples are: KeyCloak & OpenAM. Best practices define that your registration pages and logins should reside within the IDM itself. You need to build out login/registration pages in the IDM. IDMs use their own templates like Freemarker(in case of KeyCloak) which are not easy to customise. You will need to consider having standardised flows and preventing customisations on the IDM while designing your registration pages.

Don’t copy a registration flow from another site. The registration flow looks like something you can look up a similar product and copy. This is dangerous because as you evolve the direction you take could be different. Enhancing the copied flow becomes a serious challenge.

To summarise, here is the scoop:

1. Do not ask the user to register/log in unless you need it.
2. Map out your user’s journeys so that you know when to bring up registration/log in page.
3. Always present the user a context & a compelling reason to login/register.
4. Use alternatives (like OTP/Tokens/Social logins) to make the experience easy.
5. Ensure you have a privacy policy in place.

People compromise the registration flow because it is a one time thing for users. We all know how important a good first impression is. So think it through and revisit it over the course of your product development.

Edit: read this post which talks about a few other aspects in the registration flow.