Sky Bet is a household name in sports betting and gaming. Working in this industry means ensuring total security for customers and the business. In this project, we designed and tested a potentially disruptive but necessary addition to our onboarding journey.
The Problem
As a business, Sky Bet are always aiming to keep ahead of regulatory requirements by addressing them proactively, before they become law. Stakeholders identified a need for customers to verify their email address for several reasons:
➡️ To prevent ‘bonus scammers’ who sign up with an invalid email to claim multiple new customer bonuses
➡️ To address an upcoming payments regulation for customers to have a valid email address in order to process a payment
➡️ To ensure customers receive bonus offers and account information by when email has been entered inaccurately
Testing
Because our intention for the email verification was to make it compulsory for all new customers as part of the onboarding journey, we had to ensure that the experience was as seamless as possible, to reduce friction and customer churn. We were also looking for feedback on the journey as a whole, as previous testing had highlighted usability challenges and we wanted to see if these or any others came up again.
To do this, I produced two prototypes of our onboarding journey in UXPin:
1️⃣ One where the user would enter a code sent to their email to verify
2️⃣ One where the user would click a link sent to their email to verify
Myself and the Senior Product Designer then put together a test plan based on the following hypotheses:
1️⃣ Presenting the benefits of verifying their email address will increase acceptance of the process.
2️⃣ Using a code means customers will find it easier to verify their email, as it provides a clear link back to the journey.
Discussion guide for interviews
Interviews
Utilising the User Testing platform and Zoom, we scheduled interviews with existing gamblers (but not active SBG customers) who had use of a smartphone for 1 hour at a time. Myself and the Senior Designer took it in turns to moderate and take notes. Using the discussion guide above, we interviewed 8 participants in total.
Interview notes
Key findings
Thanks to 8 hours of rich content, there was a huge amount of qualitative data to analyse. We went through all the notes as a pair initially, with the interviews fresh in our minds, to note down all the common themes.
Both of our hypotheses were disproved.
Findings related to Email Verification:
1️⃣ No one read the perks of email at first inputting it.
2️⃣ Preference of link over code to verify your email.
3️⃣ If they drop out without having verified, people expect a prompt once logged in to the account reminding them to verify their account and an option to resend email.
4️⃣ Nobody was surprised they had to verify their email- everyone expected this would be the case for either their phone number or email based on past experience 5️⃣ Lack of clarity that email address had been verified, focus was on CTA to add a payment method
There were also many insights into areas of the onboarding journey which users found confusing, and a general feeling that there was friction in the wrong places. Many of these had been raised in previous interviews, and these were marked as such in my final report.
Quotes from user interviews
Report
Compiled to share out with stakeholders within the Onboarding squad, the report comprised of detailed but digestible analysis on each section of the email verification journey, as well as two additional sections containing insights for the onboarding journey as a whole, and marketing preferences which was another area we were testing in this flow.
Excerpts from the report deck
Project outcomes
As a result of the user interviews, there were some obvious alterations to the flow, and some that required more thought and further testing. Due to the project timelines, it was decided these should be split into an MVP and future iteration, with the MVP providing less friction and presenting a lower risk of customer churn. The MVP could then be used to gather data to inform the future iteration, measuring data points such as errors when verifying, amount of emails verified, and how long it took people to verify.
The intention for the future iteration was to provide deliberate friction, to ensure that all users verify their email address before they are able to proceed to add a payment method or use the product. Our discoveries ensured that, when the future iteration is implemented, it will provide the right amount of friction without negatively impacting the amount of new customers signing up for an account.