Bets.io

Building a Betting Platform that merges the power of Cryptocurrency with the excitement of Esports.

Foreword


Sportsbet.io is one of the worlds leading iGaming platforms that operates with the crypto-currency markets to provide fun, and innovative forms of entertainment and gaming experiences.


The mission for our small division, was to deliver a functioning MVP that would be used to onboard an existing Sportsbet customer who had a desire to bet on Esports. Meanwhile continuing to develop the product as child brand, dedicated to being a legitimate Betting hub for Esports.


We faced immense challenges both technologically and ethically, in a time where gambling in Esports was a relatively new concept, and the existing options had been closely linked with encouraging underage gambling and lucrative money schemes.


Upon joining the team, we already a partially built, functioning MVP developed using a lean UX discipline. Which was great, we had a working chassis. Or at least, this is what I believed in the beginning. But it was early days, and the original concept raised 2 Major concerns with the team, which I will come to later.



Prototyping components For Concept 'A'

Before we could start thinking about a concept 'B', we still needed to finish prototyping 2 of the basic functions for concept 'A', the betslip and how it behaved, and the other was the account management system, which would effectively allow users to deposit and withdraw their cryptocurrency from different wallets securely and efficiently.


There was a late addition to this, a chrome extension that allowed Bets.io users to make quick shot bets and access the live feeds for matches without touching the website.

An early stage prototype of the betslip, the product had to include a multi bet and single bet option.

Buying Terminal, collapsed before any transaction occured.

Buy Bitcoins terminal, built under the ‘money’ tab which also included a transaction history and bet history.

Requested funds terminal, if memory serves, like stocks you have to request from the stock provider the amount you want and price, only then will it be processed.

Depositing terminal, showing total balance, bonus and bitcoin address.

Chrome Extension Wireframe

The plan for Concept 'B'

Now I was able to start taking control of the situation a little and begin to outline the problems we were experiencing with concept 'A'. The First problem was, who built it the existing MVP. A single full stack developer, who had no interest in Esports, but understand fintech and crypto. Which impacted negatively on the team's individual views of the product and how it worked.


The Second, being the crucial elements of the product – the Bet Slip (which users interact with in order to keep track of their bets and odds) and Betting markets (what they actually can bet on). Which were built in house to vaguely resemble the mother site, Sportsbet.io.


This caused issues with the market syntax and general taxonomy, as we needed the product to make sense not only to Esport lovers, but to existing Sportsbet customers, whom may not have any experience with Esports.


So we reviewed the product in an affinity diagram, airing out our personal thoughts on the product. After this I built a KANO model to explain where our energy was needed most right now in the design.



The Affinity Workshop

Because our team was scattered in Tallinn (Estonia), Kiev (Ukraine) and Den Haag (Holland), we had to complete this workshop remotely, using primarily at the time, Slack and skype meetings to fill in the affinity diagram. A task that should in theory take around 45 minutes to complete, took days.


The Translation at times was loose, so for some staff we opted for skype interviews and others (whom may not of understood the logic in doing this, chose to answer in a questionnaire.) so we could avoid miscommunicating the point they tried to make.

KANO Model

To prioritise what we needed to work on from the ground up, we used KANO to plot the various mentioned product features in order to determine which features were basic, attractive and performance based.



Low Priority


There were 3 items in particular that we considered the lowest priority – Casino Gaming, Game Item Bets and the Commenting/Blogging elements.


Casino Gaming – This was a Sportsbet.io feature that their existing customer base knew very well, this was already built and ready to add in once the product was complete, so not much was really needed to be done here.


Game Item Bets – A controversial one at that, the product primarily was about Esports betting, whilst the game item betting or skins betting as it’s also known as, was very popular at the time, it was clear that this could of been a product of its own and thus would require too much time invested to do.


Commenting – Now, this was interesting, because the community dynamic on Sportsbet was there, however analytics suggested otherwise – The bets that drew the most community discussion were often the biggest Esports events (Minimum of 4 comments per bet) But on day-to-day bets (The minimum was less than 1). So made a calculated decision to not implement commenting/blogging into bets.io on the grounds that the lack of comment activity could make the site feel empty.


But we didn’t think this was a completely redundant element. We wanted to add a community chatroom on the site which users could interact with globally or on specific bets.



High Priority



Language support was the queen on the chess board, we really needed to implement support for our Russian and Asia Markets. According with Sportsbet analytics, more than half of their web traffic consisted with Russian, China, Japan and Malaysia.


What we offered on the bet market and how we offered it was second, it wasn’t enough to have multiple game title options but to really delve into the deeper aspects of the games and the players involved (offering market options for rounds won with melee weapons in use, rounds won with both teams having survivors on them, objectives taken before certain times, as examples.)


DeFi Conversion was 3rd, Most of our users were BTC betters, but with ALTcoins like ETH (and dare I say, Ripple… At the time) we needed to provide users with an option to use either options, or convert. (Like an exchange broker)

Planning the Architecture

There was method in the madness here, we planned to showcase this as a ‘tube map’ showing entry into the product and the types of interactions that can take place between each page and modal. It would condense the information to roughly where it needed to be rather than exactly, because we realised that at times some parts are going to over lap.

So, We made a set of rules and colour coordinated the journey map, the rules were:


Each line could go back and/or forward until it hit a stop.

Stops could only be added as notifications, modals, warnings or the exception (404)

Dotted Lines had to be available at all times, like a servicing trolley or a ticket master on a train.

