Closing the Gap: Bringing Richer Data to Liquipedia

A Critical Place for Tracking Competition

Data on competitive matches plays a major role in esports. It helps people tell exciting stories, understand the metagame, and help fans keep up with favorite team. And in the modern esports ecosystem, most fans get their data from wikis dedicated to esports.

Liquipedia (LP) is the oldest and largest community-driven esports wiki, and covers more than 50 different titles. However, it has struggled to gain adoption in some games. Some of this is due to a lack of contributors, or how well it can meet the needs of fans. But another big reason is that other wikis simply gained more traction earlier in the life of a title, and has more market share.

Leaguepedia for example led as the premiere resource covering League of Legends (LoL, or League) for several years. However, in 2021 Leaguepedia lost its main contributor and many started wondering if it would continue to be reliable.

This presented an opportunity for Liquipedia to make a better case for itself in League and it was clear where we could start.

A Clear Opportunity and a Path Forward

While Liquipedia had a pretty robust experience around tournament data, it lagged behind many other esports tools when it came to tracking match-specific data. And while this wasn’t the only place where improvements could be made, the most logical place to start was in

making the League wiki more useful by providing a more robust experience around match-specific data.

This also meant that there were a number of important and obvious design goals that I needed to meet when I was brought in to solve this challenge:

• Ensure that data is easily scannable.
• Make sure data is presented clearly.
• Data must be presented in an accessible way (a huge problem in esports).
• Make sure the design is as flexible as possible.

The last goal will be clearer in a bit.

Big Implications of Work, and Little Time

Before I started deconstructing the problem, there were two things that heavily influenced my work.

First and foremost, I was given 2 weeks to solve this challenge. So I had to be very careful about where I focused my time and not introduce any new complex patterns.

Second, I already understood this problem very well having worked on it previously. And it meant that I had to be careful about the bias I was bringing to the table. But it also meant that I knew something about the implications and long-term effects of this challenge.

Every single esports title has a need for this kind of robust match experience, as evidenced by even the earliest games. And this meant that whatever I worked on had the potential to be applicable to every other wiki, and that it would be highly beneficial for the long-term success of Liquipedia if I tried to solve the challenge with this in mind.

So as I worked through everything, I kept the needs of other esports in mind as I began crafting the experience for the League wiki.

Deconstructing the Problem

Because of the long-term benefits of the project I spent more than half the time deconstructing the problem, working closely with the team to get a good sense of things before I started on any solution. The main things I needed to understand were:

• What data is most important to fans of League?
• How does data interrelate (what themes exist)?
• How is this data presented already (what mental models will fans already have)?
• What larger themes exist between different titles?

Having little time I had to rely on market research and talking to staff (who were League fans) to help me get to the right place. What I found was that a few important themes emerged from my research:

• There was an emphasis on wanting summary results, head-to-head statistics, and individual player performances.
• There also were typically three levels of data that existed: match, team, and player-level data.
• And many of these themes and interaction paradigms also existed both in the wider esports scene, and in traditional sports as well; just with different datasets.

These details also suggested that there were two approaches to the design I could take — organize data by scope, or by theme. As I started exploring them however it became pretty clear that both were somewhat inflexible and didn’t really fit the mental models fans would have. So I needed something else.

Hybridization as the Solution

Exploring a more hybrid approach is when things started to click. Hybridization forced me to look at data in a more modular way, which helped keep these collections of data more aligned with a users mental models, and was much more flexible — a big benefit for a product that was already modular in natur

A Few Design Challenges

When I finally got to designing solutions, the work went pretty quickly thanks to all of the work I had done upfront. But there were still a few challenges that I did have to spend some time on

The Right User Journey for the Most Impact

There are several places where match information exists on the wiki, and none of them could support the amount of data that we needed to provide. So it was clear that an extension of the user journey would be needed. And due to our constraints, the only realistic approach we had was extending the user journey with a dedicated match page. But there was one choice I needed to make.

The time limitations made it impossible to try and cover every situation that contained match data. So I had to be more strategic, and target the journey delivered the most impact for users. And thankfully that choice was pretty clear as tournament brackets were easily the most used feature on Liquipedia and where most users got their match results.

Designing for Clarity and Flow on the Match Page

One common theme in many competing products was just how packed full of data they were. This often created an experience that was difficult to understand/navigate, and a big element that I wanted to tackle. And several design choices I made that helped achieve this.

