Redesigning the player pages for the OneFootball app: a UX case study.

Problem

Based on previous research, the players are one of the higher engagement drivers among football fans. Our current experience has a lot of interesting data, but it takes a lot of work to digest.

Also, many users don’t know these pages exist, and few interact with them. We need to make the player entity pages easier to find and access.

Goal

Redesign the player pages experience to build richer user profiles by encouraging users to follow players. We can also link news, videos, and transfers to the players’ entity pages, to keep the users excited and surface a lot of great content we have in our apps.

My role and team

I was the leading Product Designer on this project, and I worked alongside the research team (Mehmet Aydin, Moritz Braeuning, danbm94), PM (Maayan Ben), Engineering Manager (Jason Markotter), Business Analyst (Tomas Braessas) and developers from the News XP team.

Design process

We have broken the Product Design process into 4 phases: Think, Explore, Define and Build. This process was influenced by the Double Diamond framework.

1. Think

a. Current experience analysis

We started by analysing our current experience and the pain points we had in it.

We also analysed current entry points and the possibility of adding other entry points to make the feature more accessible for our users.

We analysed the data we were getting from the provider as well, and reviewed the current contract to see which other data we could get. We wrote down thoughts and questions and a lot of ideas.

b. Research:

We analysed previous research and did a new round of surveys to find out three key points:

• Awareness: Do users know they can follow players? Are users aware we have these player pages? Do they know how to find/access them?
• Current experience: What do they think of the present experience? What info is missing from the current experience? Are they interested in this information? Why? (only for personal interest or also for betting/fantasy sports?) Is there information/data that they don’t care about?
• Future experience: Are users interested in historical data of players/coaches, or do they need the most recent data? What about data from old players like Maradona or Pele? Is information about coaches relevant for users too? Is comparing players something they’d like to do?

We got 10.957 responses from Spain, France, the USA, Germany, and the UK.

Insights:

• Our current experience with the Player Pages is satisfying for most of our users, especially in France, Italy, and Spain.

• Fans need this information to feed their curiosity and to fuel them with hot topics to chat with their friends and colleagues
• The overwhelming majority of our users know that they can follow players.
• We should offer all kinds of data we have access to. With the right design and information architecture, we should present the most needed stats like Assists and Yellow Cards more clearly.

• Additional features: Users want to see stats from previous seasons. Most users would like to compare players against each other. Users would also like to have dedicated pages for coaches and retired players.

c. Benchmark:

We analysed what other apps were doing and got insights about the data they showed and how they displayed it.

d. Data analysis

We analysed the data from the current performance of our player pages and found out:

• Only 25.70% of our users follow players in our apps.
• Even the users that follow players are not getting much value from this feature since we don’t surface any content when you follow players on the app.
• On average, the users that follow players follow seven players each.
• 32% of our users are accessing the player pages without actually following the players.
• The main entry points are Match Line Up, Player Info & Team Squad.

2. Explore

a. Information Architecture

We started by exploring different ways to show the information and how to organise it.

b. Low-fidelity prototypes

We designed wireframes for the different information architecture approaches.

After that, we did a quick internal usability testing round with the design and News XP teams.

Main insights:

• If we want to go with any of these approaches, we need a lot of extra data, and we need to improve/update our contract with the data provider.
• Approach 1 is more comprehensive and organizes the information better.
• We need to test with real user to understand if approach 1 makes sense for them.

c. High-fidelity prototype:

With the insights gathered from the low-fidelity prototype, we did a lot of visual explorations and ended up with this high-fidelity prototype.

After designing it, we did a round of user interviews. We targeted 6 OneFootball users who frequently used our app and were based in Italy, Spain, and the UK.

Main insights:

• About the current experience: Users rarely know that player pages exist. Currently, there is little to no value when visiting that page:

“I don’t know how to find the player page”

“I’ve never been to a player page before”

• About the new experience: All participants found the prototype visually appealing, and they welcome the vast amount of new features and statistics.

“It’s way more visually engaging and more like a destination now”

• Although there are a handful of new features and sections the user can browse through, they don’t feel it’s overwhelming.
• Users were confused about the information inside the stats and season tabs. We could merge them both into one tab.
• We need to iterate on the design from the prototype to develop a feasible MVP
• We need to invest in the new data points we need from the data provider in order to build some of the features.

3. Define

a. MVP

After the learnings we got from the usability testings, we defined our MVP and future iterations.

For the MVP we added 2 new tabs: News and career. This is already adding so much value to the users, because we noticed on the usability testing sessions that it was one of the main features users noticed and were excited about.

We also aded new information to the header, like amount of followers, and replaced info tab with overview tab. Inside overview tab we added upcoming games, and similar player carrousel to drive users to keep exploring player pages.

We kept the season tab but redesign some of the main components to add top stats for the player, highlighting it they are in the top 5, top 15 or top 30 of players for that season. We also added upcoming games for each of the competitions the player is taking part of.

We added a suggested player carrousel to our home page as a new entry point to the top 10 player pages.

We also sourced hero images for the top 100 players because all the photos we had in our previous experience were low-quality headshots.

4. Build

We just released the MVP of our player pages on iOS! You can check them out by downloading the OneFootball app on AppStore. And we’re on last development rounds on Android so that will be released soon.

We also defined what we want to develop for V1.1, V1.2, and V1.3 of our player pages and have it already in our backlog to start building and iterating this feature soon.

Early results

We released the MVP last week and we can already see some early results of the performance of this feature:

• Player Follows within iOS users has skyrocketed: only in the last weekend, iOS users followed +83K players (+470% vs. previous weekend).
• Player Screen Views within iOS users are 25% higher than Android users.
• Player Tiles (HomeStream carrousel entry point) have been clicked +425K times with a 9,5% CTR.
• Screen distribution is in average 66% PlayerOverview, 14% PlayerCareer, 14% PlayerSeason and 7% PlayerNews.
• Already +64k articles have been opened from the PlayerNews page

Learnings

Sometimes as designers, we need to step out of our comfort zone and do a lot of work that shouldn’t be a part of our jobs to get the experience we want. For example, sourcing images for players, contacting data providers to understand data points and negotiating contracts around it, etc.

Also, it is vital that we, as designers, always vouch for our users and their needs to serve them the best experience possible, even if that involves having tough conversations with other teams & stakeholders.