1. Mirar todo junto y registrar lo que encontramos
Con mi lead recorrimos los flujos y pantallas de los cuatro productos, y fuimos registrando en una planilla lo que había que arreglar y lo que no coincidía entre uno y otro.
A esa primera lectura le sumamos una auditoría mucho más extensa, hecha con Claude: componentes, duplicados, contrastes. Haber hecho la nuestra primero nos dio un criterio propio para evaluar si lo que la IA devolvía tenía sentido.
Ese cruce fue también un punto de inflexión para nosotras. Veníamos de mirar la IA con desconfianza, casi como una competencia. Ahí entendimos que el lugar que nos correspondía era otro: el de aportar criterio y marcar dirección, y dejar que la IA hiciera el trabajo mecánico de auditar cientos de pantallas que a mano nos hubiera llevado semanas.
2. Definir las bases antes de tocar un componente
Antes de diseñar un solo botón, acordamos sobre qué principios se iba a apoyar el sistema. Para mí este paso es central en cualquier proyecto, no solo en este: sin orden y una base firme, un sistema se desordena sin que nadie lo note hasta que cuesta demasiado corregirlo. Esos principios son seis, y cada uno responde a un riesgo puntual de trabajar sobre cuatro productos en simultáneo:
- Coherencia: que el mismo patrón resuelva siempre lo mismo, para que los productos se lean como una familia y no como aplicaciones sueltas
- Accesibilidad: pensada desde el diseño, no como una revisión de último momento
- Escalabilidad: que el sistema pueda sumar productos, componentes o tokens sin reescribir lo que ya funciona
- Consistencia entre productos: distinguir con claridad qué es identidad de cada producto y qué debe ser igual en los cuatro
- Jerarquía visual: que la interfaz guíe la mirada en pantallas con mucha información, como tablas y filtros
- Feedback y estados: que el sistema comunique siempre en qué estado está, sin dejar huecos que se noten recién en producción
Definir esto antes nos sirvió para decidir qué priorizar y qué dejar para más adelante. También documentamos estilos y estructuras base, para que cualquier pantalla nueva partiera del mismo lugar.
De ahí salió, además, una regla que sostenemos con firmeza: cuando el valor de un producto no entra en la escala del sistema, se ajusta el producto y no se inventa un valor a medida para acomodarlo. Hacerlo de la otra forma habría significado que, tarde o temprano, cada producto termine con su propia escala, que es justamente lo que queríamos evitar.
3. Tokens: lo que traía del proyecto anterior, ampliado
Retomé el sistema de tokens que había armado en el proyecto anterior. Mantuve lo que ya funcionaba bien —los dos niveles, valores base y uso semántico— y, con lo que había aprendido en el camino, propuse mejoras y amplié bastante el sistema:
- Más familias de tokens: color, tipografía, radios, espaciado, sombras, movimiento, tamaños, estados y accesibilidad
- Nombres más claros y consistentes entre sí
- Un tema por producto, en lugar de un tema por cliente
También documenté reglas propias para crear un token nuevo, decidir dónde aplicarlo y cómo nombrarlo, algo que antes se resolvía caso por caso. Con esas reglas escritas, la decisión ya no depende de quién la tome ese día.
