🗓 Completed in Q4 2019

Contents

🏢 Company overview

👥 Team & responsibilities

🤔 Problems to be solved

📋 Scope

🔬 User testing and learnings

📚 Final learnings

🏢 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 2019, Casumo's strategy for bringing sustainable growth revolved in part around entering new, regulated markets.

The idea behind the strategy was to reduce over dependance on unregulated markets which had the capacity to be volatile, and negatively impact the business.

Each regulated market in the company's portfolio imposed unique requirements to be catered for - Spain was to be the fourth locally regulated market with yet a new flavour of requirements to be met.

My involvement in helping fulfil the strategy was around designing a scalable solution for handling customer deposit limit setting across regulated markets. The same initiative would also facilitate Casumo's launch in Spain.

👥 Team and responsibilities

The team I worked with consisted of

• Producer
• 3 back-end developers
• 2 front-end developers
• Product designer (myself 🙂)
• Spanish, legal consultant
• Data scientist available where necessary

My responsibilities were to

• Stakeholder interviews and research
• Liaising with legal consultant
• System design
• User flows and interface design
• Writing content
• Prototyping
• User testing
• Proposing metrics to track

🤔 Problems to be solved

Scaling deposit limit setting across regulated markets

At the time, Casumo was maintaining many flavours of deposit limit setting across regulated markets. Although all flavours worked with similar variables, their configurations were varied enough to bring additional work and keep the product team unnecessarily busy.

Casumo's system around customer deposit limit setting wasn't flexible enough to minimise product maintenance and facilitate launches new market launches.

Launching a compliant product in Spain

The Spanish market posed many requirements, one of which was to enforce daily, weekly and monthly deposit limits to all customers with amounts stipulated by the regulators. These limits would apply automatically after customers registered their account and could be adjusted only with a number of caveats.

This flavour of limit setting was unprecedented at the time and wasn't catered for.

📋 Scope

A modular solution for scaling deposit limit setting across markets

The vision of a modular solution around deposit limit setting was set in an effort to address the scaling problems.

By going modular, Casumo could receive requirements from regulators and configure customer experiences with minimal effort.

A deposit limit user experience for Spain

From an architectural perspective, the experience for Spanish customers would be borrowed from the modular system.

With that being said, the design solution for Spain had to cater for some nuances that were market specific. Designing the communication around limits and adjustments made by customers was also to be accounted for.

✍️ Design process

Untangling the modularity problem

My first exercise was around identifying market commonalities and differences by placing all findings in a single sheet.

I figured that in order to become flexible, it made sense to decouple all variables from their market configurations, then think of all the possible permutations that regulators may impose moving forward.

The variables in play were:

1. Any combination of a daily, weekly and or monthly deposit limit.
2. Any combination of imposed deposit amounts or amounts that users may set.
3. Limits may be required during registration, right after registration, or open for users to set any time if they chose to have them.

Apart from the variables, I also had to consider the actions customers could take to manage their deposit limits which were:

1. Any combination of lowering, increasing and or removing their limits.
2. Cancelling adjustments made.

Designing the modular base system

Designing for one mandatory limit

This experience was designed to begin with a prompt which would inform customers to set their limit. Although depicted as a button in the flow below, the prompt was designed to fit into any part of a journey including becoming a part of a dedicated page informing customers about their limits.

Upon getting started, customers would be given the option to add a daily, weekly and or monthly limit, and set their respective amounts. After doing so, customers would be presented with a review of their limits and given the chance to make final adjustments before saving them.

Designing for multiple mandatory limits

Just like the previous solution, this one was also designed to begin with a prompt. The main difference here is that a stepped approach to setting limits was taken.

The main reason for taking this approach was that since each limit (daily, weekly, monthly) had to be equal to or larger than the previous one in terms of value, this allowed for suggesting amounts as customers worked their way through the steps. Suggested amounts would be based on what customers entered in the previous step, and would reduce the likelihood of customers entering amounts that would return errors.

Designing for imposed, and automatically set limits

Unlike the previous experiences, in this scenario customers would register their account and have limits imposed automatically. There was no need for a prompt to set limits, instead customers would be informed that they had imposed limits which were available for reviewing and adjusting in their account.

Tapping on any of the imposed limits found in the customer's account lead into a view similar to the ones seen previously were adjustments could be made.

Designing for non-mandatory limit setting

In this scenario, having deposit limits wouldn't be mandatory, therefore rather than being prompted, customers would be free to navigate to their account and set limits if and when they chose to.

Upon beginning, they'd be able to set any combination of limits in much the same way as the first experience discussed.

Providing visibility over set limits and their states

Once customers had set limits, they'd need visibility over them. In order to determine how to communicate limits together with their states, I thought about all the useful information customers would need visibility over and drafted the following list:

