Casumo Casino an online casino with a distinctively modern instant-play interface, mobile compatibility, and unique "adventure" promotional system. The site is remarkable for its ease of use and a wide selection of games from leading providers.
This project was designed for the UK market and aimed to stop people from creating duplicate accounts.
The primary reasons people would create additional accounts include:
- To receive additional welcome offers at the organisation's expense.
- To resume playing after being self excluded.
My role in the project was to tackle product design; my main responsibilities included:
- Discussing with third party suppliers
- Documenting problems and solutions
- Mapping user flows
- Creating wireframes
I kicked this project off by trying to get a better understanding of why people would want to create multiple accounts in the first place. To do this I started by speaking with our ambassadors and fraud experts who were my closest link to the people I was designing for within the organisation. It turned out that the main reasons were that people either wanted to receive multiple welcome offers or in some cases, people wanted to continue playing after being self excluded.
After learning more about the intent of the people I was designing for, I investigated what preventative measures were already in place to help solve the problem. I mapped out my findings in order to be mindful about how my solution would work with the existing system, and also to have documentation to share and discuss with the team.
Here's what I gathered about our registration flow after digging in:
- If people tried to register with a registered email address, they would not be able to proceed.
- If people tried to register with an already registered username, they would also not be able to proceed with with registering.
- If people entered a combination of first name, last name and address which were already registered under a single account, then they would not be able to proceed in registering.
- If people entered a combination of first name, last name, date of birth, post code and mobile number which were already registered under a single account, then they would not be able to proceed in registering.
- With all of these security measures, some people were still slipping through and therefore a mobile verification system was needed.
With all of the preventative measures that were in place, people were still managing to create additional accounts and therefore a mobile verification system was necessary.
Options considered and decisions made
The first big decision to take was wether to include the mobile verification within the registration flow or right after people registered an account successfully.
The main arguments here were that by adding an extra step in our 13 step registration flow, we may affect our visitor to newly registered customer (NRC) conversion. The data had already clearly outlined that each additional step in the flow meant more people dropping off. On the other hand by introducing it after registration, we were risking affecting our newly registered customer (NRC) to newly depositing customer (NDC) conversion as people might sign up but then abandon their account once prompted to verify their number. Moreover this scenario would have also meant more work for us in-house to clear up accounts.
When we asked ourselves once again what we were really trying to solve and which metrics mattered most, it made sense to include the mobile verification as a part of the registration flow to totally avoid duplication of accounts and to focus on increased NDC's over NRC's.
Before designing, we had a meeting with the messaging provider to discuss our options. After people would enter their mobile number in the registration flow the options were the following:
- Send people a token via SMS
- Send people a link via SMS
The downfall of sending a link was that people would have to exit the registration flow entirely and open their messages app to follow the link and that would have made a broken experience.
After the ‘token send out’ stage and in the case of people not receiving their token the options were the following:
- Resend the token via SMS
- Trigger voice call with token
- Trigger voice call with 1 digit code
Before moving forward I must mention that the functionality for registered players to verify their number in exchange for a reward was already in production. However a substantial percentage of these players were experiencing problems in receiving their verification tokens, and a minority of people were not receiving them at all. The meeting with the messaging provider shed some light onto why that was happening.
The channel on which tokens were sent out to our players was highly saturated due to the amount of activity by multiple operators making use of it. Players who wouldn't receive their token and tap to get an additional token resent would only add to the traffic in the channel and therefore increase saturation and were therefore still not likely to receive their token.
To make matters worse, further investigation and discussions with the ambassador team uncovered that a percentage of people were not supplying correct phone numbers as they were adding ‘0’ after the prefix to their number; which we weren’t masking meaning that these players definitely had no way of receiving their tokens even when saturation was at a bare minimum.
In order to begin designing at the very earliest stage were problems were occuring, I decided to redesign the way we displayed mobile numbers to people during the registration flow. The changes that were made were as follows:
- The prefix was disconnected from the mobile number to further clarify that people could change it.
- A (0) in the mobile number field indicated that people did not need to enter one before their number.
- Arranging the mobile number into 3 groups of digits was thought of as a solution to help people spot genuine errors.
Tapping the next button in this step would send a token request to the messaging provider, however we had already established that if people would not receive their token within 15 seconds then there may have been saturation issues. For this reason we decided that if peoples’ wait exceeded 15 seconds, they would be prompted to check if they have supplied the correct mobile number and were also provided with a fallback solution.
The prompt displayed the number people supplied and was also formatted using spaces to make it easier for people to spot errors. If the number looked incorrect then people could change it by tapping on it and if it looked correct then they could request one more token or receive a call to verify their number.
However we had established that if the first and second token would not go through then it would be unlikely that a third would and this may have meant people being unable to register and therefore abandoning registration. Therefore after requesting a new token via SMS, that option would no longer be available and the suggested fall back state was to encourage people to receive a call.
In order to avoid people thinking that they would receive a call from a human being before even opening an account, which may be freaky, the copy was carefully written to inform people that the call would be a pre-recorded message that they had no reason to feel uncomfortable receiving.
Tapping to receive a call would allow us to switch to a different channel which was under utilised and therefore had no saturation issues. This meant that people would receive their call in a few seconds as the saturation issue wouldn't exist.
The type of token we set up was a one number token. People would simply have to tap the random number that the voice over suggested to verify their number.
We opted for this direction because remembering a lengthier code over a phone call may have been demanding for people especially since people would have their handset to their ear and have no visual representation of the token. And this may have created a frustrating experience.
In order to account for people making genuine mistakes by tapping the wrong number, the setup we opted for allowed people another attempt. After tapping the wrong number an audio clip would be played informing people that a mistake may have been made and then a new token would be provided allowing people to try again.
In total six user flows were catered for as specified below.
- User verifies his mobile number successfully
- User enters incorrect verification token
- User requests a second SMS token
- User changes a verified mobile number
- User retypes a verified mobile number
- User verifies mobile number over a voice call
User verifies his mobile number successfully:
User enters incorrect verification token:
User verifies mobile number over a voice call:
How we validated the design
We decided to validate the design on desktop first since the percentage of players on that platform was the 20% minority. This way we could test the solution and avoid effecting the other 80% of mobile players in case the solution was broken. After testing on desktop and ensuring a working solution, the project was rolled out across platforms.
My main learning in this project was that when dealing with sensitive areas of a product, no detail is too tiny to overlook. What appear to be small tweaks in design can make all the difference and help avoid large negative impacts. Discussions around understanding where the risks are and how to minimise them are worth every minute of discussion and a critical part of the design process.