Alexander H. Black

Fantasy Sports Betting App

Client commissioned the redesign of an application for fantasy sports where users would bet points on sports games using Las Vegas odds

My Role

Redesigner and Full-stack Engineer

Tools Used

Figma, React Native, Typescript

Project Duration

August 2019 - December 2019


  • Client commissioned the redesign of an application for fantasy sports leagues where users would bet fantasy points on real sports games using Las Vegas odds in a user created league
  • Design was missing crucial elements such as a login flow, user pages, and more. The client was also dissatisfied with the visual language that was heavily based on Google’s Material Design
  • Client wanted to develop the project immediately. After establishing a working relationship with the client, a development contract was agreed upon
  • Using React Native with Typescript and Django with Graphene, a multi-platform Graph-QL app was rapidly developed


The client had previously hired a designer to create an application they had envisioned. The application was a sports betting app where in place of real money, users are given points by a league admin where they would then bet on sports games using Las Vegas odds. The person who made the most points across their bets throughout the season won. The application was similar to applications such as Fanduel or Draft Kings; however, it did not raise gambling concerns as it did not use a legal tender.

While the product was clearly defined, the client was displeased with the previous designs due to the following issues:

  • The design used heavy Material Design elements, and the client preferred Apple’s design guidelines
  • The client felt the app was not intuitive to those unfamiliar with sports betting and the conveyance of the unknown concepts wasn’t well done
  • Many screens were missing. For example users’ profiles and league pages weren’t there, the designs lacked a detailed login flow, and there were no pages demonstrating contextual variants of anything.

Additionally, the client wanted to move immediately into development after the product was designed.

Solving the Design Problem:

Old Designs


In addition to the client’s issues, I identified a handful of other issues:

  • The designs did not facilitate easy extensibility. While the client expressed clear interest in expanding into other sports, V1 of the application was intended to be just American Football in order for a faster release as well as reducing the management of numerous sports’ APIs or large costs for a single multi-sport API.

    • Other sports require additional information to facilitate proper betting, such as baseball betting being heavily dependent on starting pitchers, and as such extensible designs were crucial.
    • Additionally, the previous designer used baseball teams as well as inaccurate logos for most listed teams, so the copy in the designs did not fit the goal at all.
  • The app lacked a manual login flow. While some apps do this intentionally, the client did not want the product this way.
  • The application relied on invitations; meanwhile, there were no screens to accept the invitations, whether you were a new or existing user.

    • The application used inconsistent copy, often using two different terms to refer to the same view.
  • Leagues vs Leaderboards, Users vs Players, etc.
  • Badges and other elements had failed the WebAIM WCAG2 testing, which left color-blind users with an unfair advantage while attempting to utilize the app.
  • If users wanted to make various picks or scroll through any list, they had to scroll through them until the end as filtering options were unavailable. This would quickly become cumbersome and could result in poor engagement and usage levels.
  • The app used SF Compact for the font, which is only intended for Apple Watch.

The client agreed all of these issues needed to be solved, and I began working.


I took the tactical approach of tackling low-hanging fruits first in order to solve numerous issues quickly; when it comes to design, the small changes can have the largest effects. First, I began modifying the fonts. I used a Figma Plugin that automatically set all text to SF Pro Display or SF Pro Text depending on text-size and set the leading based on Apple’s Design Guidelines. This had a significant effect on making the app feel more like Apple, due to how sharp Roboto is.

From there, I reduced the usage of Material design elements like top-mounted navbars in place of segmented control, and removed how much depth and 3D-likeness the app was portraying. It wasn’t as heavily Material as initially believed, but small, subtle changes went a long way.

While working on the smaller issues, I began implementing a consistent card pattern across the product versus the flat lists that were incorporated. The app relied on showing lots of bite-sized pieces of information that at some points were organized into groups, so incorporating a card-based UI made the app easier to follow. Implementing the card design as I went around the app allowed me to quickly unify the design of the application and set the foundation for the larger edits of new screens and entire page redesigns.

Using the pain points diagnosed, I slowly went around making the application more consistent as well as making it feel more like an Apple application. After these were solved, I began creating the missing pages and elements using the newly defined design language. I started with the login flow, and then moved onto creating League pages, user profiles, filters, settings, and then context variations of pages, such as a login page shown when clicking an invite link.

This all took about a month and a half. The client and I maintained an open dialogue, allowing for easy collaboration, feedback, and edits.

New Designs

Solving the Development Problem


The client had a developer work on the application before, but there was dubious work done alongside poor documentation, in addition to changes required based on the new design. I recommended we scrap the existing codebase and start from scratch; the client agreed.

We decided in order to release for both platforms simultaneously, we’d build the product with React Native. We also decided on TypeScript due to a couple of reasons:

  • Typescript comes with all the benefits of a statically typed language such as better testing, product stability, and IDE assistance versus traditional Javascript.
  • The client had aspirations to turn this into a full-fledged business, and based on my experience from consulting, Typescript made long term maintainability and team adaptation easier.

We elected to use Django for the backend because it allowed for a faster development time with it’s ORM and other baked-in features. I also elected to use Graphene for GraphQL instead of a REST API for a few reasons:

  • GraphQL is better suited for mobile applications because it allows easy over and under fetching of data
  • The information that would be used was already graph-shaped, with how much information was dependent on other sets of data, such as teams being reliant on games and users participating in multiple leagues


As a product designer, I prefer to start with the front-end because it allows me to use the information architecture to also define the database schema. After creating front-end views with a rough style implementation and defining their interfaces, I began back-end work and created the database schema using the Django ORM. The objective plan was to rig the apps together, connect it to an external API for the vegas odds and game data, finish styling, test, and finalize the publication.


The client decided as football season was coming to an end, it would be better to pause development until closer to the start of next season. The designs are completed and the development is about 80% complete, requiring external API integration, unit testing, and state management.

Like what you see?

Let's work together

Reach Out