Registration Decline

Problem

Ria was starting to see a decline in the number of registrations to the site. We wanted to increase the number of people registering by simplifying the experience and reducing the cognitive load on the user.

We initially A/B tested two column versus one column layout, just to see if we could see a lift in registrations on the larger screen displays. We did initially see an increase, but we knew there was still more work to be done across all screen sizes.

User Testing

I ran a couple dozen users through a session where I asked the participants to register for the Ria website (user testing environment, not production), using dummy test data to validate that there was improvements to be made to the registration flow. Using a screener question, I split the users 50/50 between those that had used a money transfer service before and those who had not. I initially had issues with user testing members not understanding the difference between remittance based money transfer services (Ria, Western Union, Moneygram) and peer to peer money transfer services (Venmo, Square Cash, PayPal). I was able to get a pool of users that had used the traditional services using a screener question where I allowed the user to pick from a list of both peer to peer services and traditional remittance based services like Ria.

Takeaways

• Users on larger displays were overwhelmed with the amount of fields to register for Ria (2 column layout and single column layout)

• Surprisingly, a majority of the users expected to enter their payment details (bank or credit card)

• Some users had issues with truncated security questions on iOS devices

• Some users incorrectly formatted their birthdates

• Majority of users were used to having their address autocomplete using 3rd party mapping API (Ria does not have this)

Next Steps

Due to API limitations, I did not dive into idea of using a light registration and collecting the relevant and required data later after registration, instead of all up front. I needed a way to ease the pain of having 24 fields displayed at once (regardless of device screen size), and increase the efficiency of the form wherever possible.

For the next round of testing, I opted to use a HTML/CSS prototype. Some of the tweaks I had in mind would not work on quick click-through static prototype. A lot of the issues we found with the registration flow could only be accurately tested using the real deal.

Tweaks and Changes

• Split the form into more than one page to reduce cognitive load

  • We opted to group like information together and place them into three categories

    • Step 1 - Account Credentials (username/password)

    • Step 2 - Security (security questions and answers)

    • Step 3 - Personal Information (name, address, phone, date of birth, communication preference, language preference)

• Use of an address autocomplete service to speed up address entry

• Splitting up date of birth field into three separate inputs (month - dropdown, day - dropdown, year - text input)

• Decreased number of security question/answer pairs from three to two

User Testing (again...)

High Fidelity Wireframes