BuildABet
Deep dive into Sky Bet's BuildABet - an intensive 6 month process from ideation to launch. See how I led design on a project valued at over £50m for the business in 2023 alone.
Introduction
One of my proudest projects to date. A Bet Builder feature was heavily requested from our users. As an offering, Sky Bet’s product had fallen behind competitors and the opportunity here was huge. The bet builder feature alone was valued at £28m in 2022.
This valuation was however dependant on the feature launching by the Champions League Final, one of the biggest sporting events of the calendar year. This gave us just short of 6 months to design, test, develop and launch. Collectively, it was the largest feature release the business had ever done - with 16 individual squads pulling their weight.
In design, I worked alone for the most part of the project. We kicked things off with a design sprint where I was a participant. Then I drove the project forward individually - initially working closely with our User Researchers to ensure we were meeting user needs. Then with the Product Managers and Engineers, to make sure the product feature I was designing was viable and technologically feasible. Collaboration and ongoing communication was vital here with this project having such a tight deadline and hundreds of people working on it.
Design Process
We kicked this project off with a great deal of user research. 90% of our competitors already had a Bet Builder product, so familiarising ourself with those was a start. We then wanted to build on this, and find out the users motivation for using their current Bet Builder product of choice.
For this, I worked closely with our Consumer Market Understanding team to devise a survey. The results of this survey were to be the kick off for our Design Sprint, with one of the Consumer Market Understanding team being our expert representative - explaining the results and answering any questions our Design Sprint team had.
The Sprint
As mentioned previously, we ran a Design Sprint to tackle this project. The main motivation behind this being time. A 5 day sprint, if successful, would cut out a lot of time. It allowed us to analyse the research, ideate, design and test potential solutions with users over such a short period of time. Which in turn, allowed us to validate our assumptions, align our team and most importantly - include our users at such an early stage of the process.
Day One
The first day was all about understanding the problem. Once we’d said our hellos we spent some time defining a goal. This goal was to foresee, in an ideal world, where this product would be.
In 2 years time, our Bet Builder will be the most popular, intuitive and flexible experiencer in the industry.
This was then supplemented with a number of sprint questions that we decided collectively, we were to refer back to both these and the goal throughout the course of the sprint.
The next stage was making a map. Starting at our actions (stakeholders) and our outcomes - then mapping the journey between the two. The aim here was to come up with a focus area, and in turn establish some ‘How Might We’ questions. Again, as a reference point for the remainder of the sprint.
Day one was wrapped up with arguably the most important part: Ask the experts. We had someone from Research, to communicate the users needs, wants and motivations; A senior representative from Product, to communicate the business requirements; someone from trading, to lay out any early constraints with our trading models; and finally someone from engineering, to again lay out early constraints but equally as importantly - previous failed attempts and the reasoning behind them.
Day Two
Today was all about getting creative and things were kicked off with some competitor analysis. Individually, each member was to identify a product (or two) where they completed some sort of building experience. We encouraged participants to look outside of the gambling industry for a broader set of examples. Each participant then communicated what they liked and disliked about each.
Following this, we moved onto Crazy 8s. Where each participant was to come up with 8 ideas in 8 minutes. This was to start to shape solutions - pushing beyond that first idea. These were pinned up on a wall and discussed within the group before things were wrapped up with a dot vote - where each participant voted for ideas they liked.
To end the day, participants then went away to draw up some solution sketches. These were to be fully fledged solutions to the initial problem. Pulling together everything we’d worked on to this point.
Day Three
The Art Museum. Each participant pinned their solution sketch on the wall and gave it a catchy name. As individuals, the rest of the group were then asked to dot vote on solutions (or sections of solutions) that they like. Post it notes were left with questions that participants had which in turn shaped the proceeding discussion. We moved forward with clusters of stickers around the areas that were favoured and a super vote from our decider. This allowed us to start to shape a final solution to test with users, which we collectively plotted on a storyboard.
Day Four
On day four, I took this storyboard and built a rapid, but realistic prototype to test with users. This was built using Figma’s prototyping functionality and tested using User Zoom. Whilst building the prototype, I worked closely with one of our UX Researchers to shape what exactly we wanted to validate with users. Between us, we established a test script for the following day.
Day Five
We conducted moderated user tests remotely with 6 individuals. Each of which fit the mould of the screener we handed to our external recruitment company, which was mainly focussed around them being current frequent bettors.
The Output
Overall, we received extremely positive sentiment on the experience. With users understanding the build process for the most part and new patterns tested well. There was one stumbling block around the entry point which prompted us to revisit an established component in our design system.
Another issue that presented itself was a lack of understanding around the reasoning for a separate build mode. Users wanted to build where they were, and didn’t understand why a separate slip was required before adding to the bet slip. This was spot on, but was actually a strict tech constraint as a result of how things were currently built.
Following this, I wanted to gain more of an understand into the friction it caused for a user. If this was to be so much of a usability problem I had to make a case to the business. Additional focussed research seemed the best route.
2 weeks later, we ran another user test. This time focussed around the building of the bet. Again, we recruited 6 participants, and ran an A/B test. The first instance was very similar to what we tested initially. The second, a complete different build process, whereby a user simply selected betting options and the bet slip handled the complex grouping.
The output from this was very interesting. Our assumptions off the back of the first round of user testing led us to believe that users wanted to add betting options from anywhere on our app. This was however disproved, with the initial version testing much better and scoring much higher on ease of use. This gave us greater confidence in this approach going forward.
The Build
We now knew what this product should be. We had a very solid base to iterate on. I continued to refine over the next few weeks based on close discussions with engineering. With around 4 months to build, tech constraints were strict. The information architecture had to match what was currently there.
Error states were designed whilst closely collaborating with engineering and product. Then tested early on an internal staff beta. Ideally, these would have been tested with users but time didn’t allow. At the time of writing, I am working through a test to revisit error states and general signposting of our app in general, so this should feed into this once the results are back.
Next steps
We launched our MVP in time for the Champions League Final fixture in May, where we took over three times our previous record in single event stakes (£1.3m) - with 55% of those coming directly from this new feature. The customer sentiment was great. Our users took to Twitter to express their thoughts on our newly launched product.
We had an ongoing line of communication with our users over social media which really drove our offering. Trading used the feedback to add new markets to BuildABet, which led us to have the more available bet builder markets than any of our competitors.
Following launch, we’re now fully committed to improving the offering. My next area of focus is around the sharing side of bets, particularly in the created bets space. With the product now live and in the hands of users, there’s space to really innovate and drive it forward.
Learnings
As someone who has spent a lot of my career in startups. I was surprised at how we were able to work collectively in such an agile way. One of my big reservations previously about working in a larger company on larger projects was the perceived inability to gain learnings fast, iterate quickly and work so closely with engineers on a fast paced project. This project really disproved that assumption.
If I was to do things differently, it would be to better understand the tech constraints upfront. There were a number of iterations which were dismissed due to the technological feasibility of them. As someone initially from an engineering background, I feel more upfront discussion and perhaps more engineering representation in the design sprint could have saved more time. Therefore allowing more focus on testing on a more granular level.
At the time of writing, BuildABet has been a huge success for the business. It continues to make up over 50% of our single event bets and the projected yearly targets have been doubled since launch. For me personally, it was a great project to work on - and the largest of my career to date.