Los resúmenes de sistemas de diseño suelen organizarse por empresa, que es el eje menos útil: ya sabe quién es Airbnb, y ese dato no le indica si su sistema le será útil. Aquí tiene el mismo conjunto organizado según lo que esté intentando resolver.

A continuación analizamos cada uno, detallando qué está disponible y qué merece la pena adoptar.

Al analizar Carbon, Polaris y Lightning en conjunto, surge un punto que no se discute individualmente en ninguno de ellos. Los tres se han reestructurado recientemente, de distintas formas, bajo la misma premisa: el código que consume un sistema de diseño es, cada vez más, escrito por una IA y no por un humano que lee la documentación.

Salesforce es el más explícito al respecto, describiendo SLDS 2 como la base de su sistema de diseño agéntico y refiriéndose a experiencias de usuario generadas dinámicamente. El motivo declarado por IBM para el servidor MCP incluye un código generado de mayor fidelidad. El enfoque de Shopify se centra en que las aplicaciones parezcan nativas del administrador, pero el efecto es el mismo: componentes que se renderizan idénticamente independientemente de qué los haya ensamblado.

Nadie coordinó esto. Tres empresas con productos diferentes, restricciones distintas y sin motivo para ponerse de acuerdo llegaron a conclusiones compatibles en el mismo periodo; lo cual suele ser la señal de que el cambio subyacente es real y no una moda.

Código abierto, financiado y construido por IBM, basado en el IBM Design Language como una capa separada de base de marca, con sistemas de dominio (IBM Products, Cloud, IBM.com) sobre el núcleo. React, Web Components y Elements son mantenidos por el equipo de Carbon; Angular, Vue y Svelte son mantenidos por la comunidad, y la documentación lo indica, lo cual es la transparencia honesta que la mayoría de los sistemas omiten.

Adoptar: la separación en tres capas y la práctica de publicar quién mantiene cada implementación. Ignorar: adoptarlo íntegramente si la diferenciación visual es importante para su producto, ya que la densidad y los modismos de interacción mantienen la identidad de IBM incluso después de cambiar el tema de los colores. Lectura completa.

Foundations, design tokens, componentes y más de 400 iconos enfocados al comercio. La librería de React ahora está marcada como obsoleta; los web components se cargan desde un CDN de Shopify y se añaden automáticamente mediante Shopify CLI.

Adoptar: el set de iconos de comercio si desarrolla en ese sector, el enfoque de nomenclatura de los design tokens y el razonamiento del modelo de entrega. Ignorar: los componentes fuera de una aplicación de Shopify; harán que su producto parezca Shopify. Lectura completa.

SLDS 1 se lanzó en 2015 como un framework CSS con la apariencia integrada. SLDS 2 lo reconstruyó en torno a propiedades personalizadas de CSS, añadió una librería de Figma cuyos nombres de design tokens coinciden exactamente con el código y lanzó herramientas de linting que validan el marcado según las reglas.

Adoptar: la paridad de nomenclatura entre Figma y el código, y el linter como mecanismo de cumplimiento. Ambos son copiables sin adoptar una sola línea de CSS de Salesforce. Ignorar: el framework en sí, a menos que desarrolle sobre la Lightning Platform. Lectura completa.

El ejemplo más sólido de un sistema construido en torno a una restricción que nadie más toma tan en serio: tiene que funcionar para todo el mundo, incluyendo personas con dispositivos antiguos, conexiones deficientes, lectores de pantalla y bajo situaciones de estrés. Los componentes vienen acompañados de investigaciones publicadas sobre cómo fueron probados y por qué tienen ese aspecto.

Adoptar: la práctica de publicar la evidencia detrás de cada componente. Casi nadie lo hace, y es la diferencia entre un sistema que se sigue y uno con el que se discute. Ignorar: la estética, que es deliberadamente institucional.

De larga trayectoria, exhaustivamente documentado y excepcionalmente fuerte en guías de contenido y voz, más allá de la especificación visual; la parte de un sistema de diseño que la mayoría de los equipos nunca escribe.

Adoptar: los estándares de redacción y contenido. Si su sistema no tiene una sección sobre cómo se redactan las cosas, este es el modelo. Ignorar: nada en particular; es una referencia general razonable.

Esta categoría suele confundir, por lo que conviene dejarlo claro: varios de los sistemas de diseño más citados no se pueden descargar. Lo que existe es la documentación publicada por el equipo sobre ellos, que a menudo es más útil de lo que habría sido el código.

Hay un patrón en esa tabla que merece la pena notar: los sistemas con las identidades visuales más fuertes son los que menos publican. No es una coincidencia ni un secreto competitivo. Un sistema que existe para que un producto se sienta como sí mismo no tiene nada que ganar al ser instalable, y un sistema construido para ser adoptado por miles de equipos tiene que ser lo suficientemente neutral para sobrevivir a ello. La neutralidad y la identidad se contraponen.

Los sistemas anteriores son los que merece la pena leer detenidamente. Estos merecen la pena conocer su existencia, con la única utilidad real que aporta cada uno.

