Mobile Premier League

Fantasy Sports is a widely known game concept in India and around the world. It is growing like crazy.

It involves creation of Fantasy team(s) by users by selecting players from two teams that will be going head-to-head in a real-life match. Based on the real-life performance of the players in the real-life match, they get Fantasy Points. These points are tallied up for the players selected by users in their teams. The sum of these player points are the points earned by that particular team (Team Points).

A leaderboard is made based on the decreasing order of these Team Points. Prize is set on the leaderboard positions and users get prizes based on the leaderboard position of their registered teams when the match is concluded. Team registration requires an entry fee.

As a user, once the Teams are registered and the match is live, there is no construct that the user can engage in. Users can come and see their Teams move up and down on the leaderboard. However, they cannot do anything meaningful about it.

The construct of Fantasy Pro comes in this place. It offers a chance to the user to engage, as the match is live.

To understand where the feature will come in the picture, it is essential to understand the existing Fantasy constructs.

The bread and butter of the Fantasy product involves users registering their teams.

The basic team registration flow involves three simple steps (secondary and Tertiary Flows removed for brevity)

1. Choose a match
2. Choose a contest
3. Create and Register Team

Basis these steps, following are few constructs to keep in mind

1. Registered Match: Match where the user has registered with a Team. (For example: IND vs SL Match)
2. Registered Contest: Contest where the user has registered with their Team(s). (For example: Monster Contest, Grand Contest etc). NOTE: Users have the option to choose 1 or many contests and register with same or different teams.
3. Registered User in a Match: User who has at least one team registered in one contest of a match.

This feature, in the Version 1, was for Registered users only.

Fantasy Pro involves the concept of Team Trading. Meaning: As the match is in live state, registered users can trade their teams.

Principles of Trading-

1. Selling Module

• Users can set up and ask price on their registered Teams
• Users can sell their teams based on the bids they receive on their teams.

2. Buying Module

• Users can place on the teams they want to buy
• Users can directly buy teams on the ask price set by the Seller

The wireframes and the flows of the feature were owned by Tapan (Senior Designer) and Winy and Vansh (Product Managers) on the team. My role was to ensure conversion of the wireframes into the final pixel perfect production ready user interfaces. Hence, the case study won’t go into the details of the flow.

Once with the wireframes in my hand, I went on to create the designs ensuring their compliance with our Design System - VDS (Vector Design System).

1. Strict Deadline: We were on a strict deadline. Fantasy Sports throughout the ecosystem witness the highest amount of engagement during Indian Premier League (IPL), India's own T20 tournament. Hence the plan was to develop and ship the feature before the IPL for maximum output.
2. Cross Functional Dependencies: The whole construct of buying and selling is deeply complex from cross functional perspectives
   • Legal: Legal team had to ensure that the product was compliant of all the laws concerning
   • Engineering: The buying and selling of the teams would happen as the match is live. Meaning the database query fetching and conflict resolving should happen at a really quick speed. Hence several trade-offs had to happen so that the product could be shipped in a timely manner.

Therefore, the interaction/user experience envisioned was changing/updating continuously to ensure agreement from all the functions. For example: Team filters, a sub-feature that would allow users to filter out teams to buy, underwent massive changes in the scope. Hence during that time, rather than being reactive and changing designs with every change in the spec, we were proactive and were creating designs for each tier of complexity. This was a big challenge.

Since the Flows are incredibly detailed and complex and something that I didn’t own, the case study won’t delve into the details of flows. For better understanding, you may reach out to me and I will help understand the flows better.

To keep it short, I will explain generally where the new things were to be added and connect it with the screens that I had to own.

Fantasy Homepage: A pop-up with an autoplay video was set in motion to explain the feature to the users.

My Matches: To create excitement and improve engagement, the Trades count (the amount of trades that happened + happening right now) were to be shown.

Joined Contest Screen: On this Screen the joined contests were shown under the Live Scorecard. As the Fantasy Pro feature came into the picture, this became a really important screen from where the user journeys will start.

Leaderboard Screen: Screen where the users will see their teams, teams they have bid on and also all the teams on the leaderboard.

Filters/Filter Screen: Component on the Leaderboard using which users can narrow down their teams and subsequent screens where users can see their filter results and take actions accordingly.

My Bids Screen: Screen where users can see the teams they have bid on.

My Trades Screen: Screen where users have a top-level view on how their trades are faring out or have fared out.

Buy/Sell Screen: Screens where the primary actions concerning the trades happen.

What is this screen trying to solve/achieve?

• Communicating information about the leaderboard positions
• Acting as a starting point for trade flows-
  • On ‘User Registered Teams’ (Teams registered by the operating user) i.e. setting an ask price/editing an ask price/selling on a bid that was received.
  • On ‘Other Users’ Registered Teams’ (Teams the other users have registered in the contest) ie Bidding on their teams, Buying Teams on their ask price etc
• Acting as a starting point to Filter flow. Sub-feature where users can filter out teams based on several parameters.

Approach

• Idea was to build upon the existing leaderboard screen doing incremental changes to accommodate new information. Reason was that since this feature was to be developed in a limited amount of time and become part of the existing product ecosystem, major new constructs/patterns could not be introduced.
• Dividing the whole screen into smaller sections and the primary UI component to be worked upon was the ‘Leaderboard Item’

Leaderboard Item

• Along with the old information the new information that was to be accommodated was the Prices, CTAs.
• The Leaderboard Item had to be battle tested with edge cases covered and looked at how it actually pans out on the screen with real life data. \

Note on Explorations: Since Leaderboard screen was an immensely important screen, we did too many UI explorations to finalize it. There is a quick video on the right to cover the amount of variations we made and then covering each variation one by one.