1. Visibility over the types of limits set.
2. Visibility over the amounts set.
3. Visibility over how much may be deposited at any given time.
4. Visibility over any pending adjustments made to limits.
5. Customers would also require the option to set additional limits were possible.
6. Customers would also require the option to adjust limits.

Bearing these requirements in mind, I figured a simple structure to communicate all of the components above in a clean and scalable way as depicted below:

Above: Stateful, list items communicating deposit limit statuses and options.

Designing for adjusting limits

Customers would be able to head over to their account to review their limits, then tap on them to enter a view were adjustments could be made. One key difference in this flow is the addition of a component to inform customers of any timeframes or caveats in connection with their adjustments right before saving them.

This was due to the fact that lowed limits would apply instantly as they'd offer added protection, however increased or revoked limits would become effective after a safety period stipulated by the regulators.

View the full modular base system design in Figma

Designing for the Spanish launch

The Spanish experience borrowed the 'three imposed limits' solution from the modular base. With that being said, there were a number of additional requirements which were unique to Spain. These requirements included:

1. Requiring customers to take a ten question test upon attempting a first limit increase. Customers who'd fail the test wouldn't be allowed to make their increase.
2. A manual background check for customers attempting a second increase. Customers who engaged in unhealthy behaviours would be prevented from making their increase.
3. Revealing a history log to customers informing them of all previous adjustments they'd made.

View the full Spanish system in Figma below:

Polishing up the UI

Nobody enjoys having limitations imposed upon them - even when they're for the better. I thought that this 'dip' could be an opportunity to generate trust by communicating that the limits were set in advance for the people's safety.

To achieve this, a 'splash' screen was designed for customers to view before accessing their limits. Here's how the Spanish experience turned out on mobile:

Handling responsiveness

The modular system catered for responsiveness too. All pre 2019 platform discrepancies were addressed, allowing customers to begin on one device and continue on another with no learning curve required.

The main platform differences were:

1. The way Casumo handled its global and local navigation.
2. The way space was utilised on larger viewports.

Of course interactions such as inputting data are a different ball game on desktop versus touch screen devices. With that being said, I remained mindful about ensuring that these systems differences wouldn't throw the customer off guard.

In the end, the experience around inserting limits was deliberately kept consistent across devices as depicted below.

Here's how the Spanish experience turned out on desktop:

View the full Spanish deposit limits UIs in Figma

🔬 User testing and learnings

User testing - the approach

No piece of user centered design is complete without user input, in fact, user testing took place a lot earlier than it might appear in this study. Before preparing any test scripts, I took a step back to establish my research questions and consolidated them into themes.

The research themes revolved around:

1. User comprehension of navigating limits.
2. User comprehension of adjusting limits.
3. User comprehension of rules for lowered limits together with increased or revoked limits.

After the exercise I fired pilot tests followed by the full tests for each research theme.

User testing - the findings

As always, user tests reveal a number of interesting findings, here are a modest couple that I found particularly interesting:

X2 Users tried to remove limits by trying to save a '0'

As unexpected as that may have been, clearly the UI hadn't done a great job at communicating that all three limits were required. The end solution catered for error handling in events were users tried to hack the system.

X3 Users tapped the 'X' icon in the summary screen to try remove limits

The summary screen featured icons next to each limit indicating the type of adjustment made. An upward arrow suggested an increase, a downward arrow suggested a decrease whilst an 'X' suggested a limit had been revoked.

The 'X' representation proved to be confusing to users who thought they hadn't successfully revoked their limit and tapped the 'X' icon in an attempt to remove it again. The end solution featured a more appropriate icon to represent a revoked limit.

View the full user test synthesis in Google Sheets

📚 Final learnings

I'd normally conclude by discussing implemented data tracking and resulting learnings.

Given the non-negotiable regulatory requirements, the team felt it wouldn't be able to action most behavioural insights, for this reason no 'project-specific, behavioural tracking was set. Instead, the team monitored the market as a whole and compared its performance to that of similar markets.

There were some domain-specific learnings I gathered that I'd like to close with though.

Regulators base their requirements on their 'neighbours'' requirements

For the most part, locally regulated markets base their regulatory requirements on other markets they have some connection with. As an example, the requirements for Latin America were similar to those of Spain.

This meant that setting up some markets made entering similar ones easier.

Circling back to Casumo's strategy, taking a modular approach to limit setting helped us enter new markets with less effort, which then made entering similar markets even easier than that.

We'd continue to see new configurations for deposit limits but were unlikely to see new variables

We learnt that the configuration flavours would continue to surprise us, but the limitations around variables appeared to have been met. Decoupling variables from configurations early proved to pay off as no market took us off our guard after the project was completed.

💬 Let's get in touch