A clearer way to understand what you own, what changes, and what is still missing from your collection.
In Bongo Cat, much of the collection lives inside Steam inventory. Steam knows which items you own, but it does not explain the story behind that collection. bongodex turns those raw records into something a player can browse, compare and follow with context.
ROLE
Product Designer + Frontend
PRODUCT
Collector tool for Bongo Cat players
STACK
Next.js · React · Tailwind · Prisma · Neon
DATA
Steam inventory + custom catalog
Context
Bongo Cat gives players skins, hats, emojis and other objects that end up stored in Steam. As a collection grows, that list stops answering simple questions: which event something belongs to, what rarity you own, what is duplicated or how close you are to completing a set.
The product needs to work for two very different stages: someone who just started collecting and someone actively chasing events, rarities and missing items.
The goal was not another game catalog. It was to make one person's inventory understandable.
Problem
An item list can be technically correct and still say very little about a collection.
The API could tell me what was in the inventory. The UX problem started after that: each item had to be connected to type, rarity, event, origin and ownership state without turning the screen into an unreadable data table.
Research
Research stayed close to the product. I worked with real inventories, checked how Steam responded and watched which information became harder to understand as collections grew.
Real inventory
Ownership was the starting point, but duplicates, partial responses, private inventories and errors all required different UI states.
Catalog structure
New types and events kept testing whether the taxonomy still made sense. Classification became a product problem, not just content organization.
Product use
Once bongodex was live, questions and feedback centered on categories, behavior and new features, which helped prioritize the next problems.
Analytics
Sessions and movement between views helped show whether this was becoming a product rather than a single lookup page.
Hypothesis
If inventory is enriched with collection context and the interface adapts to progress, the same product can serve both new and advanced collectors.
Ownership before gaps
A new account first needs to understand what it owns. Missing items too early only add noise.
Progress when it matters
Missing items become useful once completion passes 50% and the user has a reason to finish sets or events.
Separate dimensions
Type, rarity and event answer different questions. Mixing them into one hierarchy made filtering and explanation harder.
Prototyping
The first approach looked more like a catalog: lots of useful information in one surface. It worked for discovering items, but not when the question shifted from ‘what exists’ to ‘what do I own?’
That split became the foundation of the current product. Collection became the inventory exploration space. Overview became the account summary. Ideas moved through Figma or directly into frontend depending on how much they depended on real data.
The important shift was moving from designing an item list to designing collection states.
Visual system
The identity needed to work with very different item artwork. The interface therefore stays dark and restrained, while color is reserved for hierarchy, rarity, state and feedback.
Cards, backgrounds and chrome stay behind so skins, hats and other collectibles remain the first thing you notice.
Accents distinguish information and states instead of making every surface compete for attention.
Collection, Overview, Activity and Battle share rhythm, iconography and behavior even though they solve different tasks.
Information architecture
The taxonomy had to accommodate how Bongo Cat grows. Main categories are reserved for stable concepts, while subtypes and new origins can expand without breaking navigation.
Skins
Main collectibles and the only category used by Bongo Battle.
Hats
An independent inventory category.
Emojis
Its own module with origins such as Standard, Achievements and Pass.
Consumables
An expandable category; Fireworks lives here as a subtype.
Rarity and event cross several categories, so they remain separate dimensions instead of overlapping folders.
Collection
Collection is the exploration surface. It lets people browse what exists, recognize what is already owned and open individual items without losing collection context.
Overview
Overview answers a different question: ‘how is my collection doing?’. The screen changes priority based on how much information exists and how far the account has progressed.
New / casual
Starts with what you own. Rarities with zero items stay hidden until there is something useful to say.
Collector
After 50% completion, missing items, event progress and deeper collection information become more prominent.
Events
Each event uses its real total. A 25-item Advent set is not measured against an arbitrary shared target.
Product expansion
Once collection data became reliable, it could support experiences that Steam does not provide.
Bongo Battle
Daily League uses skins only. Eight enter twelve league matches; the top four advance to semifinals and the final. The player lives on its own route so side navigation does not compete with the duel.
Activity
Activity collects things worth revisiting: newly detected items, arrivals through shared links, Battle availability and product updates. The drawer and full view stay synchronized, and deleting an entry includes a short undo window.
States and trust
Steam may respond slowly, hide an inventory or return only part of it. To a user, all of those can look like ‘nothing is here’, but they mean different things. The interface needs to explain what it knows before drawing a conclusion.
Validation
Once the product was live, the signal I cared about was whether people moved beyond one surface and found reasons to stay. The first 90 days gave enough evidence to keep investing in depth rather than simply adding more items.
Validation also changed the kind of problems I solve: each new feature now forces a review of categories, states and priorities across the product.
Evolution
bongodex keeps changing because Bongo Cat changes too. New events, item types and acquisition methods keep testing whether the information model is still enough.
The next stage is not about filling the product with modules. It is about keeping the collection easy to read while the rules, data and edge cases underneath continue to grow.
Designing bongodex starts with deciding what deserves to be visible before deciding how it looks.
This is the project where product, UX/UI, frontend, data and post-release decisions are most directly connected in my work.
Back to projects→GUIGOLO
Design with intention. Systems with clarity. Experiences you can feel.
MODULE · FOOTER SIGNAL
Tip: if you unlocked something, open “Missions” and flex a little.
Navigation
© 2026 GUIGOLO · MODULE · FOOTER SIGNAL