Encore: como é um design system em 45 plataformas

Em 2019, a liderança do Spotify decidiu tornar o áudio disponível e consistente em qualquer dispositivo. O número publicado pela equipe de design é impressionante: 45 plataformas únicas e mais de 2.000 tipos de dispositivos em 200 marcas. Alguém inicia uma playlist em uma televisão na sala, continua no carro e a retoma em um laptop na manhã seguinte.

Isso não é apenas uma versão maior do problema comum de design systems. É um problema diferente. Uma televisão é vista a três metros de distância, um relógio precisa condensar tudo, um desktop tem espaço de sobra e um carro possui restrições legais de interação. Nenhuma biblioteca de componentes isolada consegue atender a tudo isso, e nenhuma quantidade de documentação fará com que isso aconteça.

O Encore foi lançado com dois segmentos. O Encore Consumer Mobile foi descrito como incrivelmente flexível, um vasto catálogo de componentes em constante crescimento para experiências focadas em mobile. O Encore Web atendia a uma gama mais ampla de produtos web. Abaixo de ambos, ficavam os design tokens cobrindo decisões fundamentais, como esquemas de cores e estilos tipográficos.

O modelo publicado é concêntrico. A fundação está no centro. Web e Mobile ficam acima dela como subsistemas equivalentes com paridade de plataforma. Mais externamente, ficam os subsistemas mais especializados — Content Web Platform, Advertising Web, Consumer Mobile — cada um cada vez mais divergente do núcleo.

O valor desse formato é que a divergência é limitada e localizada. Um componente que apenas a publicidade necessita vive no anel de publicidade, onde não pode vazar para o app do consumidor. Uma decisão de cor vive na fundação, onde não pode ser sobrescrita localmente. A alternativa — uma única biblioteca plana servindo a todos — força cada necessidade especializada a ser absorvida pelo núcleo, inchando-o, ou a ser construída fora do sistema, que é onde os design systems morrem.

Aqui está a parte que é rara em textos publicados sobre design systems, porque é uma admissão. Em 2022, a equipe julgou que o pêndulo havia oscilado demais para a flexibilidade e que uma recalibragem era necessária.

O que aconteceu é algo reconhecível. O Consumer Mobile era deliberadamente flexível, então as equipes de produto solicitavam componentes cada vez mais refinados, e ele continuava aceitando. A flexibilidade que começa como um recurso torna-se uma obrigação: a necessidade específica de cada equipe vira mais um componente de responsabilidade do sistema, e o catálogo cresce mais rápido do que qualquer pessoa consegue manter coerente.

A correção do Spotify é a jogada interessante. Eles não restringiram o Consumer Mobile nem começaram a rejeitar solicitações. Eles montaram uma equipe para construir componentes reutilizáveis para o Encore Mobile — inserindo uma nova camada entre o Consumer Mobile e a fundação. A descrição publicada de seu propósito é precisa: ele atua como uma primeira linha de defesa, reduzindo a demanda para que o Consumer Mobile forneça cada componente individualmente, ao mesmo tempo em que cria maior paridade de plataforma em todo o restante do sistema.

Isso reformula um problema de governança como um problema estrutural. Quando um subsistema recebe solicitações que não são realmente específicas para ele, as solicitações não são o problema — a camada compartilhada ausente é. Dizer não teria empurrado essas equipes a construir fora do sistema. Adicionar a camada capturou esse trabalho.

O relato da equipe sobre o processo de trabalho é concreto o suficiente para ser copiado, e a mudança crucial que eles mencionam é que os componentes multiplataforma agora são projetados como multiplataforma desde o início, em vez de serem tratados como um detalhe posterior.

1. 1

   Reúna todas as plataformas na sala

   Representantes de iOS, Android e Web juntos, antes de qualquer coisa ser projetada. O argumento deles sobre por que isso é necessário é convincente: é raro encontrar alguém especialista tanto em web quanto em mobile, portanto, a expertise deve ser reunida, e não presumida.

2. 2

   Cada plataforma audita e diagrama o que é único em sua superfície

   O Desktop tem mais espaço disponível. A televisão é diferente devido à distância de visualização. Um relógio exige que todas as informações sejam condensadas. Isso é estabelecido como fatos sobre a superfície antes que qualquer pessoa discuta sobre o componente.

3. 3

   Alinhe termos, estados e interação de propriedades

   O grupo de trabalho define como as coisas são chamadas, quais estados existem e como as propriedades se combinam. Este é o passo que costuma ser ignorado, e ignorá-lo é a razão pela qual duas plataformas acabam com um componente que compartilha o nome e nada mais.

