Norsk riksroto
Norsk rikstoto, www.rikstoto.no is a foundation that supervises pari-mutuel betting on horse racing in Norway.
I was hired as the sole UX designer into a team consisting of a graphic designer and a front-end developer in addition to a team of developers.
My tasks included
- Competitor analysis
- Journey mapping
- Workshop / focus group facilitation
- Qualitative studies (user testing)
- Quantitative studies (AB testing, analytics)
- Wireframing
- Interaction design
- Prototyping (Lo-fi, Hi-fi)
- UI-design
Goal
The goal of the project was to update and modernise their public-facing website and betting platform. They wanted a front-end framework allowing for rapid improvements and modifications, replacing the old cumbersome framework. Regarding the user experience, they saw that the existing solution did not align with a large portion of the potential customers. Therefore they wanted to employ a user-centred design process to the project to make sure that the different customer groups were heard and their needs were met.
Methodology and organisation
It had been decided early on that this type of project needed to be approached using an agile methodology, something which had not been employed by this company before. The small team of existing developers were extended to deal with such a large project by a team of contractors well versed in agile methodologies, and their chief developer acted as scrum master. The product owner had been recruited internally and was responsible for the overall planning, product roadmap, epics, user stories and together with the scrum master and the rest of the team, backlog refinement and prioritizations.
The “beta” site
To completely overhaul an existing website or software, one would often do one of two things:
- Incrementally improve the existing solution improving one bit at a time hoping that the users wouldn’t mind inconsistencies in interaction, information architecture, terminology and visual appearance.
- Create a whole new solution and launch it with loud fanfares and hope that the users like what they see.
However, it was decided that the best approach was instead to start creating a new separate site that talked to the existing back-end. This was for multiple reasons:
- The new front-end technology was not easily compatible with the existing one.
- We wanted to learn from the users and iterate and reprioritise quickly.
- We felt that could best be achieved by creating an MVP and inviting users to interact with the new site and give feedback.
- Although the back-end operated quite independently from the front-end, it had been uncovered that there were sections of the site where short cuts had been taken in the past and where front-end functionality was not completely detached from the back-end. We wanted to make sure that we adhered to the MVC paradigm in order to ensure that we made life easier for future development.
The users
From our initial research we knew that Norsk rikstoto’s customers could be split into two broad categories:
- The expert users who are specialists in horse racing. They know the horses, they know the jockeys, and which horse goes well with which jockey, if the horse performs well on a wet surface, etc. etc. This is a small group of customers, but they bring the largest turnover.
- The largest group is the casual user. They come to the site and place a bet if there is an extra large prize pool.
The existing website had been designed with the idea that it should be a good fit for all users. However, it was too involved and complicated for the casual user, and did not contain enough information for the expert user, who then had to source their information from elsewhere.
Based on this, it was decided that we needed to create separate solutions to provide the best possible user experience for each of these user groups.
The expert users
The expert users were the best understood user group. Some of the typical users even worked within the organisation and were also acquainted with other users of this category, so defining personas, and recruiting testers came quite easy.
It was decided to start with this group, since it was best understood and would also require the most complex UI and interaction design.
I used multiple techniques in order to elicit information from these users. The most productive was interviews and focus groups. The latter was particularly useful in order to understand the different approaches used by the different expert users, especially related to their use of external information beyond our control, and lead us to better understand what this user group needed.
Typically, if you ask people what they would like, you will often get the answer “don’t change much, I like it as it is. I am used to it.”. Based on previous experience, I knew that in order to get people talking, I needed to show them something. Therefore I created alternative sketches and prototypes, and that was a valuable tool to get people talking and discuss why it couldn’t be like that, and it should be quite different because of this and that. A general problem with any experts in a particular field is that much of their knowledge and expertise is implicit and second nature to them, so we need techniques to extract it from them.
Armed with findings from these we were able to create the first MVP where the users could purchase one type of game with one payment type, and we invited users to test the new site and give feedback.
The casual user
Parallel to the development of the first iterations of functionality for the expert user, I worked on researching the casual user.
One of the findings was that when we had an elevated prize pool, we would see an influx of new registered users. This was not surprising given that the company would do a lot of marketing before these events.
Onboarding
However, what I did see was that they would go through this rather involved registration process, and a large portion of the new users would not purchase a game. So why would they go through this complex process if they had no intention of purchasing a game?
It was quite easy to see why. After registration, new users were unceremoniously left to their own devices on the front page with no form of onboarding. I recommended that we should take immediate action on the main site. We created a simple onboarding asking the newly registered user about their experience and intention and performed an AB test.
- I want to learn more about betting on horses
- I just want to buy an automatic lottery ticket
- Just take me to the betting site. I want to make my own choices
We saw an uptake in about 60% of new users buying a new game within a week of their registration!
Mobile betting
Our studies showed that the expert users mainly used PCs on our site, not surprising given that they would often look at statistics and previous results in order to place their bets. The casual user, however, was much more inclined to use a mobile device. It was therefore natural to start with mobile first.
"Pick a number"
Placing a casual bet is as simple as deciding on the size of the bet. Not very exciting. How would the users respond to different ways of picking a number, and would it influence the size of the bet placed? I created a series of simple prototypes and did guerrilla testing in and around the office block.
Based on the feedback from the users, it was quite clear that the users were concerned with simplicity and ease of use. The excitement in the game was not picking a sum, but waiting for the races to complete and see if they had won. After the purchase and before the races they were potential millionaires.
I went on to refine feedback from the guerrilla test, and we went on to perform a more controlled user test/interview with a set of testers from different demographics. We got help from a company specialising in user testing to find and set up this test.
We asked them to give feedback on these three alternatives. They were presented in different order to the users in order to reduce sequential bias.
Four key findings were that they found the 60 million banner on the second alternative too pushy. They liked the picture of the horses, but felt it was unnecessary. They only wanted to enter a sum, not see anything distracting, albeit nice looking. The third key finding was that they found the NOK 200 pre-selected, suggested sum reasonable. It was on the top line, below the middle (you cannot have the middle of six, though) and it was less than half of the range of pre-selected numbers. This did not make us seem greedy trying to get the users to part with as much money as possible. The last finding was that they liked the explanatory text on the first alternative. It made it easier for them to understand the process.
Today, with updated graphic design, the mobile version still retains these key features:
Summary
The iterative process with continuous feedback from the users ensured we stayed on track with the wishes from the users. We kept adding functionality and features, iterating to improve the beta-site until the day it had more and better features than the old site, and then the beta-site switched places with the existing site.