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 reconstrucción es que han cambiado dos cosas: la demanda de los clientes de una personalización más profunda ha crecido y la IA generativa ha empezado 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 puede 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 a los valores codificados rígidamente 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 | Básicamente colores de marca y logotipo | Botones, modales, fuentes, bordes, espaciado |
| Modo oscuro | No viable | La hoja de ruta establecida |
| Lo que afirma el framework | Estructura y apariencia | La estructura es fija; la apariencia se suministra |
La frase que Salesforce utiliza para describir el beneficio merece ser citada 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 control pro-code a través de los styling hooks. Esta es una decisión real de gobernanza del sistema de diseño —decidir qué audiencia accede a qué superficie— y 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—, de modo 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, por lo 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 más alto, 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, mediante 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 dar soporte a ello, 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 está planteando 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 de forma mecánica |
| IBM Carbon | Un servidor MCP que expone documentación y ejemplos de código a los agentes | Los agentes deberían recuperar el sistema en el momento de la generación en lugar de recordarlo |
| Shopify Polaris | React queda obsoleto en favor de web components agnósticos al framework servidos desde un CDN | La entrega no debe asumir qué ha generado la página |
Nadie coordinó esto. Tres empresas con productos y restricciones diferentes llegaron a conclusiones compatibles en el mismo periodo, lo que suele ser señal de que el cambio subyacente es real y no una moda.
Qué aprender de esto si no utilizas 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 hecho: ¿puede algo 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 se transfieren independientemente de la plataforma.
- 1
Separa la estructura de la apariencia
Cada decisión visual que actualmente es un valor literal dentro de una regla de componente es una decisión que un generador no puede variar y un cliente no puede tematizar. Trasládala a propiedades personalizadas con nombre. Es una refactorización poco glamurosa pero con una gran recompensa, y es también el prerrequisito para el modo oscuro.
- 2
Nombra los hooks semánticamente y utiliza los mismos nombres en la herramienta de diseño
radius-border-4en Figma yradius-border-4en CSS. Un vocabulario, dos representaciones. Cada discrepancia entre los nombres de la herramienta de diseño y los nombres de código es un paso de traducción donde se pierde el significado. - 3
Aplica las reglas de forma mecánica, no editorial
Un linter que señale un valor hex puro en un pull request aporta más a la consistencia que cualquier cantidad de documentación. Si no puedes construir una base de datos de reglas, empieza con una única regla que prohíba los valores de color literales fuera del archivo de tokens.
- 4
Decide cuál es la superficie no-code
Salesforce lo dividió explícitamente: los administradores tematizan con clics, los desarrolladores tematizan con hooks. Si tu sistema tiene stakeholders que no son desarrolladores y necesitan cambiar algo, darles una superficie delimitada es la forma de evitar que soliciten personalizaciones aisladas.
Hay un quinto aspecto que SLDS 2 no cubre, y es el que más necesitan la mayoría de los equipos. Los styling hooks le dicen a un generador qué puede variar. No le dicen 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 colores como hex puro sin un rol semántico, el 76% no contenía prohibiciones de ningún tipo, el 69% no decía nada sobre el modo oscuro y el 57% no definía ningún motivo. Un generador al que se le entrega un conjunto de hooks y ese archivo tiene una API de tematización vacía y ninguna instrucción sobre qué introducir en ella.
Los kits de diseño de Identity Forge son esa instrucción, en un formato que un agente puede ejecutar: roles de color semánticos para temas claro y oscuro, escalas de tipografía y espaciado, motivos y reglas explícitas de qué hacer y qué no hacer, serializadas en un DESIGN.md. Explora los kits, o lee qué es un archivo DESIGN.md.
Notas prácticas sobre la migración
Salesforce aclara 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 reside en v1.lightningdesignsystem.com en lugar del dominio principal; es importante saberlo si tienes marcadores o enlaces en documentación interna que apunten a las URLs antiguas.
Si mantienes web components de Lightning personalizados, el linter es el punto de partida lógico independientemente de cuándo migres: ejecútalo, observa cuánto de tu CSS está afirmando cosas que el framework dejará de afirmar y usa ese número 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 rearquitecturiza en torno a CSS custom properties, de modo que la estructura se mantiene y la apariencia se suministra a través de styling hooks. Eso es lo que hace posible la tematización profunda y el modo oscuro, y lo que Salesforce describe como la base para las experiencias de agentes.
¿Tengo que migrar a SLDS 2?
No. Salesforce indica que no es obligatorio cambiar y que se puede adoptar 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 styling hooks de SLDS?
Son CSS custom properties expuestas por el framework que permiten establecer valores como color, radio y tipografía de forma global, en lugar de sobrescribir selectores componente por componente. Son el mecanismo que desacopla la arquitectura de SLDS 2 de su estilo visual predeterminado.
¿Es compatible SLDS 2 con el modo oscuro?
Salesforce describe el camino hacia el modo oscuro como el inicio de la transición a SLDS 2; la arquitectura de custom properties es el prerrequisito. Consulta las notas de la versión actual para ver qué se ha implementado realmente, ya que este tipo de declaraciones de hoja de ruta pueden cambiar.
¿Qué significa realmente "agentic design system" 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.