Empiece por el problema, no por la lista
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 hecho no le indica si su sistema le será de ayuda. Aquí tiene el mismo conjunto organizado según lo que esté intentando resolver.
| Leer | Porque | |
|---|---|---|
| "¿Dónde van los componentes específicos del producto?" | Carbon, Encore | Ambos lo resolvieron con capas: una base que no se puede anular y subsistemas especializados por encima |
| "¿Cómo hago para que la gente lo siga realmente?" | Stripe, SLDS 2 | Uno elimina la capacidad de desviarse; el otro utiliza linting para detectarlo. La documentación es la tercera opción y es la que pierde |
| "¿Cómo mantengo la coherencia en cuatro plataformas?" | Airbnb DLS | Componentes definidos por contrato en lugar de composición: lo único que sobrevive a cuatro implementaciones |
| "¿Cómo permito que los clientes apliquen temas a fondo?" | SLDS 2, Stripe Elements | Desacoplamiento de la estructura del estilo visual, y una jerarquía de tema→variables→reglas |
| "¿Por qué mi producto parece genérico?" | Linear | La identidad proviene de lo que un sistema se niega a hacer, y las renuncias son lo que la mayoría de los sistemas omiten |
| "¿Cómo debería entregarlo a los consumidores?" | Polaris | El hecho de que usted o sus consumidores controlen la versión depende de quién sea el responsable de la apariencia |
El resto de este texto analiza cada uno, detallando qué está disponible y qué merece la pena adoptar.
Los tres que han cambiado en los últimos dieciocho meses
Al analizar Carbon, Polaris y Lightning en conjunto, surge algo que no se discute cuando se analizan individualmente. 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 máquina y no por un humano que lee la documentación.
| Qué ha cambiado | La apuesta | |
|---|---|---|
| IBM Carbon | Ha lanzado un servidor MCP que expone documentación, ejemplos de código de componentes, gráficos y componentes experimentales a los agentes | Los agentes deben recuperar el sistema en el momento de la generación en lugar de recordarlo a partir de los datos de entrenamiento |
| Salesforce Lightning | SLDS 2: arquitectura CSS desacoplada del estilo visual predeterminado, hooks de estilo como propiedades personalizadas y un linter que valida el marcado | La estructura y la apariencia deben estar separadas, y las infracciones deben detectarse mecánicamente |
| Shopify Polaris | React ha quedado obsoleto en favor de web components agnósticos al framework servidos desde un CDN | La entrega no debe asumir qué framework generó la página |
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 de forma idéntica 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 señal de que el cambio subyacente es real y no una moda.
Los sistemas abiertos e instalables
IBM Carbon
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. Omitir: 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.
Shopify Polaris
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. Omitir: los componentes fuera de una aplicación de Shopify. Harán que su producto parezca Shopify. Lectura completa.
Salesforce Lightning
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. Omitir: el framework en sí, a menos que desarrolle sobre la Lightning Platform. Lectura completa.
GOV.UK Design System
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, incluidas 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. Omitir: la estética, que es deliberadamente institucional.
Atlassian Design System
De larga trayectoria, exhaustivamente documentado y excepcionalmente sólido en la guía 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. Omitir: nada en particular; es una referencia general razonable.
Los documentados pero privados
Esta categoría suele confundir, así 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.
| Disponible | La lección que merece la pena extraer | |
|---|---|---|
| Stripe | Dos sistemas de integración públicos (Apps UI toolkit, Elements Appearance API); el sistema interno no está publicado | La postura sigue el límite de confianza: vocabulario cerrado en la superficie de Stripe, una escala de personalización en la suya |
| Airbnb DLS | Cuentas de equipo publicadas; sin paquete | Componentes como unidades autónomas con elementos declarados, rechazando explícitamente la composición atómica |
| Spotify Encore | Documentación del equipo de diseño publicada; sin paquete | Capas concéntricas y la admisión pública de que la flexibilidad se extremó demasiado y requirió una nueva capa para corregirlo |
| Linear | Nada oficial; extracciones de terceros con fiabilidad variable | La identidad se transmite mediante la restricción: un rango de pesos estrecho, líneas finas en lugar de sombras, un solo color de acento usado con moderación |
Tenga cuidado con las "extracciones" de terceros de sistemas privados. Un informe de estilos extraído puede indicarle que una superficie es de un gris concreto. No puede decirle si ese gris es un paso deliberado en una escala o un accidente en una página, y nunca captura las prohibiciones, que es la parte que haría que la copia funcionara.
Hay un patrón en esa tabla que merece la pena observar: los sistemas con las identidades visuales más fuertes son los que menos publican. Esto no es una coincidencia ni un secreto competitivo. Un sistema que existe para que un producto se sienta como sí mismo no gana nada siendo instalable, y un sistema creado para ser adoptado por miles de equipos debe ser lo suficientemente neutro para sobrevivir a ello. La neutralidad y la identidad se contraponen.
El resto del sector, brevemente
Los sistemas anteriores son los que merece la pena leer detenidamente. Estos otros merece la pena saber que existen, junto con el aspecto específico en el que cada uno es realmente bueno.
Sistemas de plataforma
| Lección | Atención a | |
|---|---|---|
| Material Design | El tratamiento público más exhaustivo de capas de movimiento y estado disponible. Su modelo de elevación y estado de interacción merece la pena leerlo aunque nunca lo utilice | Adoptarlo íntegramente hace que un producto web parezca una aplicación de Android. Sus opiniones son fuertes y legibles para los usuarios |
| Apple Human Interface Guidelines | La redacción más clara sobre *por qué* existe una convención en lugar de qué es. Excelente en modismos de plataforma y accesibilidad | Es una guía, no una librería de componentes. No hay nada que instalar, y aplicarlo fuera de la plataforma generalmente no funciona |
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 retroceso se comporte normalmente". El DLS de Airbnb trazó su línea de divergencia de plataforma precisamente en torno a lo que estos dos poseen.
Sistemas de productos grandes
| Vale la pena por | |
|---|---|
| GitHub Primer | Documentación inusualmente buena sobre *cuándo no* usar un componente, además de un enfoque maduro para implementar el mismo sistema en Rails, React y páginas estáticas |
| Microsoft Fluent | El intento publicado más grande de un sistema único para escritorio, web y móvil con shells nativos genuinamente diferentes. Instructivo principalmente por lo difícil que es lograrlo |
| AWS Cloudscape | El mejor ejemplo público de un sistema diseñado específicamente para interfaces de consola densas y cargadas de datos: tablas, filtros, listas de recursos. Raro y útil si construye este tipo de producto |
| Uber Base Web | Una arquitectura de temas sólida y un modelo de anulación (override) que permite a los consumidores acceder a los internos de los componentes de forma estructurada |
Cloudscape es el infravalorado. La mayoría de los sistemas publicados están optimizados para marketing e interfaces de aplicaciones generales; muy pocos toman en serio las interfaces operativas densas, y los que lo hacen rara vez publican. Si construye software de administración o consolas, está más cerca de su problema que Material o Polaris.
Primitivas y distribución
| Qué es | Qué no es | |
|---|---|---|
| Radix Primitives | Comportamiento accesible y sin estilos para los componentes complejos: menús, diálogos, comboboxes | Un sistema de diseño. Deliberadamente, no tiene una opinión sobre la apariencia visual |
| shadcn/ui | Un mecanismo de distribución más una convención de tokens: componentes copiados en su repositorio, no instalados como dependencia | Tampoco es un sistema de diseño. Define los nombres de sus tokens, pero no la densidad, la composición, los motivos ni las prohibiciones |
| Tailwind | Un sistema de restricciones para espaciado, color y tipografía aplicado a nivel de clase | Tiene una opinión marcada sobre el producto. Sus valores predeterminados son neutros y ampliamente utilizados, razón por la cual se perciben como genéricos |
Esta fila merece especial énfasis 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, sin tener que tomar decisiones sobre densidad, composición, motivos o prohibiciones. Esa combinación produce la interfaz consistente, competente y totalmente intercambiable que la gente describe como «generada por IA». La distinción completa.
Los directorios y para qué sirven
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.
Cómo se ve un sistema aplicado, en lugar de documentado
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 página de aterrizaje demuestra que un sistema puede verse bien una vez. Una página de aterrizaje, un panel de control 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 no relacionadas, por lo que lo que se comprueba no es si gustan los colores, sino si las *mismas* decisiones sobreviven a un hero de marketing y a una tabla densa.
Kit showcase · live surfaces
Verdant Finance
Live renderVerdant Finance rendered from its real tokens across 3 surfaces.
La pregunta que debe hacerse ante cualquier ejemplo
No «¿es esto atractivo?», sino «¿podría predecir la siguiente pantalla?». Un sistema real hace que la duodécima pantalla sea predecible a partir de las tres primeras. Si no puede adivinar cómo sería un modal tras estudiar la página de aterrizaje y el dashboard, el sistema es un estilo, y un estilo no sobrevive a un segundo diseñador o a un agente.
Cómo realizar su propio análisis detallado
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
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
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
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
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 detallado y lo primero que se pierde en cualquier extracción automatizada.
- 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 detallado se convierte en un sistema de diseño.
El cuarto paso es el más importante. 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.
Tres cuartas partes de las pautas de diseño reales no prohíben nada. Pero la identidad se construye a través de la renuncia, y una paleta copiada deja atrás esas renuncias.
El error que debe evitar
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 anterior es el resultado de una decisión tomada en función del lector. La densidad de Linear es un argumento de que un usuario avanzado que utiliza una herramienta todo el día necesita sobriedad e información. La sencillez de GOV.UK es un argumento de que el lector puede estar estresado, tener una mala conexión y no poder dar por sentado que dispone de nada. La neutralidad de Carbon es un argumento 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, qué tan estrechos son los rangos. Después, plantee su propio argumento sobre su propio lector y deje que las reglas se deriven de él.
Los kits de diseño de Identity Forge son sistemas completos en este sentido: roles de color semánticos para temas claro y oscuro, escalas de tipografía y espaciado, motivos y directrices explícitas de qué hacer y qué no hacer, serializadas en un DESIGN.md que un agente de código puede ejecutar. Explore los kits o lea qué es un archivo DESIGN.md.
¿Cuáles son los mejores ejemplos de sistemas de diseño para aprender?
Depende de su pregunta. Carbon y el Encore de Spotify para la jerarquización; Stripe y SLDS 2 para la aplicación de reglas y el tematizado; el DLS de Airbnb para los contratos multiplataforma; Polaris para la entrega; Linear para ver cómo la restricción crea identidad; y GOV.UK para consultar la investigación detrás de cada componente.
¿Qué sistemas de diseño importantes puedo descargar realmente?
Carbon, Polaris, Lightning, GOV.UK y Atlassian están disponibles públicamente. El sistema interno de Stripe, el DLS de Airbnb, el Encore de Spotify y el sistema de Linear no lo están: lo que existe para esos es la documentación publicada por sus equipos, que suele ser el artefacto más útil de todos modos.
¿Debería copiar un sistema de diseño que admiro?
Copie el rigor, no el contenido. Todo buen sistema es un conjunto de respuestas a preguntas sobre un lector específico, y extraer las respuestas sin las preguntas le dará una interfaz optimizada para el producto de otra persona. Utilice los análisis detallados para calibrar qué tan específicas deben ser sus propias reglas.
¿Por qué tan pocas empresas publican sus sistemas de diseño?
Porque un sistema construido para que un producto se sienta distintivo no tiene nada que ganar siendo instalable, mientras que un sistema construido para una adopción masiva tiene que ser lo suficientemente neutral como para funcionar en miles de productos no relacionados. Publicar empuja a un sistema hacia la neutralidad, que es lo opuesto a lo que busca una marca sólida.
¿Vale la pena utilizar directorios de sistemas de diseño?
Para obtener amplitud, sí. Son útiles para ver muchas implementaciones del mismo componente una al lado de la otra antes de diseñar el suyo propio. Para obtener profundidad, no. La entrada de un directorio es un enlace y una captura de pantalla; el razonamiento que hace que un sistema valga la pena estudiar reside en la propia documentación del equipo.