Compartir experiencia sin borrar personalidad
Cuando este artículo se publicó por primera vez, el proyecto todavía se llamaba Blupoli. Hoy esa plataforma es Blupoli Puzzles, pero el problema de diseño que intentábamos resolver sigue siendo exactamente el mismo: ¿cómo puede una persona saltar de un Sudoku a un Nonogram, de un Logic Grid a un puzzle de regiones o a un juego contra la CPU sin sentir que ha abierto cinco aplicaciones distintas? La respuesta fácil sería imponer una plantilla visual idéntica. La respuesta útil es bastante más exigente: decidir qué partes de la experiencia deben ser previsibles y qué partes necesitan seguir perteneciendo a la mecánica.
Ese matiz importa porque la consistencia y la uniformidad no son sinónimos. La consistencia reduce el trabajo de orientación. La uniformidad, cuando se lleva demasiado lejos, puede borrar información esencial. Un tablero de Sudoku necesita comunicar cajas, números dados, candidatos y relaciones entre celdas. Un Nonogram utiliza pistas en los márgenes y estados de relleno. Un puzzle como LITS depende de regiones y formas; Logic Grid trabaja con relaciones entre entidades; Ataxx necesita turnos, piezas y respuesta de un rival. Pretender que todos ellos hablen exactamente el mismo lenguaje visual sería como diseñar un único teclado para piano, guitarra y batería porque los tres son instrumentos.
La pregunta correcta no es «¿qué componentes podemos reutilizar?»
En proyectos que empiezan a crecer, la conversación sobre diseño de sistemas suele saltar demasiado rápido a botones, tarjetas y componentes. Es tentador abrir una librería de UI y empezar a convertir cualquier patrón repetido en una pieza reutilizable. El problema es que dos elementos pueden parecer iguales sin cumplir la misma función, y dos funciones pueden ser equivalentes aunque se representen de forma distinta. Antes de extraer un componente conviene identificar qué expectativa del usuario estamos intentando conservar.
Por ejemplo, «nueva partida» es una intención bastante estable. Puede abrir un diálogo, regenerar un tablero o preguntar antes de descartar progreso, pero la persona entiende que esa acción inicia otro reto. «Deshacer» también tiene un significado común, aunque en un puzzle de un solo jugador revierta una operación y en un juego contra CPU deba retroceder una unidad de turno coherente. La abstracción interesante no es el icono. Es la promesa: una acción con nombre, estado, consecuencias y feedback previsibles.
Ese enfoque cambia la arquitectura. En vez de construir una caja de piezas estéticas para después buscar dónde encajan, empezamos por una lista de responsabilidades: navegación, configuración, ayuda, estado de partida, acciones recurrentes, persistencia, feedback, tema, accesibilidad y adaptación de layout. Algunas responsabilidades pueden usar componentes idénticos. Otras necesitan variaciones. Lo importante es que pertenecen al sistema común y no deben ser redescubiertas por cada juego.
El game shell: una frontera visual y de comportamiento
La idea que terminó organizando la experiencia fue el game shell: una carcasa alrededor del motor que sabe cómo presentar el juego dentro de Blupoli. El shell contiene o coordina el título, la configuración, las acciones globales, la ayuda, la relación con navegación, los mensajes de estado y el espacio donde vive el tablero. El motor, en cambio, conoce las reglas, el estado específico y las acciones que tienen sentido dentro de la mecánica.
Esta división es importante por dos motivos. El primero es de producto: permite que una mejora general llegue a muchos juegos sin editar cada implementación. Si cambiamos la forma de mostrar una victoria, la política de foco, el tratamiento de la ayuda o la jerarquía en móvil, esa mejora puede propagarse desde el shell. El segundo motivo es técnico: obliga a que el motor no dependa de detalles que no le corresponden. Un solver no debería saber qué ancho tiene la barra superior ni un componente de navegación debería interpretar candidatos de Sudoku.
La frontera nunca es perfecta. Algunos juegos necesitan controles que otros no tienen, o un tablero tan particular que obliga a ampliar el contrato. Eso no es un fallo. Un sistema de UI útil debe ser capaz de admitir excepciones legítimas sin convertirlas en copias completas. Si cada nueva mecánica necesita romper el shell, el shell es demasiado rígido. Si cualquier detalle se resuelve con una condición específica por slug, el shell es demasiado ambiguo. El trabajo consiste en mantener ese espacio intermedio.
Compartir estados es más valioso que compartir estilos
Un botón redondeado se puede copiar en cinco minutos. Un estado bien definido ahorra meses de incoherencia. Cuando pensamos en el sistema visual empezamos a prestar más atención a preguntas como: ¿qué significa que una acción esté deshabilitada?, ¿cómo se expresa una selección?, ¿qué feedback recibe una persona cuando una acción es inválida?, ¿qué cambia al completar el puzzle?, ¿cómo se comunica que una partida está guardada o que un ajuste requiere reiniciar?
Los estados son donde una plataforma deja de sentirse como una colección de demos. Si un juego usa rojo para «error», otro lo usa para «selección» y un tercero para «pista», el usuario debe reaprender el lenguaje aunque el estilo superficial parezca coherente. Del mismo modo, si un botón deshabilitado parece clicable en una pantalla y desaparece por completo en otra, el problema no es CSS. Es semántica de producto.
Definir esos estados también mejora accesibilidad. Una selección no debería depender únicamente del color. Un foco no puede ser invisible. Un cambio importante debería tener una señal comprensible para quien navega con teclado o tecnología asistiva. Cuando estas decisiones forman parte del sistema común, la accesibilidad deja de ser una auditoría final que intenta arreglar setenta interfaces y se convierte en un comportamiento heredado.
Sudoku fue un laboratorio, no una plantilla maestra
Antes de intentar resolver todos estos problemas en abstracto, usamos Sudoku como caso concreto. Era una elección útil porque la mecánica resulta familiar para mucha gente y, por tanto, cualquier fricción en la interfaz era más fácil de atribuir al producto que al desconocimiento del juego. El trabajo sobre Sudoku nos permitió explorar jerarquía, controles cerca del tablero, feedback, notas, configuración, onboarding y comportamiento móvil con suficiente profundidad.
La parte importante vino después: no copiar esa pantalla, sino separar las decisiones específicas de Sudoku de las que podían sobrevivir fuera. El keypad numérico pertenece a esa mecánica. La idea de que las acciones frecuentes deben estar cerca del área de juego puede ser general. Los candidatos son propios del juego; el patrón de selección y foco puede ser compartido. Esa distinción es el centro de nuestro artículo sobre Sudoku como laboratorio de interfaz y evita convertir un buen caso de estudio en una mala plantilla universal.
Este orden —resolver, observar, extraer— es más lento que diseñar primero un sistema completo y obligar a los juegos a entrar en él. También es mucho más honesto. Las abstracciones se ganan cuando sobreviven a varios casos reales. Cada puzzle nuevo puede confirmar una pieza del sistema o demostrar que estaba basada en una coincidencia accidental.
La jerarquía de una pantalla de juego no es la de una página editorial
Una de las primeras inconsistencias que apareció al auditar la plataforma estaba relacionada con el ancho y la distribución. Una página pensada para leer necesita una medida de línea cómoda. Una pantalla de puzzle necesita reservar espacio a una superficie interactiva que, en algunos casos, tiene una geometría rígida. Usar el mismo contenedor para ambos contextos era una decisión aparentemente coherente y funcionalmente equivocada.
El sistema compartido tuvo que aprender que la jerarquía cambia según el tipo de contenido. En un artículo, el texto es protagonista y conviene controlar la anchura. En un juego, el tablero necesita respirar y los controles deben adaptarse a él. Esto llevó a separar mejor las capas de layout y a permitir que las páginas de juego utilicen más espacio sin sacrificar la estructura común.
La lección va más allá del ancho. La consistencia no consiste en aplicar la misma regla en todas partes. Consiste en disponer de reglas coherentes para contextos diferentes. Una plataforma madura puede tener un layout editorial, un layout de catálogo y un layout de juego sin que eso se sienta como tres productos.
Los controles frecuentes deben vivir cerca del razonamiento
En un puzzle, la distancia entre una decisión mental y la acción de interfaz importa. Si cada anotación exige mover el puntero lejos del tablero, si deshacer está escondido en un menú o si borrar cambia de lugar entre juegos, la interfaz introduce fricción en una actividad que ya exige concentración. Esa fricción puede parecer pequeña medida en segundos, pero se repite decenas o cientos de veces durante una sesión.
Por eso el sistema distingue entre controles de partida y configuración. Herramientas como deshacer, borrar, cambiar modo de entrada o marcar suelen pertenecer al área de resolución. Ajustes como dificultad, tamaño o preferencias pueden vivir un nivel más arriba. La separación ayuda a que la pantalla se lea mejor y permite adaptar la densidad a móvil sin amontonar todo en una sola barra.
No todos los juegos necesitan la misma toolbar. Esa es precisamente la razón para modelar el patrón y no el inventario de botones. El shell puede reservar un lugar y un comportamiento para acciones de alta frecuencia; cada motor declara cuáles tiene sentido exponer. El resultado es familiaridad sin fingir que las mecánicas son equivalentes.
El tema claro fue una auditoría de arquitectura disfrazada de preferencia visual
Cuando una interfaz nace en un único tema es fácil introducir dependencias invisibles: un borde que solo funciona porque el fondo es oscuro, un color de selección con contraste insuficiente fuera de ese contexto, una sombra que asume una superficie concreta o un icono cuyo significado depende de una combinación de tonos. Añadir modo claro obliga a convertir muchas de esas suposiciones en decisiones explícitas.
Ese proceso fue valioso porque reveló qué estilos estaban realmente centralizados. Si un componente necesitaba una excepción local para cada tema, probablemente todavía no formaba parte de un sistema. Variables de color, superficies semánticas y estados compartidos permiten que el diseño cambie de apariencia sin cambiar de significado. También hacen más fácil revisar contraste y mantener coherencia cuando el catálogo crece.
El mismo razonamiento se aplica a preferencias futuras. Un sistema que distingue semántica de apariencia puede evolucionar. Uno que mezcla el estado del juego con valores visuales concretos se vuelve frágil. El modo claro no fue, por tanto, un simple acabado; fue una prueba de que las fronteras del sistema tenían sentido.
Las categorías pueden aportar identidad sin convertirse en código de color
Con un catálogo grande, las categorías ayudan a orientarse. También pueden aportar continuidad visual: un acento de color, un tratamiento de icono o una señal que acompañe a una familia desde el catálogo hasta la pantalla de juego. Esa memoria visual puede ser útil, pero solo si no compite con la información esencial del puzzle.
El tablero necesita reservar sus colores para estados con significado propio: selección, regiones, pistas, errores, caminos, grupos o piezas. Si la identidad de categoría invade esa superficie, puede dificultar la lectura. Por eso la personalización vive principalmente en el marco: encabezados, pequeñas señales, tarjetas y superficies secundarias. El juego mantiene control sobre los canales visuales que necesita para funcionar.
Además, ninguna categoría debería comunicarse únicamente por color. Texto, iconografía, orden y contexto siguen siendo necesarios. El objetivo no es convertir el catálogo en un arcoíris; es permitir que una persona reconozca relaciones sin comprometer accesibilidad ni claridad.
El onboarding común necesita saber dónde termina
Otro problema de escala aparece al enseñar juegos. Una plataforma con muchas mecánicas no puede depender de una explicación artesanal completamente distinta en cada caso, pero un tutorial genérico que solo señala «aquí está el botón de nueva partida» tampoco enseña a jugar. La solución fue separar el contenedor de onboarding del contenido y de los perfiles de interacción.
La estructura común puede gestionar pasos, progreso, cierre, persistencia y presentación. El perfil aporta una escena o acción representativa. Los datos del juego completan objetivo, reglas y terminología. Esa arquitectura se desarrolló más a fondo después y está explicada en el artículo sobre cómo enseñar un catálogo grande sin fabricar una interfaz distinta para cada puzzle.
Desde la perspectiva del sistema de UI, lo importante es que el onboarding no invada al motor ni se limite a una capa decorativa. Debe poder adaptarse a la mecánica, conservar patrones de interacción y desaparecer cuando ya ha cumplido su función. Enseñar es parte del producto, no un documento pegado al final.
Responsive no significa simplemente «hacer todo más pequeño»
Las pantallas pequeñas obligan a priorizar. Un tablero que cabe cómodamente en escritorio puede competir en móvil con la cabecera, la configuración, la ayuda y las acciones. La tentación de reducir todo hasta que entre produce interfaces densas y objetivos táctiles demasiado pequeños. Un diseño responsive necesita cambiar relaciones, no solo escalas.
En algunos juegos, los controles pueden pasar debajo del tablero; en otros conviene usar una barra compacta. Algunas explicaciones deben moverse más abajo. Ciertas opciones pueden agruparse. El shell ofrece puntos de adaptación y el motor informa de restricciones concretas. Esa colaboración evita que cada juego implemente su propio conjunto de media queries sin coordinación.
También hay que asumir que móvil no es un caso marginal. Blupoli Puzzles está pensado para funcionar en navegador y la estrategia móvil se apoya en una base web sólida. La decisión de explorar Android mediante un contenedor como Capacitor —que explicamos en el artículo sobre el camino de la web a Android— hace todavía más importante que la experiencia táctil no dependa de un escritorio.
Un sistema visual también necesita contratos técnicos
La coherencia no se mantiene únicamente con documentación. Cuando una convención es importante y verificable, conviene convertirla en contrato. El build puede comprobar que existen determinados assets, que las rutas generan correctamente, que no se pierden traducciones o que ciertas piezas comunes están presentes. Los tests pueden proteger comportamiento. La revisión visual sigue siendo necesaria, pero no debería gastar atención en errores que una máquina puede detectar siempre.
Esto conecta el sistema de UI con la arquitectura general de motores. Tal como contamos en la arquitectura de motores de Blupoli Puzzles, una plataforma crece mejor cuando las fronteras son explícitas. El shell no es solo CSS; es una interfaz entre el producto y el motor. Cuanto más clara sea esa interfaz, más fácil es saber qué debe validar cada lado.
La automatización también protege las migraciones. Si cambiamos una clase, un componente compartido o una ruta, no queremos descubrir semanas después que una integración poco frecuente quedó atrás. La cobertura técnica no sustituye a probar el juego, pero reduce la cantidad de inconsistencias accidentales que llegan a esa prueba.
Las excepciones sanas enseñan dónde mejorar el sistema
Un error habitual al construir sistemas es considerar cualquier excepción como una derrota. En realidad, las excepciones son datos. Si un puzzle necesita una representación que el shell no contemplaba, la pregunta no es «¿cómo lo forzamos a encajar?», sino «¿esta necesidad es específica o revela una categoría de casos que todavía no modelamos?».
Algunas respuestas deben quedarse locales. No tendría sentido añadir una abstracción global para un gesto que solo existe en un puzzle. Otras excepciones aparecen varias veces y merecen convertirse en extensión oficial. Esta observación evita que el sistema crezca por anticipación: no diseñamos veinte slots porque algún día podrían hacer falta; ampliamos el contrato cuando hay evidencia.
Ese enfoque mantiene la complejidad bajo control. Un sistema extensible no es el que puede imaginar cualquier futuro, sino el que puede incorporar futuros reales sin romper lo que ya funciona. La diferencia parece filosófica, pero se nota mucho en un repositorio con motores heterogéneos.
La auditoría cambió nuestra definición de «consistente»
Con el tiempo dejamos de revisar la UI preguntando si «se veía igual» y empezamos a preguntar si «se comportaba como parte del mismo producto». Esa diferencia guió una auditoría más amplia de navegación, accesibilidad, responsive, estados, contenido y rendimiento. El proceso está contado en «Parar de añadir para auditar lo que ya habíamos construido».
La auditoría fue importante porque las inconsistencias rara vez aparecían como grandes fallos. Eran detalles: un control que cambiaba de nombre, un tablero con demasiado poco espacio, una selección sin foco visible, una ayuda colocada en otro lugar, una pantalla que no respetaba el tema. Individualmente parecían pequeñas. Juntas definían cuánto esfuerzo necesitaba una persona para cambiar de juego.
Medir consistencia como reducción de fricción resulta más útil que medirla como similitud visual. Un puzzle puede tener un tablero completamente distinto y, aun así, resultar familiar si las decisiones periféricas siguen un lenguaje reconocible.
Lo que hoy llamamos sistema nació de muchas decisiones pequeñas
Es tentador mirar un sistema de diseño maduro y pensar que apareció como una especificación completa: tokens, componentes, estados, documentación, tests. En realidad, en Blupoli fue emergiendo de problemas concretos. El ancho de ciertos tableros obligó a revisar el layout. El modo claro reveló colores acoplados. Sudoku enseñó qué controles podían compartirse. Otros puzzles mostraron dónde el patrón era demasiado específico. El onboarding reveló la diferencia entre estructura y contenido.
Ese origen práctico es una ventaja porque cada regla tiene una razón. También significa que el sistema nunca está «terminado» en sentido absoluto. Cada mecánica nueva puede ejercer presión sobre una frontera. La misión no es evitar el cambio, sino hacer que el cambio ocurra en el lugar correcto: una mejora común en la capa común; una necesidad específica en el motor; un nuevo patrón solo cuando varios casos lo justifican.
El resultado que buscamos no es que se vea un sistema
Los mejores sistemas de interfaz suelen ser discretos. La persona no debería pensar en tokens, slots o contratos. Debería abrir un puzzle nuevo y reconocer rápidamente dónde está, cómo empezar otra partida, dónde buscar ayuda, qué acciones son seguras y cómo responde Blupoli a sus decisiones. Después, toda su atención puede ir a aprender aquello que sí merece ser nuevo: la lógica del puzzle.
Ese es el criterio con el que seguimos evaluando la experiencia. Si el sistema se nota porque impone la misma forma a todo, hemos ido demasiado lejos. Si cada juego obliga a reaprender el producto, no hemos ido lo bastante lejos. Entre ambos extremos existe una zona mucho más interesante: un marco estable que desaparece mientras juegas.
Hoy Blupoli Puzzles tiene más capas, mejor infraestructura y una identidad distinta a la del Blupoli de septiembre de 2026, pero esa búsqueda sigue siendo central. No queremos una colección de skins ni una aplicación gigantesca con un único tablero disfrazado. Queremos puzzles con personalidades reales que compartan una casa bien diseñada. Cuando una persona cambia de juego y siente que todo es familiar excepto el problema que tiene delante, el sistema ha hecho su trabajo.