SLDS 2: Salesforce reconstruiu seu design system para agentes

O SLDS 1 foi lançado em 2015 e, como a Salesforce define, estabeleceu o padrão para o design corporativo da época. Ele é um framework CSS: você o importa, usa suas classes e seus componentes web Lightning customizados ficam com a aparência do Lightning Experience. Era exatamente isso que uma plataforma corporativa queria em 2015, quando o objetivo era a consistência entre milhares de orgs e a premissa era que consistência significava uniformidade.

O motivo declarado para a reconstrução é que duas coisas mudaram. A demanda dos clientes por customizações mais profundas cresceu e a IA generativa começou a remodelar as experiências do usuário. Ambas as pressões apontam para a mesma direção: um framework cujas decisões visuais estão embutidas em suas definições de classe não pode ter temas profundos nem ser um alvo estável para UI gerada.

É algo bastante impactante para um fornecedor publicar sobre seu próprio sistema principal de dez anos. Também é correto, e o mesmo diagnóstico se aplica a muitos design systems internos que ainda não tiveram isso dito em voz alta.

A afirmação arquitetural é específica: a nova arquitetura CSS está desvinculada do estilo visual padrão da Salesforce, o que significa que você não está mais preso a escolhas de design predefinidas para componentes, incluindo botões, modais, fontes e bordas. O mecanismo são os styling hooks globais — propriedades customizadas de CSS — que substituem valores fixos dentro das regras do framework.

A frase que a Salesforce usa para descrever o benefício vale a pena ser citada como um princípio de design: uma única alteração atualiza tudo. Em vez de ajustar componentes individualmente, os styling hooks permitem ajustar valores em um único lugar para atualizações globais instantâneas.

Ao redor da arquitetura estão as mudanças visíveis. O Salesforce Cosmos é o novo tema padrão do SLDS 2, descrito como oferecendo espaçamento adaptável, visualizações rápidas, uma paleta de cores enriquecida, uma escala tipográfica amigável ao leitor e redução da carga cognitiva. O recurso expandido de Temas e Branding no Setup permite que administradores apliquem cores de marca, logotipos e imagens sem código, com nove novas opções de cores de destaque.

A divisão entre no-code e pro-code é deliberada e declarada: administradores têm design baseado em cliques, designers e desenvolvedores têm controle pro-code através dos styling hooks. Essa é uma decisão real de governança de design system — decidir qual público tem acesso a qual interface — e a maioria dos sistemas constrói apenas a metade pro-code.

Um detalhe merece destaque porque resolve um problema que quase todo design system possui e quase nenhum resolve adequadamente. A biblioteca do Figma do SLDS 2 usa a mesma convenção de nomenclatura semântica para styling hooks que o código usa — os próprios exemplos da Salesforce são radius-border-4 e font-scale-4 — portanto, os designs mapeiam um para um com o código vivo.

O efeito declarado é um vocabulário compartilhado que une design e desenvolvimento. O efeito prático é que o handoff de design deixa de ser um exercício de tradução. Quando um designer diz font-scale-4 e o desenvolvedor digita font-scale-4, toda a categoria de "qual cinza você quis dizer" desaparece.

A biblioteca também contém todas as variáveis e propriedades que você pode alternar, para que os componentes possam ser modificados diretamente no Figma, em vez de alternar entre o site de documentação e o arquivo de design e atualizar os componentes um por um. Esse é um pequeno detalhe de ferramenta com uma grande consequência comportamental: ele remove a fricção que faz com que designers abandonem o sistema.

O SLDS 2 entrega ferramentas que validam componentes com base nas regras do SLDS, em vez de apenas descrevê-los. O SLDS Linter é a ferramenta de análise de código; o SLDS Validator escaneia a marcação, a valida contra um banco de dados e oferece recomendações de correções. A Salesforce lista novos conjuntos de regras, orientações in-line e linting em massa.

Este é o mesmo instinto do kit de UI de apps da Stripe que recusa CSS arbitrário, alcançado por um caminho diferente. A Stripe remove a capacidade; a Salesforce não pode, porque o SLDS é CSS na org de um cliente e o cliente sempre pode escrever mais CSS. Então, ela faz a próxima melhor coisa e torna as violações visíveis mecanicamente.

A maioria das equipes tenta apenas a primeira linha. A linha do meio é onde o retorno sobre o esforço é maior, e é desinteressante o suficiente para raramente ser priorizada até que alguém conte quantos valores hexadecimais existem na base de código.