An Overarching Flow to Navigation

A common mental model fans have with match statistics is being able to compare each team’s performance in a side-by-side view. And while this would live or die based on what each module needed, I wanted to try to leverage the benefits of this approach to improve the predictability and navigation of the overall page.

Summaries as a Clear Package

I initially struggled with game summary components. There were lots of different details that would exist for different games, and adopting a purely modular approach could easily solve this challenge. However, it also was terrible at communicating this information clearly and concisely.

I eventually realized that the solution had to be clear about two things: what information described the context of the match, and what described things that affected or represented the outcome of that match. This meant I needed a more package-oriented approach, and the eventual solution helped with both clarity and creating a thematic relationship between “levels” of overviews:

Knowing how the Pregame Strategy Unfolded

Picks and bans have a big impact on a game like League. And there are lots of details I needed to surface, as they could help tell important stories — like how a wild last minute pick could completely change the dynamic of the games outcome.

Visualizing that story meant that I had to have a clear design around who picked/banned what, in what round, and in what order so that users could easily uncover the strategy that happened.

I also initially proposed a more open design to help show the selection order more clearly, however, the team felt that a compact approach was more desirable, so I adjusted my approach with their feedback.

Comparing Individual Performances

When comparing player performances in League, there are multiple levels of comparison that are important to be able to see. Beyond knowing who played what champion, their role, loadout (pre-game and during), and statistics all were things fans wanted to see.

I initially tried working through a number of configurations, but almost every single option — save for two — required a much poorer experience on smaller screens. And one was not viable as I couldn’t introduce any new interaction patterns (rip).

What remained was a pattern that was the most visually balanced and clear in how data was organized and flowed. But it also delivered another benefit by being built around these multiple levels of comparison which were easiest to parse with this version.

Oh, and it also was more flexible in its ability to manage other esports, if and when we got there.

Accessible Data Presentations

Esports statistics has always struggled with accessibility. And its an understandable effect of an ecosystem that is by design, highly complex and specific. However, this challenge was a great opportunity to improve the accessibility around matches. And there are several ways in which that was achieved.

Helping to Identify and Describe Structure

While some visualizations like the separation of selections in picks and bans help visually communicate information, there were lots of places where non-visual identification and labelling needed to be added to help fans using assistive technologies. And player details, and picks and bans were two places where adding context would help users with assistive technologies a lot.

More generally however, many visualized details just needed more expressive descriptions to help with understanding.

Creating More Accessible Visualizations

Previously on Liquipedia, colored borders had been used to identify factions, and I wanted to remedy that approach by creating an icon that players of League would understand. What I eventually designed was a simplification of Summoner’s Rift (the map), and clearly indicated the side that each team started on without needing any additional identifiers for help.

Feats also were commonly visualized across various products, but the icons that were used were not quite normalized enough to rely on the visualization alone. And in this case it was more prudent to include explicit text to help users understand the context better.

Match dots were also a new addition to the wiki, and each type of dot clearly represented the possible scenarios that could happen in a series of games (win, loss, not played). And while I believe that over time this was a cleaner visualization, in the final version we used letters which had a slight edge in clarity.

Next Steps

Match pages launched after I left Team Liquid, so I unfortunately don’t know the impact they’ve had. But before I left, the team was really excited about getting this design in the hands of users.

That said, there were plenty of things I was looking forward to doing if I had gotten to continue developing this experience.

Testing the Design with Users

Player performance components were dense, and somewhat suboptimal. And I would have loved to test different versions of the design with users to get a better understanding of just how important in practice this data was to a fan.

Similarly, in the user journey we opted not to duplicate small game summaries on the match page. But it would have been very helpful to run an A/B test to see how useful they were across every entry path if they remained. Of course this required fleshing out every other user journey to matches. Speaking of that…

Building out Every Pathway to Matches

Focusing on tournament brackets was a strategic call. But there were many more places where extensions to a match page would be valuable. And I would have wanted to dive a lot more into where those were, how they operated, and whether we could think about adjusting the user journey to be more predictable and simpler overall.

Exploring the Implications for Other Games

While I did my best to assess how the design could be applied to other esports, much more would be needed in the future. There are several different categories, all of them with slightly different details or behaviors that needed a more thorough analysis before I really knew this format would work for all of Liquipedia.