Designing for Scale and Speed in Game Ratings Delivery
Every rating Gameopedia tracked started as a manual hunt operations teams pulling scores from across the internet into separate spreadsheets, before transferring it all into a database.
I designed the system that flipped this: automated scraping did the legwork & team simply validated.
Details hidden to protect confidentiality
Product Design
Operations
The Product
The Ratings platform, sits at the 'work completion' stage, it centralizes user & critic ratings for every game Gameopedia tracks. It replaces a manual, spreadsheet-heavy process with a structured interface where ratings data sourced from various review platforms.
Timeline
April 2025 - May 2025
Role
UX Design
UX Research
Visual Design
Usability Testing
Team
1 Product manager
1 Design Director
1 Designer
5 Engineers
The shift this platform created:
Before
SMEs manually searched across the internet for each game's critic and user ratings, platform by platform.
After
SMEs add a source URL; the system automatically scrapes the latest scores, review counts, and rating breakdowns.
Before
Scores were entered into a separate spreadsheet per game, held together by manual formulas.
After
SMEs review the fetched data against each platform the game is available on, correcting or adding ratings where needed.
Before
from the spreadsheet into the databas, a slow, error-prone final step before it could be used.
After
The system stores the updated values, with real-time checks to catch errors like incomplete percentage breakdowns before saving.
Challenges
Designing this platform meant working against deeply embedded habits every team had their own mental model for rating logic, built over years on Excel, and the risk of reverting back was constant.
Some games had 50+ platforms and 1000+ ratings to manage designing an interface that handled that volume without overwhelming the user was as much a challenge as the adoption itself.
Key Learnings
01
I learned that automation only works if people trust it more than their own judgment.
SMEs had years of manual practice validating ratings their own way. Designing for automation meant designing for trust as much as accuracy, the application had to prove itself correct often enough that people stopped double-checking it against their old methods.
02
I learned to design for data complexity without letting users feel it.
With some games carrying 50+ platforms and 100+ ratings, the goal wasn't to simplify the data it was to structure it so SMEs only ever saw what mattered in the moment. Designing for scale taught me that good complexity is invisible: the system holds it, not the user.
03
I learned to own the scope and delivery end-to-end, not just the design.
Setting up crits, gathering feedback, and tracking progress against the plan weren't side tasks they were part of how I made sure the project stayed on track. Planning the delivery myself, rather than relying on someone else to manage it, taught me how much smoother a launch becomes when the designer is also driving the process.
The Impact
Since launch, the platform has kept over ~75% of games updated with current ratings & cut SME time spent per game by ~80% turning a fragile, spreadsheet-bound process into one built to scale.
