Una forma más clara de entender lo que tienes, lo que cambia y lo que todavía falta en tu colección.
En Bongo Cat, buena parte de la colección vive en el inventario de Steam. Steam sabe qué items tienes, pero no te explica la historia detrás de esa colección. bongodex nació para convertir esos datos en algo que un jugador pueda recorrer, comparar y seguir con contexto.
ROL
Product Designer + Frontend
PRODUCTO
Herramienta para coleccionistas de Bongo Cat
STACK
Next.js · React · Tailwind · Prisma · Neon
DATOS
Inventario de Steam + catálogo propio
Contexto
Bongo Cat entrega skins, hats, emojis y otros objetos que terminan guardados en Steam. Cuando la colección crece, esa lista deja de responder preguntas sencillas: qué pertenece a un evento, qué rareza tengo, qué se repite o cuánto me falta para completar algo.
El producto está pensado para dos extremos que conviven en el mismo juego: quien apenas empieza a coleccionar y quien ya revisa eventos, rarezas y faltantes con mucha más intención.
La meta no era hacer otro catálogo del juego. Era darle sentido al inventario de una persona.
Problema
Una lista de items puede ser correcta y aun así decir muy poco sobre una colección.
La API podía decirme qué había en el inventario. El problema de UX empezaba después: había que relacionar cada item con tipo, rareza, evento, origen y estado de propiedad sin convertir la pantalla en una tabla imposible de leer.
Investigación
La investigación ocurrió pegada al producto. Trabajé con inventarios reales, revisé cómo respondía Steam y observé qué información empezaba a faltar conforme la colección se hacía más grande.
Inventario real
El dato de propiedad era el punto de partida. También aparecían duplicados, respuestas parciales, inventarios privados y estados que no podían tratarse como si fueran lo mismo.
Estructura del catálogo
Nuevos tipos y eventos obligaban a revisar si la taxonomía seguía teniendo sentido. La clasificación terminó siendo parte del problema de producto, no sólo de contenido.
Uso del producto
Con bongodex ya en uso, las dudas y comentarios empezaron a girar alrededor de categorías, comportamiento y nuevas funciones. Eso ayudó a decidir qué convenía resolver después.
Analítica
Las sesiones y la navegación entre vistas servían para saber si la experiencia estaba funcionando como producto y no sólo como una ficha de consulta.
Hipótesis
Si el inventario se enriquece con contexto y la interfaz cambia según el avance de la colección, una misma experiencia puede servir tanto a quien empieza como a quien ya colecciona en serio.
Propiedad antes que faltantes
Una cuenta nueva necesita entender qué tiene. Mostrar ausencias demasiado pronto sólo añade ruido.
Progreso cuando aporta algo
Los faltantes ganan peso cuando la colección supera 50% de completado y ya existe intención real de cerrar sets o eventos.
Dimensiones separadas
Tipo, rareza y evento responden preguntas diferentes. Mezclarlos en una sola jerarquía hacía más difícil filtrar y explicar la colección.
Prototipado
El primer enfoque se parecía más a un catálogo: mucha información útil en una sola superficie. Funcionaba para descubrir items, pero se quedaba corto cuando la pregunta cambiaba de ‘qué existe’ a ‘qué tengo yo’.
Ahí apareció la separación que hoy sostiene el producto. Collection quedó como espacio para explorar el inventario. Overview se volvió la lectura resumida de una cuenta. Las ideas pasaban por Figma o directamente por frontend según cuánto dependieran de datos reales.
El cambio importante fue dejar de diseñar una lista de objetos y empezar a diseñar estados de colección.
Sistema visual
La identidad tenía que convivir con arte muy distinto entre items. Por eso la interfaz se mantuvo oscura, contenida y con color reservado para jerarquía, rareza, estado y feedback.
Cards, fondos y chrome se mantienen atrás para que skins, hats y otros coleccionables sigan siendo lo primero que ves.
Los acentos ayudan a distinguir información y estados. No todas las superficies necesitan competir por atención.
Collection, Overview, Activity y Battle usan el mismo ritmo, iconografía y comportamiento aunque resuelvan tareas diferentes.
Arquitectura de información
La taxonomía tuvo que acomodarse a cómo Bongo Cat crece. Reservé categorías principales para conceptos estables y dejé espacio para subtipos y nuevos orígenes sin romper la navegación.
Skins
Coleccionables principales y base de Bongo Battle.
Hats
Categoría independiente dentro del inventario.
Emojis
Módulo propio con orígenes como Standard, Achievements o Pase.
Consumables
Categoría extensible; Fireworks vive aquí como subtipo.
Rareza y evento atraviesan varias categorías. Se modelan como dimensiones distintas para no convertir el catálogo en carpetas superpuestas.
Collection
Collection es la superficie de exploración. Aquí importa poder recorrer lo que existe, reconocer lo que ya pertenece al inventario y abrir cada item sin perder el contexto de la colección.
Overview
Overview responde otra pregunta: ‘¿cómo va mi colección?’. La pantalla cambia su prioridad según la cantidad de información disponible y el avance real de la cuenta.
Nuevo / casual
Primero muestra lo que ya tienes. Rarezas con cero items permanecen fuera hasta que exista algo que contar.
Coleccionista
Cuando el progreso supera 50%, aparecen faltantes, porcentaje por evento y una lectura más profunda de la colección.
Eventos
Cada evento calcula su avance con su total real. Un Advent de 25 items no se compara contra una meta inventada de 14 o 20.
Expansión del producto
Una vez que la colección y sus datos fueron confiables, pude usarlos para crear experiencias que Steam no ofrece.
Bongo Battle
Daily League trabaja sólo con skins. Ocho compiten en doce duelos de liga; los cuatro mejores avanzan a semifinales y final. El player vive en una ruta aislada para que durante el duelo no haya menús compitiendo por atención.
Activity
Activity reúne cosas que sí vale la pena volver a consultar: nuevos items detectados, llegadas por link, disponibilidad de Battle y novedades. El drawer y la vista completa comparten estado, y borrar una entrada permite deshacer la acción durante unos segundos.
Estados y confianza
Steam puede tardar, ocultar un inventario o entregar sólo una parte. Para el usuario, esos casos pueden parecer ‘no hay nada’, pero significan cosas completamente distintas. La interfaz necesita decir qué sabe antes de sacar una conclusión.
Validación
Con el producto en producción, la señal que me interesaba era si la gente recorría más de una superficie y encontraba razones para quedarse. Los primeros 90 días dieron una base suficiente para seguir invirtiendo en profundidad, no sólo en más items.
La validación también cambió el tipo de problemas que resuelvo: cada nueva feature obliga a revisar categorías, estados y prioridades del sistema completo.
Evolución
bongodex sigue cambiando porque Bongo Cat también cambia. Nuevos eventos, tipos de item y formas de conseguirlos obligan a revisar si el modelo de información sigue siendo suficiente.
La siguiente etapa no consiste en llenar el producto de módulos. Consiste en mantener una colección fácil de leer aunque debajo haya cada vez más reglas, datos y excepciones.
Diseñar bongodex significa decidir qué vale la pena mostrar antes de diseñar cómo se ve.
Es el proyecto donde más directamente conecto producto, UX/UI, frontend, datos y decisiones que siguen cambiando después del release.
Volver a proyectos→GUIGOLO
Diseño con intención. Sistema con claridad. Experiencias que se sienten.
MODULE · FOOTER SIGNAL
Tip: si desbloqueaste algo, abre “Misiones” y presume tantito.
Navegación
© 2026 GUIGOLO · MODULE · FOOTER SIGNAL