Suitable
Product Management UX / UI Design Front-End Engineering

Leaderboard
Rebuild

Migrating legacy Angular code to React, solving deep UX friction, and rethinking what gamification should actually mean for students.

Company
Suitable
Timeline
6 weeks · 3 sprints
My Role
PM, Design, Engineering
Scope
30-40 story points
00 Context

What is Suitable, and why
does the leaderboard matter?

Suitable's flagship "Guided Pathways" product helps colleges centralize co-curricular and experiential learning opportunities and connect them to students. College Administrators map real-world activities to core competencies that reflect each school's mission. When students complete activities, they earn a predetermined number of points toward specific competencies.

The leaderboard was built to gamify this experience: to motivate students individually and in groups, and to give the program visibility on campus screens and social media. It was high-profile. And it was broken.

Originally, the leaderboard was calculated using two factors:

  1. Total Points: Total points earned from completing activities during a set time period.
  2. Student level (1-5): A status earned by completing a set of activities. By completing 3 or more level 1 activities in a competency, students level up to level 2 in that area. Once all competency areas reach level 2, the student's overall level increases to 2.
The catch: levels were prioritized over points. A level-2 student with 500 points ranked higher than a level-1 student with 750 points.
Screenshot of the original leaderboard design, showing a ranked list of students with their points and levels The original leaderboard — before the rebuild.
01 The Problem

Users were frustrated.
The code was exhausted.

I analyzed our full repository of customer feedback — past surveys, CS logs, support tickets, in-app data collection. Three problems surfaced repeatedly.

Convoluted ranking logic
The leveling system was prioritized over points. A level-2 student with 500 pts outranked a level-1 student with 750. Most clients didn't even use levels. The system punished engagement without explanation.
Filtering friction
Clunky time filters with confusing labels ("Last Semester," "This Semester"). No custom date range. Power users were manipulating URL parameters to get the data they needed.
Buried privacy controls
An opt-out existed, but it was so deep in settings that some students who didn't want to be ranked weren't aware they could opt out, leading to frustration and support tickets.
"The confusion wasn't about missing documentation. It was a lack of utility."

Alongside the user pain, the leaderboard ran on legacy Angular code. This created slow load times (2-5 seconds) and techincal debt: it was difficult to maintain and incompatible with the direction the rest of the product was heading.

Screenshot of the original leaderboard design, showing a ranked list of students with their points and levels The original group filtering — before the rebuild.
Screenshot of the original leaderboard design, showing a ranked list of students with their points and levels The original time filtering — before the rebuild.
02 Discovery

How I validated what
I suspected.

I developed a multi-channel data collection strategy to go beyond anecdotal feedback and build confidence in what we were solving.

In-app user surveys
Surfaced friction points directly from students and admins while they were experiencing them — highest signal-to-noise ratio.
Internal CS team interviews
The Customer Success team had a front-row seat to client frustration. Their pattern recognition was invaluable for identifying systemic vs. edge-case problems.
5 customer interviews
Direct conversations with admin users at client schools revealed the levels insight: that most schools simply weren't building their programs around levels at all.
03 Solutioning

Four decisions that changed
the product.

1
The smoking gun: remove levels from ranking
The boldest call. If levels don't hold weight in the minds of most users, they shouldn't hold weight in the calculation. The new leaderboard is based solely on total points. Simple. Legible. Honest.
2
Filter drawer: consolidated controls
All filters moved into a single side-panel. No more scattered dropdowns. Custom date range UI added, eliminating URL hacking entirely. Pre-set options rewritten in plain language and reflected frequently used options.
3
The Podium Finish
Top 3 students get a high-impact visual treatment. I designed a podium finish that's built for mobile and big campus screens alike. Adds real gamification energy and shareability.
4
Points breakdown sidebar
A sidebar showing how a student earned their total — broken down by competency. Nudges students toward skill growth rather than just chasing a leaderboard number.
04 Shaping

Blue sky → real world.
Budget is a design constraint.

After the initial design phase, I had to shape the project to fit reality: 4–6 weeks, 2–3 sprints, 30-40 story points. That means hard choices on the effort/impact matrix. Not everything made it. The features that survived were the ones that directly addressed the three core pain points discovered in research.

Concessions were made. Features deferred. But the shape we landed on was clean, defensible, and buildable within the constraints we had.

05 Outcomes

What changed.

30%
Target satisfaction improvement (from 60% baseline)
<1s
Target load time (down from 2-5 seconds)
0
Angular code remaining — fully migrated to React

Beyond the metrics the filter drawer component became a reusable pattern applied across the rest of the app. The leaderboard went from a feature clients complained about to one they actively showcased on campus screens, in newsletters, and on social media.

The podium lives on large displays in campus buildings. That visibility was always the point. Now the design matches it.

The redesigned leaderboard — delivered product.
next case study

What else has Max built?

Built with love and svelte by Max Wix · © 2026