Retto
Siete sistemas de diseño fragmentados convertidos en una sola fuente de verdad.
- Rol
- Líder de diseño del sistema
- Equipo
- 3 diseñadores · 3 devs · 1 PO
- Duración
- ~6 meses efectivos
- Plataforma
- Web Components · Figma
- Estado
- v1.0.0 · en producción
Resultado
Del lado de diseño la adopción fue total: los tres diseñadores participábamos en los seis productos y todos trabajábamos sobre el sistema, desde la especificación hasta el acompañamiento al desarrollo. Fuera de los productos activos también lo adoptaron proyectos independientes, como el CMS de páginas web generadas internamente.
Métricas objetivo
Las métricas de negocio que el sistema buscaba mover, y debajo de cada una el valor que tendría moverla.
Tiempo de construir un producto nuevo
Cada semana que un producto tarda en salir es una semana sin facturar. El sistema existe para que montar pantallas deje de ser la parte lenta.
Coste de aplicar una marca nueva
Con el whitelabel, venderle el mismo producto a otro cliente deja de ser un proyecto de diseño y pasa a ser una configuración.
Coste de arrancar cada proyecto
La empresa creaba productos de forma constante, y cada uno arrancaba resolviendo desde cero las mismas preguntas ya resueltas cuatro veces.
Siete sistemas de diseño, y ninguno por descuido.
Conectera llegó a mantener siete sistemas de diseño distintos. Partíamos de que cada producto merecía el suyo, así que cada vez que entrábamos a uno nuevo le construíamos uno propio. El modelo se rompió solo, y fue la evidencia la que nos hizo cambiar de opinión.
Yo había participado en cinco de esos siete, en unos con más contribución que en otros. Dicho de otro modo: buena parte de lo que había que desmontar lo había construido yo. Varios nunca llegaron a desarrollo, porque el producto se detuvo o porque no había tiempo de mantenerlos actualizados. Y como la empresa creaba productos de forma constante, cada nuevo proyecto arrancaba resolviendo desde cero las mismas preguntas ya resueltas cuatro veces. Las inconsistencias visuales se discutían caso por caso, en cada módulo, cada vez.
Había un segundo problema, menos evidente. Los primeros sistemas nacieron como adaptaciones de Material Design. Funcionaban, pero el portafolio entero de la empresa terminaba pareciéndose a Google en lugar de parecerse a sí mismo.
La conclusión: hacía falta una sola fuente de verdad, whitelabel, que alimentara a todos los productos cambiando marca y tipografía en vez de reconstruir el sistema, y con un lenguaje propio.
Líder de diseño, con las manos dentro del sistema.
Trabajamos como equipo de producto porque el sistema se gestionó como un producto, no como un entregable paralelo.
- · Dirigí la fase de diseño y repartí los componentes entre el equipo, coordinando a 2 diseñadores.
- · Diseñé y documenté componentes directamente, no solo coordiné.
- · Definí la dirección visual de varios componentes y propuse las plantillas de creación, edición y trazabilidad que viven en Figma.
- · Propuse la arquitectura de tokens: el enfoque whitelabel y el esquema de dos capas.
- · Compilé y ajusté la gobernanza a partir de lo que el equipo formuló.
Lo que no fue mío: el código de los componentes lo escribieron los desarrolladores a partir de nuestras especificaciones. Desde diseño revisábamos el funcionamiento visual de cada uno y entregábamos la plantilla de cómo debía presentarse. El proyecto tampoco nació como encargo: empezamos con un producto y, mientras diseñábamos, se hizo evidente que teníamos conocimiento repartido en siete sistemas muertos que valía la pena juntar en uno vivo.
Auditar antes de construir.
Auditamos los siete sistemas anteriores para ver qué habíamos propuesto y qué sobrevivía. En paralelo recorrimos los productos a los que queríamos dirigir el sistema, para saber qué componentes íbamos a necesitar de verdad y qué funcionalidades debía cubrir cada uno.
Atomic design lo traje yo a la empresa: no se usaba, lo propuse con el argumento de por qué encajaba aquí y por eso lo adoptamos. Empezamos por las piezas base (el botón, los inputs, el tooltip) porque son las que después componen moléculas y organismos. Ese orden no fue estético: sin las bases resueltas, cada componente compuesto habría vuelto a discutir decisiones ya tomadas.
La adopción, que suele ser la parte difícil, aquí no lo fue tanto. El concepto de sistema de diseño ya estaba arraigado en la empresa, así que desarrollo y el PM entendían de entrada la promesa de ahorrar tiempo. Y como la iniciativa nació desde diseño, dentro del equipo fue obligatoria: toda pantalla diseñada en Figma tenía que fundamentarse en el sistema. Lo que terminó de convencer al resto fue la evidencia: a medida que los desarrolladores lo implementaban, montar pantallas se volvía trivial y podían concentrarse en el backend y la lógica.
Tokenización en dos capas, a propósito.
Propuse el enfoque whitelabel y estructuré los tokens en dos capas (primitiva y semántica) en lugar de un esquema más granular. Lo que descarté: una arquitectura más completa, con una capa adicional a nivel de componente.
Yo venía estudiando tokenización por mi cuenta y el resto del equipo no estaba en ese tema. Dos capas era lo máximo que se podía entender e implementar bien desde el primer día, así que preferí una arquitectura que el equipo usara correctamente sobre una técnicamente superior aplicada a medias. La tercera capa no se descartó en una discusión: nadie la planteó, y ahí está lo que hoy añadiría.
Lo que anticipé: que íbamos a necesitar aplicar el sistema a más productos de los que existían entonces. Por eso el whitelabel no fue un requisito recibido sino una propuesta. Si la meta era mantener un solo sistema para todo, la marca tenía que ser una variable, no una reescritura.
Accesibilidad como línea base, no como revisión.
Acoté el alcance en vez de anunciar «accesibilidad» a secas. Quien usa estos productos son perfiles administrativos que pasan la jornada entera dentro de la herramienta, así que el esfuerzo fue a lo que les rinde: las pautas visuales —contraste conforme a WCAG 2.1 y 2.2, jerarquía y densidad— y la navegación por teclado de cada componente, documentada tecla por tecla. No fue un requisito impuesto por nadie: salió del equipo de diseño.
La lógica es sencilla: si la accesibilidad va dentro del componente, un equipo que usa Retto la hereda sin saber de accesibilidad. Si queda en una checklist posterior, depende de que alguien se acuerde, y tarde o temprano nadie se acuerda. Es probablemente el mayor efecto multiplicador del sistema: una decisión tomada una vez y aplicada en todos los productos que lo consumen.
El botón, documentado hasta el último píxel.
Cada componente se documenta con su anatomía, sus estados, sus variantes y las reglas de uso de cada jerarquía. El botón es el ejemplo más denso porque es la pieza base: ocho anatomías, siete estados y tres jerarquías con criterio de cuándo usar cada una.
La gobernanza necesita tiempo protegido, no solo un documento.
Estudiamos cómo otras empresas resolvían la gobernanza de sus sistemas y propusimos un modelo propio: principios, políticas, modelo de equipo con roles, flujos de revisión, estándares y métricas de adopción, junto con las prácticas de entrega de especificaciones desde diseño. Yo compilé y ajusté lo que el equipo formuló.
La gobernanza quedó escrita y no llegó a operar.
Habíamos negociado una franja semanal dedicada al sistema, y la operación diaria se la fue comiendo. La salida de uno de los desarrolladores que estaba al frente dejó además un vacío que no habíamos previsto. Los principios, los flujos de revisión y los estándares siguieron existiendo en el documento, pero dejaron de cumplirse.
Debajo había una contradicción que tardé en ver. El sistema se concibió como un producto vivo, que se actualiza mientras se usa, y a la vez se esperaba «terminarlo» para poder implementarlo. Las dos ideas no caben juntas: mientras un sistema de diseño se entienda como algo que se acaba, la franja semanal siempre parecerá prescindible.
La consecuencia fue concreta: aparecieron roces en el equipo por componentes que unos consideraban no optimizados, sin un estándar vigente al cual apelar. Eso no fue un problema de las personas. Es lo que ocurre cuando un sistema tiene reglas escritas y nadie tiene asignado hacerlas cumplir. La gobernanza es una rutina con dueño y con tiempo protegido.
Documentar el comportamiento, no solo el estado final.
Un componente no se define por cómo se ve en el ancho ideal, sino por qué hace cuando deja de caber. Cada componente lleva documentadas sus reglas de desbordamiento, de reordenamiento y de colapso, con el caso móvil resuelto explícitamente.
41 componentes con su documentación viva.
Cada uno con guías de uso, consideraciones de accesibilidad y comportamiento responsive documentados.
La documentación real está en un sitio interno dedicado, con especificaciones, ejemplos de código y la librería de componentes. Figma cumple otra función: es donde se diseña, y donde están las plantillas de creación, edición y trazabilidad que aceleran la escritura de especificaciones. No es una copia de ese sitio, es la herramienta de trabajo del equipo de diseño.
Lo que este sistema me enseñó a decidir antes.
Un sistema se distribuye como paquete versionado.
Retto se implementó copiando la carpeta del sistema dentro de cada proyecto. Sin un paquete versionado, una corrección no se propagaba: había que replicarla producto por producto. Lo supimos y no lo peleamos, porque desde diseño no quisimos interferir en cómo trabajaba desarrollo. Hoy la distribución entra en la definición del sistema desde el primer día: es una decisión de arquitectura de producto, y le corresponde a quien responde por ese producto.
Las capas de tokens necesitan un momento pactado para crecer.
Quedarnos en dos capas (primitiva y semántica) fue lo correcto para arrancar. Lo que hoy añado a esa decisión es el disparador: qué señal concreta —cuántos componentes, cuánta variación entre productos— indica que toca abrir la tercera capa, la de componente, que da bastante más control sobre el sistema.
El modo oscuro se decide al definir la rampa.
La rampa se definió pensando solo en el modo claro, y un modo oscuro no se añade después sin rehacerla entera. Hoy no doy una rampa por cerrada hasta verla funcionar en los dos modos: preverlo al principio cuesta una tarde y corregirlo después cuesta el sistema completo.
Una decisión de stack acertada también necesita fecha de revisión.
El sistema se construyó en Web Components por dos razones que iban juntas: casi todos los productos eran de legado y ya estaban en ese lenguaje, y era el stack que desarrollo dominaba. Cualquier otra elección habría metido fricción justo donde el sistema tenía que entrar sin ella. Fue lo correcto para ese momento y volvería a elegirlo. Lo que añado ahora es el acuerdo explícito de en qué punto se revisa, para que un cambio como el que Retto está haciendo hoy hacia React sea un paso previsto y no una urgencia.
La lección más transferible del proyecto: aprendí a negociar con desarrollo con datos. No basta con «hagamos esto porque nos ayuda a mejorar»; hay que explicar el cómo y, siempre que se pueda, llevar el número. Las limitaciones técnicas de los desarrolladores son restricciones de diseño, y tratarlas como obstáculos en vez de como insumos es la forma más rápida de perder una discusión que tenías ganada.
Retto es un sistema interno, así que comparto documentación y foundations, pero no los productos donde está implementado. Puedo mostrar el sistema completo y su aplicación en una conversación.