Foris · Design Leadership · TransversalDesign SystemAIGobernanza

El sistema que sostiene
cinco productos —
y ya no los frena.

Avocado es el sistema de diseño de Foris. Lo que parecía un proyecto de componentes se convirtió en un cambio de cómo el equipo trabaja: documentación automática, gobernanza real y un handoff que los desarrolladores no tienen que interpretar.

Mi rol
Design System Lead
Empresa
Foris
Alcance
5 productos · equipo completo
Tipo
Proyecto transversal
~40%
menos tiempo de handoff a desarrollo con documentación automática
0
componentes duplicados desde la implementación de gobernanza
5
productos de Foris corriendo sobre el mismo sistema coherente
El contexto

Un sistema de diseño
que nadie seguía igual.

Foris tiene cinco productos. Cada uno diseñado en momentos distintos, por equipos distintos, con criterios que nadie había escrito formalmente. El resultado era predecible: botones con cuatro variantes distintas del mismo estado, componentes duplicados con nombres diferentes, y desarrolladores que recibían pantallas y tenían que adivinar el resto.

Avocado existía como librería. Pero una librería sin proceso no es un sistema, es una colección de archivos que cada uno interpreta a su manera. El problema no era de componentes. Era de criterio compartido.

El problema real

El DS no frena al equipo.
Lo frenaba la falta de proceso.

Cada vez que un designer necesitaba un componente nuevo, lo creaba. Sin revisión, sin validación, sin documentación. En seis meses el sistema tenía capas de deuda que nadie quería tocar. Y cuando llegaba un desarrollador, encontraba un Figma con notas incompletas y tenía que preguntar.

La decisión de enfoque
Podíamos reconstruir Avocado desde cero, nuevo naming, nueva estructura, nuevo todo. Eso hubiera tomado meses y roto la continuidad de cinco productos en desarrollo. La decisión fue diferente: instalar proceso sobre lo que ya existía. Limpiar, documentar y gobernar, en ese orden.

Decisión de diseño

Documentación automática —
los componentes se explican solos.

El problema de la documentación en cualquier design system es siempre el mismo: nadie la mantiene actualizada porque es trabajo extra. La solución que implementamos fue integrar AI en el proceso de creación de componentes para que la documentación se genere en el momento, no después.

Cada nuevo componente pasa por un flujo que extrae automáticamente sus propiedades, variantes, estados y casos de uso. El output es un archivo MD estructurado que vive junto al componente y que el desarrollador puede consumir sin abrir Figma.

Por qué esto cambió la adopción
Cuando la documentación existe y está actualizada, los desarrolladores confían en el sistema. Cuando no existe, construyen sus propias interpretaciones. La adopción del DS no era un problema de calidad de componentes, era un problema de confianza en la información.
Imagen · flujo de documentación automática

Del componente en Figma al archivo MD, sin intervención manual del designer

Decisión de diseño

Gobernanza —
ningún componente entra solo.

Antes de la gobernanza, cualquier designer podía agregar un componente al sistema. Eso generaba el caos que encontramos. La decisión fue instalar un proceso de propuesta, revisión y aprobación antes de que cualquier componente entre a Avocado.

01
Propuesta
El designer identifica la necesidad y propone el componente con contexto de uso, casos edge y criterio de reutilización. Si ya existe algo parecido, la propuesta lo justifica.
02
Revisión
El design lead revisa coherencia con el sistema existente, naming y si aplica a más de un producto. Si no aplica a dos o más productos, no entra al DS, vive como componente local.
03
Aprobación y documentación
El componente se documenta automáticamente, se agrega al sistema y se notifica al equipo. Ningún componente vive en el DS sin documentación completa.
"La gobernanza no frena al equipo. Le da certeza de que lo que usa hoy va a seguir funcionando mañana."
Decisión de diseño

Handoff con código —
el desarrollador no tiene que adivinar.

El handoff tradicional es una pantalla de Figma con anotaciones. El desarrollador la abre, interpreta espaciados, infiere comportamientos y pregunta. Con Avocado, cada componente entrega un archivo MD con especificaciones exactas y snippets de código listos para implementar.

La librería de AI dentro de Avocado tiene un sistema de tokens que mapea directamente a las variables del código. El desarrollador no traduce, implementa.

El impacto en velocidad de entrega
Antes del nuevo handoff, cada componente generaba entre 2 y 4 preguntas al designer durante la implementación. Después, las preguntas cayeron casi a cero. El ~40% de reducción en tiempo de handoff vino de eliminar el ciclo pregunta-respuesta, no de hacer el proceso más rápido.

El resultado

Un sistema que el equipo
realmente usa.

La diferencia entre Avocado antes y después no es visual, es de comportamiento del equipo. Los designers proponen antes de crear. Los desarrolladores implementan sin preguntar. Y los cinco productos de Foris comparten el mismo lenguaje visual sin que nadie tenga que coordinarlo manualmente.

Un design system no vale por la calidad de sus componentes. Vale por la calidad del proceso que lo sostiene.

Lo que me llevé
Liderar un DS me enseñó que el mayor problema no es técnico, es de adopción. Y la adopción no se logra con mejores componentes. Se logra cuando el proceso le hace la vida más fácil a quien lo usa, no más compleja.
Más casos
Línea A · Foris
Automatización de casos de uso
AI workflow · Process design · Claude
Línea B · Starlight Labs
Starlight AI
AI system · Fintech · 80% más rápido