El tablero como laboratorio de producto
En septiembre de 2026 el proyecto todavía se llamaba Blupoli. Hoy ese producto forma parte de Blupoli como Blupoli Puzzles, pero una de las decisiones de diseño más útiles de aquella etapa sigue explicando buena parte de la interfaz actual: antes de intentar rediseñar un catálogo entero, elegimos Sudoku como laboratorio. No porque quisiéramos que todos los juegos parecieran Sudoku, sino porque necesitábamos un caso suficientemente conocido para separar los problemas de la mecánica de los problemas de nuestra propia interfaz.
Ese detalle parece pequeño y cambia mucho la forma de diseñar. Si pruebas un sistema con una mecánica extraña, cualquier confusión puede venir de dos lugares: el puzzle es desconocido o la interfaz no está ayudando. Con Sudoku eliminábamos gran parte de esa ambigüedad. La cuadrícula 9×9, las cajas 3×3 y la idea de completar números son familiares para una parte importante del público. Si un botón no se entendía, si la selección era confusa o si el tablero perdía protagonismo, era difícil culpar al concepto del juego.
Trabajar así también nos protegió de un error común en productos con muchas superficies: intentar crear el sistema perfecto desde una vista aérea. Un catálogo grande invita a pensar en componentes genéricos, pero los sistemas útiles suelen nacer de estados reales. Elegir un juego y llevarlo hasta el detalle nos dio algo que una colección de wireframes no podía ofrecer: fricción concreta, secuencias de uso, decisiones repetidas y lugares donde la teoría dejaba de funcionar.
Un laboratorio necesita una pregunta, no solo un prototipo
La pregunta no era «¿cómo hacemos un Sudoku bonito?». Era «¿qué tendría que aprender aquí la plataforma para que el siguiente juego empiece desde un nivel más alto?». Esa formulación nos obligaba a revisar cada mejora en dos planos. Primero, ¿mejora realmente la experiencia de Sudoku? Segundo, ¿qué parte de esta decisión pertenece a la mecánica y qué parte resuelve un problema recurrente de cualquier juego?
Un keypad numérico es claramente específico. La decisión de mantener las acciones frecuentes cerca del tablero puede ser general. Las notas de candidatos son específicas. La forma de expresar selección, foco o error puede generalizarse. El resaltado de fila, columna y caja responde al Sudoku. La jerarquía entre tablero, configuración y contenido de ayuda puede sobrevivir en muchas familias.
Ese filtro evitó que confundiéramos «funciona muy bien en este juego» con «debe convertirse en estándar». Un laboratorio no produce leyes automáticamente. Produce hipótesis. Después hay que probarlas en otras mecánicas y estar dispuesto a descartarlas. Esa disposición a perder una buena idea local para ganar un sistema más flexible ha sido más importante que cualquier detalle visual concreto.
La primera mejora fue devolver el protagonismo al tablero
En una página de puzzle, el tablero es la tarea. Todo lo demás existe para sostener esa tarea: explicar, configurar, recuperar, reiniciar, ayudar o registrar. Sin embargo, una interfaz que crece por acumulación puede acabar tratando el tablero como otro bloque entre muchos. Encabezado, botones, selectores, textos y tarjetas compiten por espacio hasta que el objeto interactivo deja de dominar la pantalla.
Sudoku nos permitió medir esa jerarquía de forma casi física. Una cuadrícula necesita tamaño suficiente para que las celdas se distingan, los candidatos sean legibles y el gesto táctil no resulte impreciso. En escritorio puede convivir con más elementos alrededor; en móvil cada línea adicional en la parte superior roba espacio útil. Esta observación llevó a revisar anchos generales, densidad y orden de los controles.
No se trataba de hacer el tablero enorme por principio. Se trataba de reconocer que la interfaz debía tener una prioridad clara. El contenido editorial puede vivir debajo. Las opciones poco frecuentes pueden agruparse. Las acciones de resolución deben estar cerca. Esta jerarquía, nacida de Sudoku, se convirtió después en una pieza del sistema de UI compartido de Blupoli Puzzles.
Frecuencia de uso y cercanía física empezaron a ir juntas
Durante una partida de Sudoku se repiten acciones: seleccionar celda, introducir valor, cambiar a notas, borrar, deshacer, quizá comprobar un conflicto. La configuración de dificultad o tamaño importa, pero normalmente no se toca cada diez segundos. Poner ambos grupos al mismo nivel visual crea ruido y obliga al usuario a explorar más de lo necesario.
El laboratorio nos llevó a separar configuración de herramientas de resolución. Las primeras pueden vivir en el contexto de la partida y no reclamar atención constante. Las segundas deben poder usarse sin abandonar mentalmente el tablero. En móvil esta diferencia es especialmente importante: mover una acción frecuente a una zona incómoda se convierte en cientos de desplazamientos del pulgar.
La regla resultante no dice «todos los juegos tendrán los mismos botones debajo del tablero». Dice «la interfaz debe colocar las acciones según su relación con el razonamiento y su frecuencia». Eso permite que un Nonogram tenga herramientas distintas, que un puzzle de caminos no necesite keypad y que un juego contra CPU organice sus acciones de otra forma sin perder una lógica común.
Los estados visuales debían explicar, no adornar
Sudoku ofrece un conjunto de estados muy útil para probar lenguaje visual: celda seleccionada, celdas relacionadas, números iguales, candidatos, valores dados, entradas del jugador, conflicto y finalización. Cada estado compite por canales limitados: color, borde, peso, fondo, iconografía, animación. Si todos intentan llamar la atención a la vez, el tablero se vuelve más difícil de leer.
El laboratorio nos enseñó a preguntar qué información merece persistir y cuál puede aparecer solo cuando es relevante. Una selección necesita ser clara. Las relaciones pueden ser más suaves. Un error debe ser reconocible sin depender únicamente del rojo. Una pista dada necesita distinguirse de una entrada editable. Los candidatos deben caber sin convertirse en una textura ilegible.
Este trabajo fue más importante que elegir una paleta concreta. La paleta puede cambiar. La semántica de los estados debería mantenerse. Separar ambas cosas hizo posible avanzar después con tema claro y oscuro sin redefinir el significado de cada interacción.
El modo notas hizo visible la diferencia entre estado del juego y estado de interacción
Los candidatos son una función muy característica del Sudoku y, precisamente por eso, enseñan una lección general. Cambiar entre introducir un número definitivo y anotar posibilidades no modifica las reglas del puzzle; modifica la intención de la interacción. La interfaz necesita expresar ese modo con claridad para evitar errores silenciosos.
Este tipo de estado no pertenece del todo al tablero ni del todo a la navegación. Vive en la frontera. Si el motor conoce la idea de candidato pero el shell gestiona la herramienta, ambos necesitan un contrato comprensible. Esa observación ayudó a diseñar puntos de extensión en lugar de llenar el sistema de condiciones específicas.
Otros juegos tienen equivalentes distintos: marcar o sombrear, elegir una herramienta de línea, alternar entre afirmación y descarte. No son la misma función, pero comparten el patrón de «modo de interacción». El laboratorio nos dio un ejemplo suficientemente concreto para nombrar ese patrón y luego reconocerlo en otras mecánicas.
El teclado no debía ser una versión secundaria del ratón
Sudoku se presta muy bien a navegación por teclado. Las flechas pueden mover la selección, los números introducir valores y teclas auxiliares activar acciones. Pero una experiencia accesible no aparece simplemente añadiendo eventos de teclado. Hay que definir foco, orden, feedback y coherencia con lo que ocurre al tocar o hacer clic.
Trabajar estos detalles en un juego familiar hizo visibles inconsistencias que de otro modo podrían parecer menores. ¿Qué ocurre si la selección visual y el foco DOM se separan? ¿Una celda dada se puede enfocar aunque no sea editable? ¿Cómo se anuncia un conflicto? ¿Deshacer devuelve también el foco a un lugar razonable? Las respuestas forman parte de la experiencia, no de una capa de compatibilidad opcional.
Una vez resueltas como patrón, estas decisiones pueden elevar otros juegos. No todos usarán flechas del mismo modo, pero el sistema puede garantizar foco visible, estados semánticos, acciones alcanzables y una estructura predecible. El laboratorio convirtió accesibilidad en una responsabilidad de diseño temprano.
El móvil demostró que responsive significa reorganizar, no encoger
Una cuadrícula 9×9 tiene una ventaja: conocemos bien su proporción. Eso hizo muy evidente cuándo el problema no era el tablero, sino todo lo que lo rodeaba. En una pantalla estrecha, conservar el layout de escritorio y reducirlo proporcionalmente produce texto pequeño, controles densos y una superficie de juego frustrante.
La respuesta fue permitir que la jerarquía cambie. La configuración puede plegarse. Las acciones pueden moverse. El contenido de explicación puede caer más abajo. Los márgenes deben comprimirse de manera distinta a los objetivos táctiles. El tablero puede ocupar casi todo el ancho disponible sin que eso signifique que la página pierda estructura.
Ese aprendizaje es especialmente relevante para la estrategia móvil posterior. Cuando evaluamos llevar la web a Android mediante Capacitor, una conclusión era inevitable: empaquetar la misma web solo tiene sentido si la base táctil ya es buena. Lo contamos en el artículo sobre el camino de la web a Android. Sudoku fue uno de los lugares donde esa base empezó a demostrar si era real.
El onboarding debía responder a la primera acción, no recitar todas las reglas
Sudoku también sirvió para cuestionar cómo enseñábamos. Es fácil escribir una sección de reglas completa y asumir que el problema está resuelto. Pero una persona que abre un juego necesita primero saber qué hacer ahora: qué puede tocar, cómo introduce una respuesta, qué significan los estados y dónde puede pedir ayuda. El orden pedagógico no coincide necesariamente con el orden lógico de una documentación.
En Sudoku pudimos probar un onboarding más cercano a la interacción: señalar el objetivo, mostrar una selección, introducir un valor, explicar notas y ofrecer salida rápida hacia una explicación más completa. La familiaridad del puzzle hacía más fácil observar si el tutorial ayudaba o simplemente interrumpía.
Más adelante este trabajo se generalizó en perfiles de onboarding para distintas familias. La idea central se mantuvo: compartir el contenedor y la estructura, pero adaptar la escena a la mecánica. Un buen sistema enseña el producto una vez y el puzzle cada vez que hace falta.
La victoria necesita cerrar la sesión sin romper la concentración
Otro estado revelador es el final. Detectar que un Sudoku está resuelto es sencillo comparado con diseñar qué ocurre después. Una celebración demasiado intrusiva puede sentirse fuera de tono. Una señal demasiado discreta puede dejar dudas. Además, el final debe coordinar estadísticas, persistencia, posibilidad de revisar el tablero y acceso a una nueva partida.
El laboratorio nos obligó a pensar la victoria como estado de producto, no solo como booleano del motor. El motor puede decir «resuelto». El shell decide cómo cambia la experiencia. Esa frontera se repite en casi todos los puzzles y evita que cada uno invente un modal distinto, un sonido diferente o una ruta de salida incompatible.
También aparece aquí una lección sobre datos. Registrar una resolución necesita conocer variante, dificultad o tamaño cuando esos conceptos importan. El UI no debería fabricar esa información; el motor y los metadatos deben exponerla. Un estado visual aparentemente sencillo conecta varias capas del sistema.
Usar un caso conocido redujo el riesgo de abstraer demasiado pronto
Una de las ventajas menos obvias de empezar por Sudoku fue que no necesitábamos demostrar que la mecánica merecía existir. Podíamos gastar atención en el sistema. Eso permitió probar ideas con suficiente profundidad antes de convertirlas en contratos compartidos.
Si hubiéramos diseñado el shell a partir de una lista teórica de setenta juegos, probablemente habríamos creado una abstracción llena de opciones por miedo a dejar algo fuera. El laboratorio nos dio el enfoque contrario: el mínimo conjunto que resuelve un caso real muy bien, seguido de pruebas en casos deliberadamente diferentes.
Cuando una pieza fallaba fuera de Sudoku, no intentábamos siempre salvarla. A veces la conclusión correcta era que pertenecía al juego y no al sistema. Esa capacidad de retroceder mantiene el producto más simple y deja espacio a la diversidad.
La taxonomía visual apareció después, no antes
Una vez estabilizada la estructura básica, empezamos a experimentar con color de categoría y continuidad visual entre catálogo y partida. Hacerlo después fue importante. Si la identidad temática hubiera llegado antes de resolver selección, contraste y estados, habría ocupado canales visuales que el juego necesitaba.
Sudoku mostró una forma prudente de usar esos acentos: el marco puede recordar la categoría, pero el tablero conserva sus propias prioridades. Esta regla se volvió todavía más importante en puzzles donde el color ya codifica regiones, relaciones o piezas.
El resultado es una identidad que acompaña sin invadir. La marca y la categoría ayudan a reconocer dónde estás; la lógica del juego decide cómo debe leerse el espacio donde razonas.
El laboratorio también reveló deuda que no era visible como bug
Cuanto más pulíamos Sudoku, más claras se volvían las diferencias con otras páginas. Un control bien colocado hacía evidente otro que estaba lejos. Una jerarquía limpia hacía que un layout antiguo pareciera saturado. Un estado de foco correcto revelaba ausencias en otros motores. Esa comparación fue una de las razones para detener temporalmente la expansión y realizar una auditoría más amplia.
El proceso está desarrollado en nuestro artículo sobre auditar antes de seguir construyendo. La idea importante es que un buen laboratorio no solo produce una solución; produce una referencia. Esa referencia permite detectar deuda de producto que no genera errores automáticos pero sí fricción real.
El riesgo, por supuesto, era usar Sudoku como juez absoluto. Por eso la referencia debía expresar principios —claridad, proximidad, jerarquía, feedback— y no copiar medidas o componentes exactos. La auditoría preguntaba si otro juego resolvía la misma necesidad, no si tenía el mismo aspecto.
Del laboratorio al sistema compartido
Después de varias iteraciones, algunas decisiones dejaron de ser hipótesis y empezaron a repetirse con éxito: un game shell, controles con estados coherentes, layout capaz de dar espacio al tablero, mecanismos de ayuda, soporte de temas, patrones de foco y lugares de extensión para herramientas específicas. Ese conjunto se convirtió en el sistema descrito en «Cómo diseñar una UI compartida para puzzles que no se parecen entre sí».
La relación entre ambos artículos es importante. El laboratorio explica de dónde salen las reglas. El sistema explica cómo se mantienen cuando ya existen muchas mecánicas. Separar esos momentos ayuda a no confundir diseño de producto con construcción de componentes. Primero hay que aprender qué merece repetirse. Después hay que construir la infraestructura para repetirlo bien.
Lo que no trasladamos fue tan importante como lo que sí
Sudoku tiene patrones que no deben generalizarse. La cuadrícula regular, el keypad numérico, los candidatos, las relaciones fila-columna-caja y ciertas formas de resaltado son parte de su identidad. Intentar que un puzzle de caminos, un tablero de conexiones o un juego competitivo adopte esos patrones por consistencia sería una mala decisión.
El laboratorio nos enseñó, por tanto, a documentar límites. Un sistema sano no solo dice «esto se comparte». También dice «esto pertenece al motor». Esa claridad reduce la tentación de añadir opciones genéricas para casos que deberían resolverse localmente.
Paradójicamente, proteger las diferencias hace que la plataforma se sienta más coherente. Cuando el marco común deja respirar a la mecánica, el usuario puede confiar en lo familiar sin perder aquello que hace interesante cambiar de juego.
La métrica útil era cuánto trabajo evitaba el segundo juego
Una interfaz de Sudoku muy pulida podía seguir siendo un callejón sin salida si cada mejora debía rehacerse en todos los demás títulos. Por eso empezamos a valorar las decisiones por su capacidad de propagación. ¿Una mejora de foco beneficia a otros juegos? ¿Un cambio de layout se puede aplicar desde el shell? ¿El onboarding comparte infraestructura? ¿Los estados de error tienen semántica común?
La velocidad aquí no significa implementar una pantalla más rápido. Significa aumentar la calidad base que recibe el siguiente juego. Ese efecto compuesto es una de las razones por las que un sistema de UI merece inversión incluso cuando no añade ninguna mecánica nueva.
La misma lógica se aplica a correcciones. Si arreglar un problema de accesibilidad en una capa común mejora varias experiencias, la arquitectura está trabajando a favor del producto. Si obliga a abrir docenas de archivos, todavía hay una frontera que revisar.
Un buen laboratorio termina cuando deja de ser especial
Al principio Sudoku recibió atención excepcional porque necesitábamos aprender. El objetivo no era mantenerlo para siempre como una pantalla privilegiada. Era conseguir que los aprendizajes salieran de allí y elevaran el estándar del resto. Cuando eso ocurre, el laboratorio cumple su función: deja de ser una excepción y se convierte en origen de capacidades comunes.
Hoy Blupoli Puzzles ha evolucionado mucho desde aquel Blupoli de septiembre de 2026. El nombre cambió, el sistema editorial cambió y el producto incorporó más capas. Sin embargo, seguimos utilizando la misma secuencia cuando aparece un problema amplio: elegir un caso representativo, resolverlo con profundidad, observar qué principios emergen, probarlos fuera y solo entonces convertirlos en infraestructura.
La estrategia evita dos extremos. No obliga a rediseñar todo el catálogo de golpe, y tampoco deja que cada pantalla evolucione en aislamiento. Hace algo más sostenible: aprende en pequeño para mejorar en grande. Sudoku fue una elección especialmente buena porque su mecánica conocida dejó a la vista lo que queríamos estudiar de verdad. El protagonista del experimento nunca fue la cuadrícula. Fue la plataforma que estábamos intentando construir alrededor.