🗓 Completed in Q1 2021
Contents
📋 Scope
🏢 Company overview
Casumo is an award winning, online casino reaching 60,000 plus active customers per month globally. What makes it different is its relentless focus on safe customer engagement.
In late 2020, I was tasked to improve the customer payment experience (AKA 'wallet') to address a host of issues of various impacts to customers and the business. The wallet is crucial to Casumo's success, simply put, it's the bridge which enables players to play and the company to generate its revenues.
👥 Team and responsibilities
The team I worked with consisted of
- Payments expert / project manager
- 1 back-end developer
- 2 front-end developers
- Product designer (myself 🙂)
- Legal and compliance stakeholders were necessary
My responsibilities were to
- Interviewing stakeholders
- Auditing the previous payment experience across platforms
- Designing user flows and interfaces
- Prototyping
- Writing content
- User testing
- Proposing data metrics
🤔 Problems to be solved
Understanding the problems first
There were two main inputs leading to concerns about the the wallet's performance:
- Our data revealed a concerning percentage of customers dropping off at various, and unrelated stages throughout their deposit experience.
- The payments team (wallet owners) were frustrated about broken features throughout the wallet that may have been impacting its performance.
My first step was to begin with an audit of the wallet. The intended outcome was to have a map of the full experience that would help the team in locating problematic areas which needed addressing.
Auditing the wallet - the approach
Above: A small piece of the wallet audit in Figma.
I carried out the audit by going through each user flow that was live, taking screen shots of each step along the way and placing them in sequence. Next, I filled out stickies under screens which presented usability issues.
The audit helped us spot broken flows and usability issues. It also helped us discover new opportunities.
Above: Documenting pain points throughout the wallet in Figma.
Once all findings had been documented and discussed, it was time to prioritise the ones that would have most reach and impact on users. These issues were marked as critical whilst the remainder were left to be considered as future improvements.
Auditing the wallet - the findings
The lowest and highest accepted deposit amounts were not communicated
As a result users would input invalid amounts and experience unnecessary errors which delayed or their deposits.
Users had no visibility over deposit limits they'd set
As a result they'd attempt deposits which would fail. Unfortunately they weren't informed of the reason or the fix.
The value in using deposit bonuses wasn't clearly explained to users
With casinos, users could use bonuses to deposit X and receive X + Y%. The amount of money a bonus would add to a user's deposit wasn't communicated. Nor was it clear that users may drop or change bonuses. As a result users may have been less inclined to making larger deposits.
The credit card setup flow was unnecessarily long
Our data suggested customers dropped off at each step.
People weren't properly informed about their expired credit cards
As a result, they'd attempt making deposits only to find that they couldn't make one right away.
Several input errors weren't accounted for
This put the burden on customers to figure out what went wrong when things snapped.
The desktop experience was a legacy one
After deciding to go fully responsive some months earlier, the mobile product became the flagship experience for Casumo to converge towards. As a result, mobile received all the love whilst desktop was left redundant.
A significant percentage of players used multiple payment methods, including some of the same type
People couldn't easily manage and choose their methods which resulted in people using expired methods at times.
📋 Scope
Since problems spanned across multiple tracks, the team decided to address the wallet holistically. This way, each chunk that shipped would plug into a consistent whole.
The solution had to cater for all markets and their different needs, whilst keeping product dept to a minimum.
✍️ Low fidelity iterations
The first iterations merely accounted for the main deposit flows. This approach enabled me to begin from the core and cover lots of ground quickly.
Each time I completed an iteration, I'd write comments under screens which needed further exploration or discussion. These notes helped bring team alignment, especially around blind spots, and allowed us to pivot and save time.
Above: A portion of the first low fidelity iteration.
One example of a pivot point was when I tried to design a credit card scanning feature to help users hook cards up effortlessly as depicted below.
Upon discussing the idea with developers, we felt that implementing the feature well across platforms would pose challenges and decided to shelve the idea.
Another example of a pivot point was when I tried to create a clean looking deposit screen by placing pre-suggested deposit amounts at the bottom of the screen, and placing payment methods close to the deposit amount as depicted below.
The issue with the amounts was that they'd be covered by the keypad in many use cases. This was a no-no for the payments team who's data suggested that a large percentage of people were using them, and rounding up their deposit amounts in doing so.
The issue with the payment method pattern was that some methods such as e-wallets featured an email address as an identifier, forcing the pattern to crash into the deposit amount to the left. Moreover, communicating expired credit cards using this pattern proved to be nightmare.
Each new iteration was about expanding out of the core flows and designing in greater depth, whilst addressing critique from previous iterations till there were less red flags.
Above: A portion of the second low fidelity iteration of the wallet.
🔬User testing and learnings
User testing - the approach
After several low fidelity iterations, the team's confidence was ripe. However at this point customer input around our ideas was still missing.
I took a step back to establish which flows were used by most users more often, and which were used by less users seldomly.That way I was able to narrow down to the least amount of testing that would uncover the most critical blind spots.
What was clear was that more users deposited than withdrew. Moreover the deposit flows carried more business value and posed more user pain points.
In view of the priorities, I narrowed my research questions to the following:
- Do newly registered customers know how to hook up a credit card and deposit?
- Do users know how to change a bonus as they deposit?
- Do users know how to change a payment method as they deposit?
- Do users know how to reach the withdrawal page from outside the wallet?
- Do users know how to find their full transaction history from outside the wallet?
Prototypes were built to answer my questions, then a pilot test was fired, followed by a full test.
User testing - the findings
Above: Snapshot of the user testing synthesis.
Overall the test went well, however the amount of effort required from users in some areas was concerning.
I learnt that users couldn't figure out how to make a withdrawal without getting there by trial and error. There were two reasons for this:
- A lack of clarity in the labels used for the product's global navigation detailed in the image below-left.
- A persistent balance bar throughout the product which promoted depositing but hid withdrawing as detailed in the image below-right.
Another learning was that one of my 'new' ideas was actually a terrible one. My idea was to provide a summary of all transaction-related activities and options in a single place as detailed below.
Throughout the tests the dashboard felt awkward to users. In their mind they either wanted to deposit or withdraw and the dashboard came across as an extra step that offered no value. After the test, I took the dashboard down and refactored the wallet's architecture.
📱 Final designs
The end solution addressed the prioritised issues that surfaced from the inputs outlined in this study.
The final design leverages five main views which were designed to be highly stateful. Hence their reusability across varied contexts and their ability to help minimise product dept.
Two of these views were 1. the 'deposit amount view' and 2. the 'the new payment method view' as detailed below:
1) Deposit amount view
This view could adapt to help users in the following contexts of use, and more, whilst remaining familiar:
- Jump-starting a first deposit.
- Helping users add, change or remove deposit bonuses confidently.
- Helping users make repeat deposits quicker.
- Helping users with limits manage deposits quickly and easily.
- Helping users with expired or no longer supported methods, check out quicker.
Above: Deposit amount view in four different contexts.
2) New payment method view
This view could adapt to help users in the following contexts of use, and more, whilst remaining familiar:
- Helping users add any kind of payment method including credit cards, e-wallets and bank accounts.
- Allowing users to insert bank details specific to their markets (such as Canada) without design overhead for Casumo.
- Helping users search for bank details which would only be accepted in specific formats (such as in India).
Above: Payment method view in three different contexts.
A before and after comparison
Previous problem
The lowest and highest accepted deposit amounts were not communicated to users as depicted below.
Solution
Depending on the payment method in use, the deposit amount bracket was presented in the deposit field empty state. If users changed their method, the depicted bracket would change too.
Previous problem
Users had no visibility over deposit limits they'd set as depicted below.
Solution
This problem was addressed in three parts:
- Firstly by communicating what a user could deposit, in deposit field empty states.
- Secondly, by retaining visibility of set limits underneath the deposit input field as users type.
- Lastly, by providing contextual, pre-suggested deposit amounts.
Previous problem
The value in using deposit bonuses wasn't clearly explained to users as depicted below.
Solution
A contextual widget was designed to communicate:
- Whether or not bonuses were available to be used.
- Whether or not a bonus was actually being used.
- The money a selected bonus would add to the total deposit, based on what the user typed in as a deposit amount.
- How to change or remove a bonus.
Previous problem
The credit card setup flow was unnecessarily long as depicted in the flow below.
Solution
The card details were consolidated into one view. To collect details faster, the card holder name would be filled automatically after users entered their CVV.
Previous problem
People weren't properly informed about their expired credit cards as depicted below.
Solution
Users would be reached by email before having to discover the issue upon depositing.
Within the product, the CVV field was swapped with a callout helping users update their card or change their method altogether. Users with a second method available would be offered the option to use that instead.
Previous problem
Several input errors weren't accounted for as depicted below.
Solution
This was addressed in part by avoiding the likelihood of errors taking place - deposit brackets and limits were displayed upfront to help achieve this. Moreover all errors known to the team, including those that may occur by deliberate misuse, would be communicated when triggered.
Previous problem
The desktop experience was a legacy one as depicted below.
Solution
A single, scalable solution was designed. The only nuances between platforms were related to the different ways users would insert data using them.
Previous problem
A significant percentage of players used multiple payment methods, including some of the same type as indicated below.
Solution
Methods of the same type were bundled into groups which helped reduce information overload. In addition, users were given the option to hide methods which were no longer relevant to them.
📏 Measuring the outcome
Gauging the wallet's health across markets afforded some simplicity without compromising insights.
Of course improved designs wouldn't increase deposit amounts or decrease withdrawals. These behaviours were more likely to be influenced by customer motivation and Customer Relation Management.
Improvements could however ensure increased customers success around deposits and withdrawals. On this premise I drafted three KPIs:
- Improve transaction completion rates.
- Improve transaction completion times.
- Reduce transaction related, customer contacts.
For each KPI, I selected main metrics to outline the wallet's performance. Lastly, for each main metric, supporting metrics were chosen. These were behavioural metrics which could help locate user behaviours that lead to the resulting main metrics.
Watch me run through the KPIs and metrics on Loom below (feel free to speed it up).