Todos los proyectos
Un único sistema de diseño, varios equipos
Un sistema de diseño hecho desde cero para tres equipos, cada uno con su producto y sin diferencias.
- Design System Manager
- Sistemas de diseño · IA
- 2025
- Seis o siete diseñadores, entre dos agencias y el cliente
- 11 meses
- Sistema de diseño: librería, tokens y documentación
En resumen
Construí, desde cero, el sistema de diseño de una organización que estaba lanzando varias herramientas de IA a la vez, cuando esas herramientas aún eran wireframes. Once meses después, una sola librería alimentaba seis productos en su lanzamiento y la compartían los diseñadores de dos agencias y del cliente.
- 11
- 6
- 3
- 62
- 616
- 1,3K+
El contexto
Un organismo público quería impulsar el uso de los datos y de la inteligencia artificial entre pymes y autónomos, y el plan era construir varias herramientas independientes, cada una con una función específica. El primer plan hablaba de cuatro o cinco productos; después vendrían más.
Cuando llegué, en febrero de 2025, de esos productos solo había wireframes. No existía un lenguaje visual, ni reglas compartidas, ni sistema de diseño. Existía la idea.
Mi papel, a través de una agencia, era hacerme cargo de ese sistema que aún no existía: construirlo, documentarlo, llevar su backlog y conseguir que diseñadores y desarrolladores fueran al mismo paso. Mientras tanto, otros dos diseñadores de la agencia iban diseñando los primeros productos.
Y había una complicación más: los productos siguientes se encargaron a otras agencias, por lo que el sistema dejaba de ser solo para mi equipo. Tenía que ser la única fuente de verdad para quien llegara después.
El reto
Lo normal es que un sistema de diseño ponga orden en algo que ya existe. Aquí no había nada que ordenar. Los diseñadores necesitaban componentes para pantallas que tenían fecha de entrega, y el lenguaje visual del que dependían esos componentes seguía cambiando.
Donde mejor se vio el coste fue en los botones. Cada cambio de dirección visual dejaba un estilo nuevo en los archivos, hasta juntar cuatro o cinco, algunos ya sin uso, y quien se incorporaba al proyecto no tenía forma de saber cuál iba dónde. Además, las propuestas visuales se quedaban en el aspecto: los estados hover y deshabilitado, el comportamiento y las pantallas pequeñas quedaban sin resolver, y con eso nadie puede programar.
Y cada vez éramos más. Aquello dejó de ser un reto para convertirse en el leitmotiv de mi participación en el proyecto: la librería tenía que entenderla gente que no había estado delante cuando se tomaron las decisiones.
Mi enfoque
El trabajo, por orden:
- Fundamentos
- Componentes base
- Publicar
- Tokens
- Documentación
- Registro de cambios
Y las decisiones que le dieron forma:
Publicar un kit básico antes de cerrar el lenguaje visual
Esperar a los colores definitivos habría dejado a cada diseñador resolviendo por su cuenta los mismos botones y formularios, que es como empieza la fragmentación. Acordé con el equipo publicar pronto componentes utilizables y actualizarlos después. El riesgo era tener que rehacer trabajo. Lo que lo hacía asumible era la propia librería: en cuanto los diseñadores cambiaban sus piezas provisionales por instancias enlazadas, un cambio hecho una sola vez llegaba a todos los archivos.
Primero el componente; sus tokens y su documentación, después
El orden de manual es fundamentos, tokens, componente y documentación. Seguirlo habría dejado a los equipos de producto esperando. Así que, cuando un diseñador necesitaba algo, yo simplemente lo construía y lo publicaba... y ya después lo tokenizaba y lo documentaba. Un backlog abierto a todos enseñaba qué componentes venían y cuándo, para que nadie tuviera que adivinar.
Donde un diseño dejaba un hueco, lo rellenaba yo
Yo estaba justo entre quien diseña una pantalla y quien la programa. Cuando una propuesta llegaba sin estados hover, deshabilitado o vacío, o sin respuesta para una pantalla pequeña, tenía dos opciones: pasarle el hueco a desarrollo o cerrarlo yo. Lo cerraba yo: definí esos estados, con sus tokens, para que cada componente sirviera más allá de la pantalla en la que apareció por primera vez.
Los resultados
- Seis productos alimentados por el sistema de diseño en el lanzamiento, y sumando
- Una sola librería compartida por los diseñadores de tres organizaciones
- Una librería de 62 componentes y 616 variantes, documentada para diseño y desarrollo
- Cambios que llegan a todos los archivos de producto desde un solo sitio
- Un registro de cambios que desarrollo revisaba cada semana
- Entregado en diciembre de 2025, tras once meses
Lo que aprendí
Lo más difícil no fue construir componentes. Fue explicarle a gente menos acostumbrada a los sistemas de diseño que todo lo que se diseña alguien tiene que programarlo, y que un cambio visual nunca es solo visual cuando otros equipos dependen de él. Visto ahora, habría puesto ese coste encima de la mesa mucho antes, cuando los botones todavía se estaban multiplicando. Todo se asentó cuando se fijó el lenguaje visual, pero no tenía por qué haber tardado tanto.
El proyecto también me confirmó una costumbre que ya traía: preguntarme quién va a abrir mis archivos después, si un diseñador o un desarrollador, y trabajar cerca de desarrollo para adelantarme a sus dudas. ¿Qué pasa aquí cuando no hay datos? Prefiero contestarlo mientras diseño a que me lo pregunten después.
Lo que no puedo decir es cuánto tiempo ahorró: nadie midió lo que el sistema les quitó de encima a los equipos.
Contacto
Si te he caído bien y quieres ponerte en contacto conmigo, cuéntame el proyecto, la charla o tus teorías sobre el Área 51. Escríbeme o reserva una llamada.