The problems

To successfully activate the account, a pending user was expected to go through the flow like this:

• Step 1. Pending users are to the Sign in page.
• Step 2. Click to enter the Forgot password page and request a new password.
• Step 3. Receive an email with a link to reset the password.
• Step 4. Set the password.
• Step 5. Update the profile information.
• Step 6. Get to Sign in page again.
• Step 7. Sign in to activate account.

It was a long flow, and not an intuitive experience. Things can go really wrong in this flow, such as:

1. Pending users don’t understand the term “activate the account” from the welcome email. From their perspective, they never created an account, thus once they got to the Sign in page, they tend to go to the Sign up page instead, with the expectation to create an account.
2. Users complained that the “Sign up here” button is too hard to find on the Sign in page. Many of them are stuck at the page and don’t know what to do.
3. In the case when pending users manage to land at the Sign up page, they will fill out the form and click on the “Create Account” button. They will then receive an error telling them “user already exists with that email”.
4. Pending users don’t know that they have to use “forget password” to set the password.

As a result, most of the pending users had no clue how to activate their accounts. They jumped back and forth between Sign in and Sign up pages and eventually called the support team for help.

The Key Problems

• Users were confused about why they have to activate the account, but not create one.
• The process of activating the account was long, misleading and counter-intuitive.

Ideas and constraints

Throughout the research period and meetings with product and engineering teams, some ideas have been brought to the table to discuss the feasibilities:

• Update this use case to a traditional invite flow, where users could receive an invitation and create their account.
  

  How was this idea?

  This idea can solve the problems for the upcoming users once the update could be built and launched. However, existing pending users would still have the same problem activating their accounts. A separate solution would be needed for all the existing pending users.

  Based on the early estimation, this idea required many back-end and front-end changes. Along with the extra solution needed for existing pending users, the overall effort could be relatively high.

  As a result, the idea got ruled out after the initial evaluation process.

• Create a custom flow to easily activate the account. Instead of bringing users to either the Sign in or Sign up Page, a new Activate your account page could be designed for pending users.
  

  How was this idea?

  One of the most confusing parts of the process was the term “account activation”. Pending users did not understand why the account needed to be activated when they did not create one in the first place.

  The idea might be able to slightly improve the experience, however, pending users will most likely be having the same confusion, and therefore, leaving key problems unsolved.

  Having a new flow customized to a specific use case required extra resources to build, test and maintain, and the design would lack the possibility to scale to other usages.

  This idea was ruled out because it would not solve the problems.

• Update the sign-up flow, pending users can “sign-up” (activate account) just like the new users.
  

  How was this idea?

  This idea moved the term “activation” to the back-end system to handle. And on the front-end interface, pending users would experience a normal signup process.

  Updating the sign in and sign up flow would possibly affect all users. The design and updates need to be tested for all.

  The idea would have the pending users sign up just like a new user, therefore, no more confusion about account activation. With experience similar to the new users, the flow can be much more efficient as well.

  Based on the early estimation, this idea required limited back-end changes, and focused mainly on front-end updates, the effort was relatively low. As a result, we decided to move on with this idea.

Updating the flow

Previously, we had one Sign up page and one Sign in page:

The solution needed to focus on users’ expectations, which was to consider them as the new users. Following this direction, I wonder if pending users can be directed to the Sign up page. Then, just like every new user, they can fill in the information, create the password, and click the “Create Account” button. The system at the backend would validate the email against the pending user base. If the user was successfully identified as a pending user, we would let them finish the account creation process, which, in the backend, would be finishing the account activation process.

However, a security concern was brought up when I presented this solution. The partner’s email used to create the pending account comes from the SaaS companies. There is a risk of someone creating a personal account using this email. Therefore, for security reasons, emails of the pending users needed to be verified before collecting and saving more profile info to mitigate this risk of human error or intentional malice.

To solve this, I added a welcome page containing only an “email” field. This page was designed to be the first landing page prior to the rest of the sign in or sign up flow. We later called this page - the Handshake page:

From the Handshake page, the system then directed the users of all types to the next step. Existing users would be directed to the Sign in page, new users to the Sign up page. Pending users, once identified, were directed to a page to confirm their email address. Once confirmed, a link in the email would bring the user back to complete the rest of the signing up process(account activation).

With this updated flow, the “activation process” for pending users got reduced to three steps. The system handled the validation and activation in the back end. On the front-end level, the Handshake page acted as a navigation page to direct users, including pending users, to first confirm their email and then complete a sign up process.

Iterating for a better experience

EMAIL VERIFICATION

Most of our users have busy schedules throughout the day. They worked in multi-task and fast-paced environments. Putting them into this context, users tend to get interrupted in the step of email verification, where they have to temporarily leave the current process to open their mailbox. Many users tend to “take a break” from this process, and that leads to:

• not returning to complete the signup.
• coming back before the verification link expires, and successfully sign up.
• coming back after the verification link expires, and having to go through the entire process again.

I added a button on the Email verification page to link to their email provider. This helped to prevent more than half of our users from leaving this flow.

LINKS IN-BETWEEN SIGN-IN & SIGN UP

With the new Handshake page, the system could check the email entered and direct the user to the corresponding next step. Therefore, for the first release, I did not include a link to be able to navigate between the Sign in and Sign up pages. However, real-life scenarios were usually much more complicated. Users could easily end up on the wrong page when they have more than one email address and used the incorrect one to sign in. In a scenario like this, having a link to navigate in-between provided a more flexible experience for many users.

ERRORS AND EDGE CASES

I went ahead and added the error messages for edge cases that we did not have before. This further helped to smooth the experience when something goes wrong during the signup process. When there is no guidance on what to do during errors, users can get stuck easily. Hence I included links in the messages to direct the users based on their scenarios.

The results

• Pending users have a much more smooth experience becoming a user of Partner platform. They come to the application expecting to create an account, and we allow them to achieve that efficiently without the confusions.
• Pending users could activate their account within three steps, significantly shortening the time they used to spend on this process.
• Our support team saved 3 to 7 hours per week and could focus their efforts on other important tasks. Previous to the release, there were around 20 - 40 supporting tickets per week related to the pending user flow. Tickets related to pending users were down to almost 0 after the update.

My takeaways

• In this project, I gain valuable data from our customer support team. In this particular project, the pending users knew very little about the process as they were new to the product and did not know what to expect. The support team handled most of the tickets related to this issue and helped many users to activate the accounts every day. They were the most knowledgeable group who can provide comprehensive information about the experience and problems about pending users.
• Context plays an important role in users’ behaviour and actions. The real-life scenarios are usually much more complicated due to the difference in context. I was lucky to be able to design and iterate based on real-life use cases.