DESARROLLO Y DISEÑO
Ideación, dirección de producto, diseño UX/UI y sistema de diseño en Figma, desarrollo front-end con Claude Code. App web que genera escalas tonales de color con el mismo contraste en cada paso: de un color de marca, que se conserva exacto, a escalas de 3 a 30 pasos con neutros y paletas semánticas, exportadas a Figma (DTCG), CSS y Tailwind.
Figma, DTCG, Terrazzo, Tailwind CSS, Vite, React, TypeScript, Node.js, Vercel, Claude Code
Al crear las escalas de color de una marca, las herramientas obligan a elegir. Tailwind CSS ofrece paletas probadas de 11 pasos, pero el mismo paso no tiene el mismo contraste en todos los colores. Leonardo iguala el contraste, pero con su espacio por defecto el color de marca no queda en ningún paso y el tono se desplaza. Scale conserva la marca, pero al mezclar en sRGB el tono también se desplaza. El diseñador acaba comprobando el contraste paso a paso, escala por escala.
El problema lo encontré en mi propio curso. DesignToken101 incluía una herramienta, “Generar escalas”, que partía de un color de marca y seguía las curvas de Tailwind CSS: 11 pasos fijos, nombres de Tailwind y el color de marca exacto en su paso. Servía para enseñar, pero un sistema real necesita otro número de pasos o los nombres que ya usa, y el mismo paso no daba el mismo contraste: el 500 iba de 1,88 a 4,22 con blanco según el color. Antes de escribir código, la comparamos con Leonardo y Scale sobre 13 colores y 39 escalas por herramienta, y ninguna conservaba a la vez la marca, su tono y el mismo contraste en cada paso. Ahí vi la oportunidad: una app aparte en la que el número del paso signifique lo mismo en todas las escalas. Sin eso, no se puede escribir una regla como “texto sobre blanco, del paso 700 en adelante”, cada combinación se comprueba a mano y cambiar un color por otro del mismo paso puede romper la accesibilidad.
Un proceso en tres fases que avanzan en orden: qué se quiere y con qué método, UX y diseño en Figma, y desarrollo con Claude Code. No se escribió código hasta tener cerradas las dos primeras. Cada paso sigue el mismo ciclo: medir con un script, proponer, decidir y registrar la decisión con fecha; en desarrollo, encargo a Claude Code, pruebas, build y lint, revisores de código, accesibilidad y seguridad, y pull request.
El flujo más crítico era leer el resultado: ver, al escribir un color, qué pasos se pueden usar para texto. Ahí la app podía perder al usuario, porque el método no es el habitual. El nombre del paso es su nivel de contraste, la marca cae en el paso de contraste más cercano y no se puede mover, y ese paso conserva su propio contraste. La solución fue que el resultado lo dijera sin abrir ninguna tabla. Todo se calcula al momento, sin botón, con los ajustes al lado en escritorio. Encima de las tiras, una frase da la regla para el número de pasos elegido, por ejemplo texto sobre blanco del 700 en adelante. Dos filas, White AA y Black AA, la marcan paso a paso en todas las escalas. Un ✓ señala el color de marca, con su contraste aparte. En móvil, donde esas filas no caben, el nombre de cada paso va dentro de su muestra, en negro o en blanco, el que cumpla AA. El usuario sabe qué puede usar antes de exportar.
La primera alternativa fue seguir las curvas de Tailwind CSS tal cual, como la herramienta del curso: la luminosidad de cada paso venía de la paleta y la marca caía en el paso más parecido. La descarté al comprobar qué es lo actual en escalas para sistemas de diseño: el criterio ya no es solo trabajar en OKLCH, sino que el número del paso signifique lo mismo en todas las paletas. Con las curvas de Tailwind, el 500 iba de 1,88 a 4,22 de contraste con blanco según el color. La segunda alternativa fue dejar que el usuario eligiera en qué paso cae su color, como hacen Scale y ColorScale. La descarté porque, con el nuevo método, el nombre del paso es su contraste: mover la marca rompía la promesa. La tercera fue exportar a Figma en OKLCH. La descarté al probarla: Figma no importó esas variables, y en sRGB con hex sí importó las 44. La solución fue que cada paso sea un nivel de contraste, igual en la marca, los neutros y las paletas semánticas, aceptando el coste: los colores muy saturados pierden más croma al ajustarse a sRGB, y la app lo avisa.
La interfaz se construye con un sistema de diseño propio en Figma, ColorScaleUI, casi igual al de DesignToken101, y sus variables llegan al código por el mismo camino que exporta la app: de Figma a DTCG y de DTCG a CSS con Terrazzo. Esa decisión hace que colorgods pase por su propio flujo: el formato que entrega al usuario es el mismo con el que está hecha su interfaz. Las pantallas de Figma fueron la referencia del desarrollo, y lo que no estaba dibujado se resolvió con el documento de UX, respetando su estética.
La interfaz usa un sistema de diseño propio en Figma, ColorScaleUI, y sus variables llegan al código como DTCG y CSS con Terrazzo, el mismo formato que la app exporta. Las pantallas de Figma son la referencia del desarrollo, y lo que no estaba dibujado se resolvió con el documento de UX, respetando su estética. Cada color, espacio y componente de la app pasa por el flujo que colorgods ofrece al usuario.
No hay botón de generar: cada ajuste cambia el resultado mientras se escribe. Si un campo tiene un error, el resultado sigue con el último valor válido y el campo dice cuál es, así la pantalla nunca queda vacía ni desactualizada. La exportación espera mientras haya errores y los lista con un enlace a cada campo. El usuario prueba sin miedo a romper nada.
Todo lo que conviene saber va en una sola lista encima de las tiras: los avisos señalan algo que conviene cambiar y las notas explican algo que se puede notar. Cada uno empieza por el nombre de su escala y lleva un enlace que abre la tabla en el paso del que habla. La app no cambia nada por su cuenta: no toca los nombres personalizados ni el color propio de un rol, solo avisa. El usuario entiende el resultado y decide.
En escritorio, los ajustes van en una columna a la izquierda que se queda fija mientras el resultado se desplaza, para cambiar cualquier valor sin volver arriba. Por debajo de 1024 px, el resultado va primero y los ajustes se abren en un panel desde el botón de menú, que entra deslizándose desde el borde, atrapa el foco y se cierra con Escape. Sin animación si el sistema pide movimiento reducido. Los anuncios para lectores de pantalla se repiten dentro del panel para que no se pierdan con él abierto.
El método no es el habitual, así que “How it works” explica cada parte de la app y por qué una marca cae en un paso o un paso tiene su contraste. Empezó como una sección al final de la app y pasó a una página aparte: el texto era largo, en un panel obligaría a desplazarse dentro de él y la app ya estaba al 99,6 % de su presupuesto de peso. Una página se puede enlazar, la encuentran los buscadores y, al volver, la app recupera los ajustes que tenía el usuario.