Design systems en organizaciones grandes: cuando la coherencia es una decisión de gobierno, no de estética
Un sistema de diseño bien construido no es una colección de botones y tipografías. Es la decisión de cómo una organización garantiza coherencia cuando cientos de personas construyen el mismo producto. Y esa decisión es de dirección, no de diseño.
Un sistema de diseño no es una librería de componentes. Es una decisión de gobierno.
Hay una conversación que tenemos con frecuencia con nuevos clientes. Empieza cuando nos dicen que ya tienen un sistema de diseño, y termina cuando les preguntamos quién decide qué entra en él.
Si la respuesta es "hay un equipo que lo gestiona", vamos bien. Si la respuesta es "depende", "no está claro" o "cada equipo tiene algo diferente", el problema no es el sistema — es la gobernanza que hay alrededor.
O más bien, la falta de ella.
El error de tratar un sistema de diseño como un producto de diseño
La mayoría de los sistemas de diseño fracasan por la misma razón: se diseñan como si fueran un producto de diseño cuando en realidad son una infraestructura organizativa.
Un producto de diseño tiene un equipo de diseño, un equipo de producto, unos usuarios y un objetivo. Se itera, se mejora, se lanza. La calidad se mide en usabilidad, en adopción, en impacto en el negocio.
Un sistema de diseño tiene todo eso, más algo que un producto de diseño normal no tiene: múltiples equipos que dependen de él para construir sus propios productos. Equipos con necesidades distintas, con plazos distintos, con criterios estéticos distintos y con distintos niveles de comprensión de lo que el sistema es y para qué sirve.
Gestionar esa complejidad no es un problema de diseño. Es un problema de gobierno.
Qué significa gobernar un sistema de diseño
Gobernar un sistema de diseño significa tener respuesta a estas preguntas:
¿Quién puede proponer cambios al sistema? ¿Cualquier equipo, o solo algunos? ¿Con qué proceso?
¿Quién aprueba los cambios? ¿Un comité, una persona, el equipo que gestiona el sistema? ¿Con qué criterios?
¿Cómo se comunican los cambios a todos los equipos que dependen del sistema? ¿Con cuánta antelación? ¿Con qué documentación?
¿Qué pasa cuando un equipo necesita algo que el sistema no contempla? ¿Puede hacer una excepción? ¿Con qué condiciones? ¿Quién lo sabe?
¿Cómo evoluciona el sistema cuando la marca o el producto cambian? ¿Con qué proceso de migración para los productos que ya están en producción?
Estas preguntas no tienen respuesta en Figma. Tienen respuesta en un documento de gobernanza que el equipo entiende, acepta y respeta — y en una cultura organizativa que lo hace cumplir.
El modelo de federación
En las organizaciones grandes donde hemos construido o mantenido sistemas de diseño — grupos bancarios, aseguradoras, operadoras de infraestructura — el modelo que mejor funciona es el de federación.
En el modelo federado, hay un equipo central que gestiona el sistema: define los estándares, aprueba los cambios, comunica las actualizaciones. Pero los equipos de producto tienen cierta autonomía para proponer extensiones al sistema, para construir componentes específicos que el sistema central no contempla todavía, y para adaptar ciertos aspectos a las necesidades de su producto.
Lo que no pueden hacer es saltarse el sistema sin más. Si necesitan algo diferente, hay un proceso para pedirlo, justificarlo y, si tiene sentido, incorporarlo al sistema central para que todos se beneficien.
Ese equilibrio entre centralización y autonomía es lo que hace que el sistema sea útil para los equipos de producto y manejable para el equipo central. Demasiada centralización y el sistema se convierte en un cuello de botella. Demasiada autonomía y el sistema se fragmenta en semanas.
Por qué esto importa especialmente en banca y seguros
En sectores altamente regulados, la consistencia en el diseño no es solo una cuestión estética. Tiene implicaciones en la confianza del usuario y en el cumplimiento regulatorio.
Un flujo de onboarding inconsistente en una app bancaria no solo confunde al usuario — puede generar dudas sobre si está en el sitio correcto, sobre si la operación es segura, sobre si la entidad es de fiar. En un contexto donde el fraude digital es una realidad cotidiana, esas dudas tienen consecuencias.
Un sistema de diseño bien gobernado garantiza que esa consistencia existe en todos los productos del banco, independientemente de qué equipo los haya construido. Y garantiza que cuando hay que introducir cambios por requisitos regulatorios — un nuevo aviso de privacidad, un nuevo flujo de consentimiento — ese cambio se aplica de forma coordinada en todos los lugares donde es necesario.
Lo que hemos aprendido
Llevamos años construyendo y manteniendo sistemas de diseño para organizaciones grandes. La lección más importante no es técnica — es organizativa.
El sistema de diseño que más valor genera no es el más completo, ni el más sofisticado, ni el más bonito en Figma. Es el que la organización realmente usa. Y la organización solo usa el sistema que entiende, en el que confía, y que evoluciona con sus necesidades sin quedarse obsoleto ni romperse cada vez que alguien propone un cambio.
Para que eso pase, hace falta gobernanza. Y para que la gobernanza funcione, hace falta que alguien en la organización la tome en serio desde el principio — no como un proceso burocrático, sino como la infraestructura que hace posible diseñar a escala.