4. 4

   Projete o componente considerando tudo isso simultaneamente

   Não a versão de uma plataforma com adaptações. Um único componente cujas variantes já eram conhecidas antes de ser desenhado.

O passo três é aquele que vale a pena copiar, independentemente de quantas plataformas você tenha. A maior parte do desvio de componentes começa como um desvio de vocabulário: o "secundário" de uma equipe é o "ghost" de outra, o estado desativado de uma equipe é o somente leitura de outra e, quando alguém percebe, ambos já foram implementados.

Ao pesquisar pelo design system do Spotify, uma das primeiras coisas que você encontra são as Diretrizes de Design e Branding públicas do Spotify no site para desenvolvedores. Vale ressaltar que isso não é o Encore e não é um design system no sentido usual. É um documento de conformidade.

Sua estrutura o denuncia: atribuição, uso de conteúdo do Spotify, navegação de conteúdo, links para o Spotify, visualizações de reprodução, exibição de entidades, uso do logotipo, uso das cores, restrições de logotipo e nomenclatura, fontes. A razão declarada para as regras de atribuição é que o conteúdo disponível através do Spotify pertence a muitos detentores de direitos diferentes, portanto, qualquer uso de metadados do Spotify — nomes de artistas, álbuns e faixas, artes, reprodução de áudio — deve ser acompanhado pela marca Spotify. A página afirma que o uso dos recursos implica a aceitação dos Termos de Serviço do Desenvolvedor.

A distinção é importante se você estiver construindo algo que integre o conteúdo ou a marca de terceiros. Essas regras são contratuais, e "ficou melhor sem o logotipo" não é uma justificativa. Também importa como categoria: se o seu produto é consumido por produtos de outras pessoas, você pode precisar deste documento além de um design system, e eles não são o mesmo tipo de trabalho de redação.

O modelo concêntrico transfere-se diretamente para a orientação de design escrita para agentes de código de IA, e resolve um problema que surge assim que um projeto possui mais de um tipo de superfície.

A falha comum é ter um único DESIGN.md que tenta cobrir um site de marketing, o shell de um aplicativo e uma tabela de dados densa. Suas regras acabam sendo ambíguas — "espaçamento generoso, embora tabelas possam ser mais densas" — e uma regra ambígua não é uma regra. O modelo precisa decidir, e ele decide de forma diferente a cada vez.

A estruturação em camadas funciona da mesma forma que o Encore:

# DESIGN.md          <- foundation: tokens, roles, prohibitions
                        applies everywhere, never overridden

# app/marketing/DESIGN.md
   Extends the root. Spacing scale shifted up one step.
   Hero type may use the display scale (48px+).
   Cards may use shadow elevation.

# app/dashboard/DESIGN.md
   Extends the root. Compact spacing (8-12px controls).
   Elevation is surface steps + hairline, never shadow.
   Table rows: 32px, no vertical padding above 8px.

Cada arquivo é objetivo dentro de seu escopo. A raiz contém apenas o que genuinamente não deve variar — papéis de cores, família tipográfica, proibições — e as folhas contêm as decisões que legitimamente diferem. Um agente trabalhando em app/dashboard/ lê dois arquivos e obtém uma resposta única e inequívoca, em vez de um arquivo com ressalvas.

Amostramos 299 arquivos DESIGN.md publicados para leitura de agentes. 44% não continham nenhum valor de tamanho concreto e 54% dependiam de pelo menos um adjetivo vago — "clean" em 39%, "moderno" em 36%. Esse é o problema da ambiguidade em seu extremo: um arquivo que nunca se compromete com um número não pode entrar em conflito consigo mesmo, mas também não consegue produzir uma interface consistente.

Você provavelmente não tem 45 plataformas. Pode ser que tenha três superfícies, duas das quais divergiram silenciosamente, e uma equipe que continua pedindo um componente que ninguém mais quer. Esse é o mesmo problema em uma amplitude menor, e as respostas do Encore se aplicam a esse tamanho.

Coloque o que não deve variar em uma fundação e torne isso genuinamente imutável. Deixe que necessidades especializadas vivam em camadas especializadas, em vez de forçá-las para o núcleo ou para fora do sistema completamente. Quando uma camada estiver sobrecarregada de solicitações, procure a camada ausente abaixo dela antes de começar a recusar. E projete para todas as superfícies ao mesmo tempo, porque um componente adaptado posteriormente é um componente que irá divergir.