Each page/modal represents a station and platform (the station is the master location but the platforms are other affiliated links or services)

AB Testing

'First Wave'

The first wave was solely about understanding the homepage interface, we made this the ‘Grand Central’ of all our site activity, so we knew this had to tick a lot of boxes.

The Kiev team was given both designs and the Map, and asked to comment on ‘A' and 'B’, on which they felt fit the map best, and where on either they felt both concepts didn’t.

The 'A' Concept (The existing design, Design #1)


Most said it was unengaging.


There was no hook, they were leaving the site within 5 minutes, and that was generous, they were here to test the product, so they knew to spend time on it. But otherwise, they didn't stay to actually want to place a bet.


Most said it was Too Clinical.


The site felt like it was trying to say 'was welcome, here's your markets, go bet'. We needed to make the site feel bigger, more venturous, like walking into casino and being spoilt for choice.


We also had to keep an open mind, some people want to bet on specific games they love to play. Introducing them to other marketing's and Esports titles had to be handled using different vocabulary.


Most said they don't understand the Navigation


Better structure of information, better definitive menus, labelling objects, grouping of certain assets and clear CTA's.


Some said it's the design was just plain sh*t and a couple said it's too bright.


By plain sh*t I realised what they meant was it was just empty. We needed to fill it with image and colour and contrast between items to help them understand the layout.


THE 'B' Concept (Proposed, Design #2)

Most said ''B'' was fun to look at more engaging.


Just by adding some adaptive livestream functionality, our co-workers were spending more time watching the streams on the site.


It opened our options up, we could now set bets to automatically show the stream on the homepage. So as they decide to bet, they could see what was happening, live.


Most said ''B'' bet slip was clear to understand


The bet slip didn't feel unintegrated, now it was, all in one menu along the top of the site. By making the navigation leaner, it reduced the amount of thinking time spent in understanding where things were.


Most said ''B'' Bet markets needed more work, but it was better.


This became out biggest challenge, cramming the right amount of information needed to make a bet. We didn't master it in ANY version of these designs.



Some said ''B'' CTA's needed work


The blocks in generally utilised a lot of unnecessary space and when squashed to mobile, became unbearable invasive.


A couple said ''B'' Navigation was 'too lean' and that ''A'' felt fuller.


We agreed, even though we designed a simpler menu, we neglected some of the details and we needed to address this later.

Wireframing For Mobile

But above all, our biggest issue with the newest design was that it struggled for mobile compatibility, because there was so much emphasis on trying to add character to the original concept, there was no development into the behaviour.


So I began to wireframe the design for mobile, from scratch, following the map, to see if we perhaps missed stuff in the design. We had, or at least we hadn't given enough thought into some features.


Features we know are important to Mobile but are less important to web had been neglected,

stuff like a support FAB, a settings tab for stream input. We even revised the layout of our navigation and started asking questions like – How important is it to show the logo now that we're logged into the product? Can we format

‘Mobile compatible’ Wireframed concept

'Mobile compatible' Wireframed concept – With a bit of colour and some basic animation features included.

Mobile compatibile

AB Testing

'Second Wave'

The Second wave was primarily about understanding if A, B or Both fit the map in similar ways, despite the designs being somewhat different. The team were asked questions to give their opinions on the interfaces to see whether they had a preference.




The 'A' Concept (Proposed Design #3)


Most said the 'A' layout was better.


The general plan around the layout change, was just to improve context and grouping of information for mobile, and the result was met with a positive response. Great success.


Most said the 'A' looked like an actual betting app.


This was encouraging, the end goal of this was to produce a working Betting app/site for Sportsbet and to hear that our team was now seeing the product as it was intended, from where we were at the start, was major progress.


A few said the 'A' bet markets were a lot better now, but still required more improvement to ease concern.


The appearance wasn't the issue here, it was how the markets for each bet was displayed. I had essentially just added a number in a bubble next to them.


This wasn't clear enough to some our team testing the product and often made them ask – where are the other markets on this match?


Some said the 'A' design had gone backwards – going back to white.


This was fair point, the app was more white than ever. So we discussed the inclusion of a dark mode or simply adding more contrast on some pages.



The 'B' Concept (Proposed Design #2)


Most said ''B'' was still almost perfect for web.


The big thing here was the inclusion of twitch, which at the time, viewing experience wasn't very good on mobile, so we had to cut this out of the mobile concept. We now needed to find a new way to bring twitch to the site without being imbedded into the site.


Some said ''A'' handled the markets better and should become the new norm.


The markets as mentioned, never became perfect any approved change was a good step forward. This meant we could just redesign the layout of the markets to match the mobile and we'd be on to something.


Most said ''A'' Balanced the navigation requirements and expectations


The team described the syntax as clearer because of this format. They could locate pages to go to and what options they had available on each page quickly.


A couple said wanted 'A' to have more of 'B' CTA inclusion


To my understanding this was wanted by our marketing division to encourage quick signup and play actions from the app/website directly.


But this also raised concerns with how often a user would be interrupted whilst playing. So we needed to come up with a way of making CTA's non-intrusive to the experience.






Prototype build

The new challenge now was to build a prototype, one that brought all the good of ‘A’ over the Desktop, implemented a different broadcasting interaction, make less intrusive CTA’s and give some animated context to the layout to show our product owners the journey in action.


We were in the midst of completing this prototype when our team began a series of restructure and reassignment which inevitably killed the project off completely. Over the years I have tried to piece together parts of the design which never saw the light of day to give context to the work our team created.