Ambos importan por una razón que es fácil pasar por alto: establecen las convenciones que sus usuarios ya han aprendido. Incluso si no construye nada con ellos, definen lo que significa que "el botón de atrás funcione normalmente". El DLS de Airbnb trazó su línea de divergencia de plataforma precisamente en torno a lo que estos dos dominan.

Cloudscape es el infravalorado. La mayoría de los sistemas publicados están optimizados para marketing y UI de aplicaciones generales; muy pocos se toman en serio las interfaces operativas densas, y los que lo hacen rara vez publican. Si construye software de administración o de consola, está más cerca de su problema que Material o Polaris.

Esta fila merece especial atención porque es donde se encuentran la mayoría de los equipos. Adoptar Radix más shadcn más Tailwind proporciona un comportamiento accesible excelente, una capa de tokens y una estrategia de distribución, pero ninguna decisión sobre densidad, composición, motivos o prohibiciones. Esta combinación produce la interfaz consistente, competente y totalmente intercambiable que la gente describe como «generada por IA». La distinción completa.

Existen varios catálogos extensos que indexan sistemas de diseño públicos y responden bien a una pregunta concreta: ¿alguien en mi sector ha resuelto esto y cómo lo ha llamado? Una galería de componentes es genuinamente útil para comparar once versiones de un selector de fecha antes de diseñar la duodécima.

Lo que no hacen es decirle qué sistema merece la pena estudiar. Una entrada de directorio es un enlace y una captura de pantalla; el razonamiento reside en la documentación del equipo, no en el catálogo. Úselos para obtener amplitud y acuda a la fuente para obtener profundidad.

Cada ejemplo anterior es documentación que se lee. Esa es la limitación intrínseca del formato: un sistema de diseño solo puede juzgarse una vez que las mismas decisiones se trasladan a pantallas que no tienen nada que ver entre sí. Una landing page demuestra que un sistema puede verse bien una vez. Una landing page, un dashboard y una hoja de componentes creados a partir de un mismo conjunto de tokens demuestran que el sistema es sólido.

Estos son sistemas completos renderizados en vivo, no capturas de pantalla. Cada uno es un conjunto de tokens aplicado a tres superficies independientes; por lo tanto, lo que se comprueba no es si gustan los colores, sino si las *mismas* decisiones sobreviven tanto en un hero de marketing como en una tabla densa.

La versión más valiosa de este ejercicio es aquella que nadie ha publicado, sobre un producto de su propio sector. Lleva aproximadamente una hora.

1. 1

   Capture tres pantallas, no una

   Una pantalla le muestra la paleta. Tres pantallas le muestran qué decisiones se repiten, y la repetición es lo que distingue un sistema de una página.

2. 2

   Lea los valores computados, no confíe en la vista

   Abra las herramientas de desarrollo y anote el font-weight, letter-spacing, border-width, border-radius y padding. El «interletrado cerrado» es una impresión; -0.022em sobre 48px es una regla.

3. 3

   Busque el rango, no el valor

   El hallazgo rara vez es un único número. Es que cada peso cae entre 400 y 510, o que el radio es siempre 6 o 12. Los rangos son reglas; los valores únicos son muestras.

4. 4

   Anote lo que está ausente

   Sin sombras. Sin degradados. Sin un segundo color de acento. Sin pesos superiores a 510. Las ausencias son el resultado de mayor valor de un análisis técnico y lo primero que se pierde en cualquier extracción automatizada.

5. 5

   Convierta cada observación en una instrucción

   «La elevación es un paso de superficie más un borde de 1px, nunca un box-shadow» es ejecutable. «Minimalista y preciso» no lo es. En este paso es donde un análisis técnico se convierte en un sistema de diseño.

El cuarto paso es el fundamental. Analizamos 299 archivos DESIGN.md escritos para dar pautas de diseño a agentes de IA y descubrimos que el 76 % no contiene ninguna prohibición, además de que el 86 % especifica los colores como hex raw sin rol semántico y el 57 % no define motivos distintivos. Esos archivos describen una paleta. La identidad que intentaban capturar estaba en las ausencias.

Existe una forma de estudiar los sistemas de diseño que produce algo peor que empezar de cero. Ocurre cuando el ejercicio se vuelve adquisitivo: si reúne las mejores partes de nueve sistemas, obtendrá una interfaz competente pero sin ningún argumento detrás.

Cada sistema mencionado anteriormente es el resultado de una decisión sobre el usuario. La densidad de Linear es un argumento a favor de que un usuario avanzado que utiliza una herramienta todo el día busca sobriedad e información. La sencillez de GOV.UK es un argumento a favor de que el lector puede estar estresado, tener una mala conexión y no se puede asumir que disponga de ningún recurso. La neutralidad de Carbon es un argumento a favor de que miles de equipos lo adoptarán y ninguno de ellos es el equipo de marca de IBM.

Utilice estos ejemplos para calibrar el rigor: qué tan específicos son los números, cuántas cosas se prohíben y qué tan estrechos son los rangos. Después, plantee sus propios argumentos sobre su propio lector y deje que las reglas se deriven de ello.