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.
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.
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)
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...)
• Users liked the ability to use autocomplete on their address
• The time to input date of birth decreased
• Mistakes made when entering date of birth decreased
• Some of the users wondered why you had to provide security question and answers instead of 2 factor authentication
• When implemented, the focus should switch to Apartment/Unit # Field once an address suggestion has been selected
• Decrease amount of content for password requirments
• New security questions to reduce truncation
• Users liked the progress indicator
High Fidelity Wireframes
The new design has not yet been implemented into production, the product team wanted to kill two birds with one stone and introduce the new registration flow with the redesign that is currently wrapping up.