Análisis independiente de la documentación pública de Salesforce y de los escritos de su equipo de diseño. Identity Forge no está afiliado ni cuenta con el respaldo de Salesforce. Salesforce, Lightning y Agentforce son marcas comerciales de sus respectivos propietarios. Los detalles de la versión reflejan la documentación disponible en el momento de la redacción.
El problema de SLDS 1
SLDS 1 se lanzó en 2015 y, según Salesforce, estableció el estándar del diseño empresarial de la época. Es un framework de CSS: se importa, se utilizan sus clases y los componentes web personalizados de Lightning adquieren la apariencia de Lightning Experience. Eso es exactamente lo que una plataforma empresarial buscaba en 2015, cuando el objetivo era la consistencia entre miles de organizaciones y se asumía que consistencia significaba uniformidad.
El motivo declarado de la reestructuración es que cambiaron dos cosas. Creció la demanda de los clientes por una personalización más profunda y la IA generativa comenzó a remodelar las experiencias de usuario. Ambas presiones apuntan en la misma dirección: un framework cuyas decisiones visuales están integradas en las definiciones de sus clases no puede admitir un temizado profundo ni ser un objetivo estable para una UI generada.
Es una declaración bastante contundente por parte de un proveedor sobre su propio sistema insignia de hace una década. También es correcta, y el mismo diagnóstico se aplica a muchos sistemas de diseño internos que aún no lo han admitido en voz alta.
Qué ha cambiado en SLDS 2
La propuesta arquitectónica es específica: la nueva arquitectura de CSS está desacoplada del estilo visual predeterminado de Salesforce, lo que significa que ya no está limitado a elecciones de diseño predefinidas para componentes como botones, modales, fuentes y bordes. El mecanismo son los styling hooks globales, propiedades personalizadas de CSS que sustituyen los valores fijos dentro de las reglas del framework.
| SLDS 1 | SLDS 2 | |
|---|---|---|
| Ubicación de las decisiones visuales | Dentro de las reglas CSS del framework | En propiedades personalizadas de CSS configurables |
| Cambiar el radio de las esquinas en todo el sistema | Sobrescribir selectores, luchar contra la especificidad, esperar | Configurar una única propiedad personalizada |
| Profundidad del temizado | Colores de marca y logotipo, aproximadamente | Botones, modales, fuentes, bordes, espaciado |
| Modo oscuro | No viable | La hoja de ruta establecida |
| Lo que afirma el framework | Estructura y apariencia | Estructura; la apariencia se suministra |
La frase que Salesforce utiliza para resaltar el beneficio merece citarse como un principio de diseño: un solo cambio lo actualiza todo. En lugar de ajustar los componentes individualmente, los styling hooks permiten modificar los valores en un único lugar para obtener actualizaciones globales instantáneas.
Esa frase es la definición de un sistema de tokens, y es la prueba que debe aplicar al suyo propio. Si cambiar el radio de las esquinas de su marca implica editar más de un lugar, tiene variables, no tokens. La diferencia radica en si el valor tiene un único hogar o múltiples copias.
Alrededor de la arquitectura se encuentran los cambios visibles. Salesforce Cosmos es el nuevo tema predeterminado para SLDS 2, descrito como una propuesta que ofrece espaciado adaptable, vistas de un vistazo, una paleta de colores enriquecida, una escala tipográfica legible y una carga cognitiva reducida. La función ampliada de Temas y Branding en Setup permite a los administradores aplicar colores de marca, logotipos e imágenes sin código, con nueve nuevas opciones de colores de acento.
La división entre no-code y pro-code es deliberada y explícita: los administradores disponen de un diseño basado en clics, mientras que los diseñadores y desarrolladores obtienen el control pro-code a través de los styling hooks. Esta es una decisión real de gobernanza del sistema de diseño, al definir qué audiencia accede a qué superficie; la mayoría de los sistemas solo llegan a construir la mitad pro-code.
La librería de Figma que coincide exactamente con el código
Un detalle merece ser analizado por separado porque resuelve un problema que casi todos los sistemas de diseño tienen y casi ninguno resuelve correctamente. La librería de Figma de SLDS 2 utiliza la misma convención de nomenclatura semántica para los styling hooks que el código (los propios ejemplos de Salesforce son radius-border-4 y font-scale-4), por lo que los diseños se mapean uno a uno con el código en vivo.
El efecto declarado es un vocabulario compartido que tiende un puente entre el diseño y el desarrollo. El efecto práctico es que la entrega de diseño (handoff) deja de ser un ejercicio de traducción. Cuando un diseñador dice font-scale-4 y el desarrollador escribe font-scale-4, desaparece por completo la categoría de "¿a qué gris te referías?".
La librería también contiene todas las variables y propiedades que se pueden alternar, de modo que los componentes pueden modificarse directamente en Figma en lugar de tener que alternar entre el sitio de documentación y el archivo de diseño actualizando los componentes uno por uno. Este es un pequeño detalle de herramientas con una gran consecuencia conductual: elimina la fricción que provoca que los diseñadores se salgan del sistema.
Cuando un diseñador dicefont-scale-4y el desarrollador escribefont-scale-4, deja de existir toda una categoría de errores de handoff.
Cumplimiento: el linter
SLDS 2 incluye herramientas que validan los componentes frente a las reglas de SLDS en lugar de limitarse a describirlos. SLDS Linter es la herramienta de análisis de código; SLDS Validator escanea el marcado, lo valida frente a una base de datos y ofrece recomendaciones de corrección. Salesforce enumera nuevos conjuntos de reglas, guía integrada y linting masivo.
Este es el mismo instinto que el kit de UI de aplicaciones de Stripe al rechazar CSS arbitrario, alcanzado por una ruta diferente. Stripe elimina la capacidad; Salesforce no puede, porque SLDS es CSS en la organización de un cliente y el cliente siempre puede escribir más CSS. Por lo tanto, hace lo siguiente mejor: hace que las infracciones sean visibles mecánicamente.
| Mecanismo | Coste | |
|---|---|---|
| Documentación | Escribir lo que es correcto y esperar | Gratis, y aproximadamente tan efectivo como lo gratis |
| Linting | Marcar infracciones en el editor y en CI | Inversión real en herramientas; requiere una base de datos de reglas mantenida junto al sistema |
| Eliminar la capacidad | Hacer que lo incorrecto sea imposible de expresar | Cada necesidad nueva y genuina se convierte en una solicitud a los propietarios del sistema |
La mayoría de los equipos solo intentan la primera fila. La fila central es donde el retorno del esfuerzo es mayor, y es lo suficientemente poco glamurosa como para que rara vez se priorice hasta que alguien cuenta cuántos valores hexadecimales hay en la base de código.
La parte agéntica, en palabras de Salesforce
La descripción de Salesforce sobre SLDS 2 es directa: es la base para el sistema de diseño agéntico de los productos de Salesforce creados sobre la Lightning Platform. El blog que lo anuncia afirma que la nueva arquitectura sienta las bases para las experiencias agénticas y el modo oscuro, y describe una reimaginación de cómo funcionan los sistemas de diseño tanto en el flujo de trabajo de diseño-desarrollo como en las experiencias de usuario generadas dinámicamente.
Esa última frase es la que hay que analizar. Experiencias de usuario generadas dinámicamente. No se trata de que "la IA ayude a los desarrolladores a escribir código más rápido". La interfaz misma se ensambla en tiempo de ejecución, por usuario y por contexto, por algo que no fue un diseñador.
Si esa es su premisa, un sistema de diseño que integra la apariencia en las definiciones de los componentes es estructuralmente incapaz de servirlo, porque el generador no tiene nada que variar. Lo que necesita una interfaz generada es exactamente lo que proporciona SLDS 2: un vocabulario estructural estable con las decisiones visuales expuestas como valores nombrados y configurables.
Vale la pena notar quién sostiene este argumento. No es una startup que vende herramientas de diseño con IA. Es un proveedor de plataformas empresariales con una década de base instalada y todos los incentivos para no reconstruir un framework que ya funciona, publicando que lo ha reconstruido de todos modos y explicando por qué.
El mismo movimiento, tres veces
SLDS 2 no es un caso aislado. Tres de los sistemas de diseño empresariales publicados abiertamente más grandes se reestructuraron en aproximadamente dieciocho meses, cada uno apostando de manera diferente por la misma premisa.
| Qué cambió | La apuesta | |
|---|---|---|
| Salesforce Lightning (SLDS 2) | Arquitectura CSS desacoplada del estilo visual; styling hooks; linter y validador | La estructura y la apariencia deben estar separadas, y las infracciones deben detectarse mecánicamente |
| IBM Carbon | Un servidor MCP que expone documentación y ejemplos de código a los agentes | Los agentes deben recuperar el sistema en el momento de la generación en lugar de intentar recordarlo |
| Shopify Polaris | React queda obsoleto en favor de web components independientes del framework servidos desde un CDN | La entrega no debe asumir qué fue lo que generó la página |
Nadie coordinó esto. Tres empresas con productos y restricciones diferentes llegaron a conclusiones compatibles en el mismo periodo, lo cual suele ser señal de que el cambio subyacente es real y no una simple moda.
Qué extraer de esto si no utiliza Salesforce
La arquitectura de SLDS 2 es una respuesta amplia y específica a una pregunta que la mayoría de los equipos aún no se han planteado: ¿puede alguien que no sea un diseñador producir una interfaz alineada con la marca a partir de su sistema de diseño? Hay cuatro aspectos que son transferibles independientemente de la plataforma.
- 1
Separar la estructura de la apariencia
Cada decisión visual que actualmente es un valor literal dentro de la regla de un componente es una decisión que un generador no puede variar y que un cliente no puede tematizar. Eleve estos valores a propiedades personalizadas con nombre. Se trata de una refactorización poco glamurosa pero con una gran recompensa, y es además el requisito previo para el modo oscuro.
- 2
Nombre los hooks semánticamente y utilice los mismos nombres en la herramienta de diseño
radius-border-4en Figma yradius-border-4en CSS. Un solo vocabulario, dos renderizados. Cada discrepancia entre los nombres de la herramienta de diseño y los nombres del código es un paso de traducción donde se pierde significado. - 3
Imponer mecánicamente, no editorialmente
Un linter que marque un valor hexadecimal bruto en un pull request aporta más a la consistencia que cualquier cantidad de documentación. Si no puede crear una base de datos de reglas, empiece con una sola regla que prohíba los valores de color literales fuera del archivo de tokens.
- 4
Decidir cuál es la superficie no-code
Salesforce lo dividió explícitamente: los administradores tematizan mediante clics, los desarrolladores mediante hooks. Si su sistema tiene stakeholders que no son desarrolladores y necesitan cambiar algo, darles una superficie delimitada es la forma de evitar que soliciten anulaciones (overrides) puntuales.
Hay un quinto elemento que SLDS 2 no cubre, y es el que más necesitan la mayoría de los equipos. Los hooks de estilo indican a un generador qué puede variar, pero no le indican cuáles son los valores correctos, qué significa cada rol o qué está prohibido.
Analizamos 299 archivos DESIGN.md escritos para dar exactamente esa guía a los agentes de IA. El 86% especificaba los colores como hexadecimales brutos sin rol semántico, el 76% no contenía prohibiciones de ningún tipo, el 69% no mencionaba el modo oscuro y el 57% no definía motivos. Un generador que reciba un conjunto de hooks y ese archivo se encontrará con una API de tematización vacía y sin argumentos sobre qué incluir en ella.
Los kits de diseño de Identity Forge son ese argumento, en una forma que un agente puede ejecutar: roles de color semánticos para modo claro y oscuro, escalas de tipografía y espaciado, motivos y directrices explícitas de lo que se debe y no se debe hacer, serializados en un DESIGN.md. Explore los kits o lea qué es un archivo DESIGN.md.
Notas prácticas sobre la migración
Salesforce deja claro que el cambio no es obligatorio y que las organizaciones pueden adoptarlo a su propio ritmo. El sitio de SLDS 2 incluye una guía de transición a SLDS 2, y la documentación de SLDS 1 ahora se encuentra en v1.lightningdesignsystem.com en lugar del dominio principal; es importante saberlo si tiene marcadores o enlaces en la documentación interna que apunten a las URLs antiguas.
Si mantiene Lightning web components personalizados, el linter es el punto de partida lógico independientemente de cuándo migre: ejecútelo, observe cuánta parte de su CSS está afirmando cosas que el framework dejará de afirmar y utilice esa cifra para dimensionar el trabajo con honestidad.
¿Cuál es la diferencia entre SLDS 1 y SLDS 2?
SLDS 1 es un framework de CSS con las decisiones visuales de Salesforce integradas en sus reglas. SLDS 2 lo reestructura en torno a propiedades personalizadas de CSS, de modo que la estructura permanece y la apariencia se suministra a través de hooks de estilo. Esto es lo que hace posible la tematización profunda y el modo oscuro, y lo que Salesforce describe como la base para las experiencias agénticas.
¿Tengo que migrar a SLDS 2?
No. Salesforce indica que no es obligatorio realizar el cambio y que puede adoptarlo a su propio ritmo. El sitio de SLDS 2 publica una guía de transición a SLDS 2, y la documentación de SLDS 1 sigue disponible en v1.lightningdesignsystem.com.
¿Qué son los hooks de estilo de SLDS?
Propiedades personalizadas de CSS expuestas por el framework que permiten establecer valores como el color, el radio y la tipografía de forma global, en lugar de anular selectores componente por componente. Son el mecanismo que desacopla la arquitectura de SLDS 2 de su estilo visual predeterminado.
¿Soporta SLDS 2 el modo oscuro?
Salesforce describe que el camino hacia el modo oscuro comienza con la transición a SLDS 2. La arquitectura de propiedades personalizadas es el requisito previo. Consulte las notas de la versión actual para ver qué se ha implementado realmente, ya que este tipo de declaraciones de hoja de ruta suelen variar.
¿Qué significa realmente "sistema de diseño agéntico" en este contexto?
Salesforce lo utiliza para interfaces ensambladas dinámicamente en lugar de diseñadas pantalla por pantalla, en el contexto de su plataforma Agentforce. Estructuralmente, esto implica que el sistema de diseño debe exponer sus decisiones visuales como valores configurables con nombre, ya que un generador que produce una interfaz en tiempo de ejecución necesita elementos que puedan variar y otros que permanezcan fijos.