A descrição da Salesforce sobre o SLDS 2 é direta: ele é a base para o design system agentic para produtos Salesforce construídos na Lightning Platform. O blog que o anuncia diz que a nova arquitetura estabelece a base para experiências agentic e modo escuro, e descreve a reimaginação de como os design systems funcionam, tanto no fluxo de trabalho de design-desenvolvimento quanto em experiências de usuário geradas dinamicamente.

Essa última frase é a que devemos analisar. Experiências de usuário geradas dinamicamente. Não se trata de "IA ajuda desenvolvedores a escrever código mais rápido" — a própria interface é montada em tempo de execução, por usuário, por contexto, por algo que não foi um designer.

Se essa é a sua premissa, um design system que incorpora a aparência nas definições de componentes é estruturalmente incapaz de atendê-la, porque o gerador não tem nada para variar. O que uma interface gerada precisa é exatamente o que o SLDS 2 fornece: um vocabulário estrutural estável com as decisões visuais expostas como valores nomeados e configuráveis.

O SLDS 2 não é um caso isolado. Três dos maiores design systems enterprise publicados abertamente foram reestruturados em aproximadamente dezoito meses, cada um apostando de forma diferente na mesma premissa.

Ninguém coordenou isso. Três empresas com produtos e restrições diferentes chegaram a conclusões compatíveis no mesmo período, o que geralmente é um sinal de que a mudança subjacente é real, e não apenas uma moda.

A arquitetura do SLDS 2 é uma resposta ampla e específica a uma pergunta que a maioria das equipes ainda não fez: algo que não seja um designer consegue produzir uma interface alinhada à marca a partir do seu design system? Quatro pontos são transferíveis, independentemente da plataforma.

1. 1

   Separe a estrutura da aparência

   Toda decisão visual que atualmente é um valor literal dentro de uma regra de componente é uma decisão que um gerador não consegue variar e um cliente não consegue tematizar. Eleve-as para propriedades customizadas nomeadas. Este é um refactoring sem glamour, mas com um grande retorno, e também é o pré-requisito para o modo escuro.

2. 2

   Nomeie os hooks semanticamente e use os mesmos nomes na ferramenta de design

   radius-border-4 no Figma e radius-border-4 no CSS. Um vocabulário, duas renderizações. Cada incompatibilidade entre os nomes da ferramenta de design e os nomes do código é uma etapa de tradução onde o sentido se perde.

3. 3

   Imponha mecanicamente, não editorialmente

   Um linter que sinaliza um valor hex bruto em um pull request faz mais pela consistência do que qualquer quantidade de documentação. Se você não consegue construir um banco de dados de regras, comece com uma única regra proibindo valores de cores literais fora do arquivo de tokens.

4. 4

   Decida qual será a superfície no-code

   A Salesforce dividiu isso explicitamente: administradores tematizam com cliques, desenvolvedores tematizam com hooks. Se o seu sistema tem stakeholders que não são desenvolvedores e precisam alterar algo, dar a eles uma superfície delimitada é a maneira de evitar que peçam overrides pontuais.

Há um quinto ponto que o SLDS 2 não cobre, e é o que a maioria das equipes mais precisa. Hooks de estilização dizem a um gerador o que pode variar. Eles não dizem quais são os valores corretos, o que cada função significa ou o que é proibido.

Amostramos 299 arquivos DESIGN.md escritos para dar exatamente essa orientação a agentes de IA. 86% especificavam cores como hex bruto sem função semântica, 76% não continham proibições de qualquer tipo, 69% não mencionavam nada sobre modo escuro e 57% não definiam motifs. Um gerador que recebe um conjunto de hooks e esse arquivo terá uma API de tematização vazia e nenhum argumento sobre o que colocar nela.

A Salesforce deixa claro que a migração não é obrigatória e que as organizações podem adotá-la no seu próprio ritmo. O site do SLDS 2 possui um guia de Transição para o SLDS 2, e a documentação do SLDS 1 agora reside em v1.lightningdesignsystem.com em vez do domínio principal — algo importante se você tiver favoritos ou links em documentações internas apontando para as URLs antigas.

Se você mantém Lightning web components customizados, o linter é o ponto de partida sensato, independentemente de quando você migrar: execute-o, veja quanto do seu CSS está afirmando coisas que o framework deixará de afirmar e use esse número para dimensionar o trabalho com honestidade.