Un sistema de diseño sin componentes
El contexto
Entré como Design Lead en una empresa edtech que cuenta con una plataforma educativa que cubre el sistema editorial al completo: editores, escuelas, estudiantes y docentes.
La arquitectura de productos
El producto se vendía como marca blanca y funcionalidades a medida de cada cliente. Ambas personalizaciones se soportaban mediante “flags”, acumulando en cada despliegue más deuda y dificultades de mantenimiento.
Planteamiento de un diseño escalable
Para frenar la deuda técnica y hacer viable el white-labeling, mi primera idea fue crear un DS estructurado en variables semánticas y modos, pero la carga de trabajo hacía que cualquier elemento quedara rápidamente obsoleto. El DS siempre iba detrás de producción. Por eso, decidí que el sistema de diseño iba a ser solo reglas de color en su primera versión.
Cada nuevo tenant esperaba que el producto se sintiese “suyo” según introducía los colores de su marca. No era así y había conflictos de accesibilidad. En service desk, el porcentaje de tickets por esta causa rondaba el 25-30% del total.
El branding que traían los clientes estaba pensado para gráfico. Faltaban colores que sirviesen para los estados interactivos y en ocasiones los primarios no eran válidos para cumplir los ratios de contraste AA que necesitábamos en la plataforma. Es decir, cuando los utilizábamos para las acciones principales, ni el texto negro ni el texto blanco se podían leer con claridad suficiente.
Y esto no era exclusivo de clientes, comprobé que nuestra marca presentaba el mismo problema, pero era tan habitual customizarla que se había pasado por alto. Si quería plantear un sistema de reglas, tenía que empezar por arreglar nuestra propia marca y no era únicamente una evolución de branding.
Bifurcación del color primary
Dupliqué nuestro color primario en:
Una variable primary: Evolucioné el color principal a uno con contraste AA con blanco. De él desarrollé una rampa completa (del 50 al 900).
Una variable primary-decorative: Mantuve el color original para los elementos decorativos no interactivos. Me sirvió para dar personalidad a la plataforma, y que siguiera percibiéndose como “la de siempre” (útil para las demos, el propio equipo y los clientes que usaban el plan básico que no permitía personalizar).
Con este planteamiento conseguí no forzar la presencia de un color ligeramente distinto y a la vez no comprometer ni la usabilidad ni la accesibilidad.
Los neutros también los segmenté. Por un lado, neutros de “plataforma” y por otro neutros “de marca” que adquirían un ligero matiz del tono principal o secundario seleccionado.
Elección del modelo de color LCH y relación de variables
Para que la paleta de cliente se pudiera customizar sin casi intervención humana, necesitaba usar un modelo de color matemáticamente predecible y opté por el LCH (Lightness, Chroma, Hue) que me permitió definir umbrales y generar alternativas controladas. El rango 42-56 lo decidí para evitar valores con luminosidad media que no contrastan con un mínimo AA con blanco/negro.
Según el resultado del color inicial, la variable de text-default (que es la que contrastaría en las acciones principales con el color primary) se alimentaba de una primitiva dark o light. El mismo patrón usaba para contrastes entre surfaces y borders, por ejemplo.
Esta y otras reglas las documenté en una hoja de cálculo, con la idea de que fuera accionable tanto en manual como usando herramientas IA tipo Claude. Mi propuesta es que un sistema en su mínima expresión son relaciones lógicas y aunque se manifieste en herramientas de diseño, no necesariamente tiene que vivir ahí.
Impacto en el equipo
En un primer momento este trabajo se percibió como una “pérdida de tiempo”, pero finalmente estas reglas lograron que los tickets relacionados con accesibilidad y color dejaran de ser un problema recurrente, el setup de editoriales se simplificó y logró que el equipo de desarrollo recuperara tiempo para resolver deuda técnica.