Completionist — Jade Haldane

The problem worth solving

I started with a problem I actually have. I own plenty of games, but that does not mean I know which one I want to spend the time 100%-ing. A useful answer had to look at more than the number of achievements, because a game with 20 easy achievements can be completely different from one with 20 brutal ones.

Core design questionHow can I turn a lot of achievement data into a recommendation that is quick to understand, while still being honest that difficulty is never completely objective?

Three problems changed the project

The original API did not support the idea

I originally planned around Free-To-Game because it was easy to work with. Once I got further into the idea, I realized it did not have Steam IDs, achievements or personal progress, which meant it could not really support the project I wanted to make.

The Steam key could not live in the browser

Moving to Steam solved the data problem and immediately gave me a new one. I could not safely leave my Steam API key in the browser, so I moved the requests behind a Node.js/Express backend instead.

A valid score was not necessarily a useful score

My first scoring attempts technically worked, but the results did not feel right. Too many games landed together and some edge cases were wildly overvalued. I had to treat the formula like part of the design and keep changing it when the output did not make sense.

Pivoting to the right data

The first version of the idea was about discovering free games. Once I looked at the data I could actually get, I realized I was drifting away from the reason I cared about the project. I changed direction to the Steam Web API and focused the site on the user’s own library instead.

That also made the experience simpler. A Steam ID could load what I needed without creating another account system, and I decided games without reliable achievement information should simply not be shown rather than pretending I could score them accurately.

Designing the difficulty model

The scoring system took five tries. I kept testing it against my actual library, looking for games that clearly felt wrong, and then changing the part of the formula that caused the problem.

Rarity-based scoring

Started with average rarity and bonuses for rare achievements. It failed because rarity alone did not represent the amount of work required.

Workload + rarity

Achievement count was added and rarity bonuses were capped. Rarity could still overpower the overall difficulty.

Refining the balance

Workload tiers, reduced rarity bonuses and a deduction for mostly common achievements improved the spread, but too many bonuses and deductions became difficult to calibrate.

Weighted factors

Workload, rarity and special requirements were given defined proportions. This was clearer, but demanding special requirements could still have too little influence.

Core score + challenge multiplier

Workload and rarity became the core difficulty, while multiplayer, deathless and similar requirements became a multiplier. Special requirements could now raise difficulty without accidentally lowering the existing score.

Final interaction decisionI did not want the final number to feel like a mysterious answer the user was supposed to trust. I paired it with a difficulty label and a plain-language reason so the score gives context instead of replacing the user’s own judgement.

The finished experience

The finished site keeps completed games visible at the top because I still wanted finishing something to feel like an achievement. The main grid focuses on unfinished games, starts with the easiest completions first, and explains why each game received its score.

Full finished Completionist interface — I kept the game art prominent because it is still a library of games, not a spreadsheet. Difficulty, progress and the explanation sit around it to help with the decision without taking over the card.

Open Completionist ↗