Personalización sin pasar por la cola de ingeniería
Un sistema de componentes configurables que da a los operadores espacio para expresar su marca sin tocar la estructura que hay debajo.
Diseñado para un ecosistema existente de más de 10 marcas de operadores · Casino primero
La misión
InPlaySoft es una plataforma de iGaming en la nube para casino, apuestas deportivas y esports, que sirve a un ecosistema de marcas de operadores con más de 1 millón de usuarios activos al mes. Los cambios pequeños de front-end interrumpían a ingeniería una y otra vez y tardaban demasiado para los operadores. Propuse un sistema de componentes configurables y un catálogo que pudiera convertirse en la referencia compartida de cómo funcionan esos componentes. El CEO me dio autonomía para desarrollar la idea, y el sistema todavía está en construcción.
- Rol
- Senior Product Designer
- Origen
- Iniciativa propia · patrocinio del CEO
- Periodo
- 2025–2026
- Estado
- En construcción · Casino primero
- Responsabilidad
- Diseño, sistema y documentación
Una plataforma, muchas expresiones
Cada marca de la plataforma se ve distinta. Personalizar nunca fue el problema. Operarlo, sí.
La plataforma white-label de InPlaySoft sirve a un ecosistema de marcas de operadores: GingaBet, Viva Sorte, ZeroUm, 4Play, 4Win, BandBet, QG.bet, Energia y otras. Cada una tiene una identidad visual distinta sobre una misma arquitectura de producto.
La fricción estaba en cómo se operaba esa flexibilidad. Las peticiones pequeñas de front-end seguían sacando a ingeniería de trabajo más urgente, mientras los operadores esperaban por cambios que deberían haber sido simples. Ya existía un Page Builder, pero era complejo, concentraba demasiada información y requería una formación considerable, así que esas peticiones seguían pasando por ingeniería.
Otro modelo
Dar a los operadores espacio para cambiar lo que expresa su marca, y bloquear lo que sostiene el producto.
Propuse otro modelo operativo: en lugar de pedir cada cambio o aprender un builder pesado, los operadores configurarían componentes dentro de límites definidos. El CEO me dio autonomía total para desarrollar la idea. No fue un encargo de biblioteca de componentes. Empezó como una propuesta.
El modelo es flexibilidad controlada. Los operadores tienen control real sobre la expresión de su marca, mientras las reglas que mantienen un componente estable entre dispositivos y contextos se quedan en el sistema.
Libertad, con límites
Dentro de un Jackpot, seis propiedades de marca pueden cambiar. El tamaño, el espaciado y la estructura responsive se quedan en el sistema.
Los Jackpots se convirtieron en el ejemplo de trabajo para ese límite. Los operadores pueden cambiar imagen, movimiento, bordes, tipografía, colores y variantes. El tamaño, el espaciado, las reglas por viewport y la estructura de base siguen gobernados por el sistema porque determinan cómo el componente se sostiene entre dispositivos.
- Expresión de marca
- Imagen · Movimiento · Bordes · Tipografía · Colores · Variantes
- Definido por el sistema
- Tamaño · Espaciado · Reglas por viewport · Estructura del componente
Diseñar las reglas
Definido primero en Figma, refinado al construirlo.
- 01
Primero la anatomía, en Figma
El sistema empezó en Figma en 2025. Cada componente se definió primero ahí: su estructura y su anatomía, qué partes existen y cómo se relacionan, cuáles puede tocar un operador, y sus variantes, variables, tokens y reglas. Esa arquitectura inicial es de donde viene la lógica del componente.
- 02
Variantes y propiedades expuestas
Las variantes que ofrece un componente, y las propiedades expuestas para él. Los Game Category Banners vienen en tres disposiciones, Split, Grid e Inline, cada una dibujada para escritorio, tablet y móvil. En el Jackpot, las propiedades expuestas son imagen, movimiento, bordes, tipografía y colores. Exponer una propiedad es una decisión. No exponerla, también.
- 03
Comportamiento y movimiento como parte de la especificación
Cómo se mueve y responde un componente está escrito en su definición, no decidido en la implementación: autoplay y loop, drag y swipe, easing, pausas en hover, drag, foco y pestaña oculta, y qué ocurre con movimiento reducido.
- 04
La accesibilidad dentro de la especificación
Los requisitos de accesibilidad forman parte de la especificación de cada componente, no de una revisión aparte: contraste, con objetivos AA donde aplica; consideraciones ARIA; y uso con teclado, comportamiento del foco, contenido anunciado y reglas de movimiento reducido, documentados junto al componente.
- 05
Definido por dispositivo
Cada componente se define y previsualiza para escritorio, tablet y móvil, para que una variante que aguanta en una pantalla de escritorio se compruebe en un teléfono antes de existir en el catálogo.
De la biblioteca al catálogo
El sistema no se queda en Figma.
En 2026 empecé a convertir las definiciones de Figma en un catálogo funcional en la plataforma. La página de cada componente reúne sus variantes, las propiedades y tokens con los que está construido, comportamiento y movimiento, previews por dispositivo, contenido localizado e historial de releases. El catálogo es la referencia compartida de cómo se define un componente y cómo se espera que se comporte.
- Figma Definición del componente: estructura, variables, tokens, reglas.
- Catálogo Referencia compartida y documentación funcional.
- Claude Design Sync Definiciones de los componentes puestas a disposición de desarrollo durante la implementación.
- Desarrollo El equipo de desarrollo implementa los componentes.
- Nuevo Page Builder Capa de entrega a operadores, prevista.
Trabajar con los componentes de forma funcional también devuelve información al sistema, en lugar de convertirlo en una entrega unidireccional desde Figma. Claude Code y Claude Design forman parte de cómo los implemento, inspecciono y refino en ese entorno. A medida que el sistema crecía, ese proceso también hizo más visibles algunas limitaciones, entre ellas la necesidad de introducir tokens Semantic cuando la estructura original de Primitive y Foundation se volvió más difícil de navegar.
Reflexión
Entré en este trabajo pensando en la personalización como un problema operativo: demasiadas peticiones pequeñas, demasiadas pasando por ingeniería. Construir el sistema dejó más clara otra pregunta. No cuánto hacer configurable, sino dónde debe parar la configurabilidad. Cada propiedad que expongo le da más control a un operador, pero también cambia lo que el sistema tiene que resolver entre marcas, dispositivos y contenidos. Acabé dedicando tanto tiempo a decidir qué debía quedar protegido como a decidir qué debía ser configurable.