How to design a Self Service Betting Terminal

Looks simple in person, design documentation states otherwise

Gambling industry had a problem. It was stale, unwilling to update its ways to cater for what fin-tech and social media has to offer. Those who took a chance and dove deeper into current trends won big. This is one of the reason for recent boom in online and retail solutions that enable continuous journey, from your mobile phone or laptop to your local betting shop or casino.

I was tasked with creation of SSBT, one of most popular retail solutions gambling industry has to offer.

Discovery

What do you do when embarking on a new project? You check what mistakes were made by your direct competitors and try not to make them yourself. Quick exploration of your usual sources of UX goodness didn't produce much more than what I pencilled in during initial meeting. The market was filled with devices that emulate the online experience. Usual modus operandi was to strip down the website and wrap it in an executable file (Windows or Android app). Our approach needed to be different. We wanted to write an app from scratch. Platform and device was chosen fairly quickly — Windows (7+), handheld tablet with at least hd resolution and specs that were able to respond to quick actions on constantly fluctuating UI.

After a visit to the betting shop I noticed a couple of things we needed to brush up on. We had to go a bit deeper into functionality and features we want to support. What I usually do is write up a general problem/feature list with short descriptions to clear any confusion:

Legal requirements

• what is mandatory for a successful bet
• whats mandatory for on-boarding
• what do we need to display to fulfil legal requirements
• what are the differences between markets the product is going to be deployed in (international laws, customs)

Initial device login

• what the device does when logging in after power-up
• what welcome messages we need to display
• error messages if anything goes wrong
• what is the maintenance mode when the network has issues providing a stabile data feed
• panic buttons, do we support hard shutdown / operation freeze at any point

On-boarding

• what user needs to do to successfully login (in steps)
• how users without credentials can on-board
• what are the ways to get verified
• registration process

User area

• what data is available for the user in user area
• how do we differentiate the experience between authenticated and unauthenticated user
• mandatory notifications, blockades, restrictions as per gambling regulators requirements
• error messages and status notifications
• how user can customise the experience to his liking — odds type, preconfigured stakes, favourites, settings made via website
• Call to action buttons — top-up / payout / promotions

Payments

• vetting process
• prepaid cards/ loyalty cards — how to get one, how to operate it
• pay-in / pay-out options
• online accounts — what is the tie-in if any

Betslip

• what are the mandatory fields
• what are the usual error messages we support
• dynamic bet status — how do we handle changes to bets and stakes
• multiples — tab or single column, how we handle Tricast/ Forecast
• Betslip details — do we display a separate page with custom layout and extensive information about contents of the betslip
• call to action buttons — clear betslip / place bets / accept changes/ decline
• compliance issues with Gambling Commission Remote Technical Standards requirements

Landing screen

• whats mandatory
• what needs to be hard coded and whats dynamic (controlled via CMS or jSON config file )
• idle state options — do we dim the screen when not in use, do we run ads, videos or animations when not in use for more than 5 minutes
• live video or audio feeds, how do we load and handle files

Sportsbook

• full list of supported sports
• e-sports or similar categories?
• error messages — suspended/ problems loading feed, problems with odds, any other messages

Top level menu

• authentication — NFC loyalty card / log in form / barcode scan?
• search — what do we search for, what do we display in results
• user area — do we display anything else other than username/ balance?
• top-up buttons

I know answers to most of those questions in an online context, but live and in-person betting store experience is a different kettle of fish. Base product is flexible enough to cater for a Windows based app without any issues, security and payment related processes can be transferred quite closely from already existing solution.

Playing with Lego can come in handy when putting back together complex systems

Bits and pieces

With complex products there is high chance of adding extra layer of convoluted functionality — your run-of-the-mill feature creep. Quick solutions to, at first glance, shorten the path from one screen to another or add something proficient users would seemingly benefit from. Stopping this was one of the first rules I have set.

To make clear what we are building I needed to drill down to the basics of each part of SSBT and remove any unnecessary function or feature, do quick wireframes of whats left and diagram its functionality. Basing the product on tried and tested custom CMS, data feeds already used in online solutions and know-how I gathered over last couple of years allowed me to plan the structure similarly to what we already have been using in white label websites done for our clients.

This approach lets you put everything back together like a set of building blocks. Suddenly things fit together almost perfectly, areas where there will need to be a bit of extra development become obvious, you can plan for upcoming features without worrying that whatever comes next changes the usability more than allowed.

As usual, concepts about general navigation changed, business development was keen on areas that would cater more towards experienced users, there was a push to shorten the coding time and get the SSBT into market as soon as possible. Having a bit of documentation allowed for movement in terms of what goes into version 1 of the product and what needs to be approached properly in version 2

SSBT started to look like a complete product, roadmap got clearer, it was easier to focus on details around usage and maintenance.

Clean and crisp UI template, exactly what the client ordered.

Considerations and use cases

Every product starts with a couple of preconceptions and assumptions. In ideal world you need to test those as soon as possible. What to do when you are tasked with creation of something thats original enough and has not been attempted in the way you want to do it? Do similar products have enough traction to enable you to confirm your that your approach will cover usability and functionality you were tasked with? This required a couple of trips to local betting shops and attendance at leading industry events. At your local bookies it was easy to get the feel of surroundings that your product would need to work in, gambling conferences allowed for a spot of checking up on how your direct competitors handled the same issues you were presented with. Along with user testing along the way this should paint a good picture if finished product has the ability to please the end user and tick all the boxes betting shop operators require.

Considerations

As this was to be a white-label product there were more than your usual set of requirements for similar solution:

1. Main market would cover betting shops in UK and Ireland, with the possibility of deployment in casinos in Asia
2. As a white-label product there would need to be a quick way to rebrand the UI and adapt it to customers look and feel
3. Betting shops would cover most of the usage, there needs to be considerations for easy on-boarding, personal data security and data protection. Casino usage needs to focus on quick turnaround.
4. As a CMS driven product UI needs to be dynamic, easy to customise and update to fit within changing environment
5. When possible the product needs to cater for both experienced and novice users, this applies both to the interface and ease of use.

Use cases

Main driver behind the need for white-label SSBT solution were the betting shop operators. With the popularity of similar devices going through the roof and recent changes to regulations governing some of them there were a gap in the market a device that allows betting on sports events would fit in perfectly. You can’t get more clear use case than this.

Betting shop

1. User: 30+, computer and mobile phone literate but using betting shops for both ease of access and social interactions.
2. Location: device is usually placed close to similar devices, surrounding light is subdued, visual and audio distractions close by.
3. Usability: terminal needs to handle all usual sports with focus on max 4 as per betting shop operator speciality
4. UX: Left hand should handle main navigation and secondary buttons, right hand needs to handle main calls to action and “Bet now” button. Two types of interactions — high frequency, low stake and longer term, medium stake — are the majority of uses for average user.
5. UI: Interface needs to be clean to the point of basic. When possible all labels should be self-explanatory, CMS controlled areas should include enough space for translated text with small buffer for readability. As the surroundings can be darker than ideal and amount of distractions can impede focus the contrast between content and the interface needs to be at least 75%, fonts should be readable from further away than standard position.

Regulatory changes and recent popularity of SSBTs opened up yet another avenue for this type of betting — casinos. Along with EPOS solutions clients more often enquire about adding this type of product to their offering.

Casino

1. User: 30+, not focused on sports betting,
2. Location: clearly marked, properly illuminated area
3. Usability: depending on jurisdiction number of available sports might be regulated.
4. UX: High probability of NFC enabled loyalty cards as a form of authentication.