O design system do Linear, interpretado como restrições

Comece por aqui, pois a maior parte da confusão posterior vem de pular esta etapa. O Linear não publica um design system. Não existe @linear/tokens no npm, nem Storybook, nem site de documentação equivalente a um design.linear.app, nem biblioteca de Figma lançada pela empresa. Compare isso com o Carbon da IBM, o Polaris da Shopify ou o Salesforce Lightning, todos os quais entregam pacotes instaláveis e documentação pública como uma decisão deliberada de produto.

O que existe, em vez disso, são três tipos de materiais secundários, e vale a pena saber qual deles você está lendo:

A distinção importa porque uma extração pode dizer que uma superfície é #0f1011, mas não pode dizer se ela é um passo deliberado acima da tela ou apenas um acidente. Tudo abaixo é declarado no nível em que pode ser comprovado: padrões observáveis, com o raciocínio exposto para que você possa discordar dele.

Se você tirar apenas uma coisa daqui: a tipografia do Linear reside em uma faixa de pesos estreita, aproximadamente de 400 a 510, em praticamente todo o produto. Um título de 72px e um rótulo de 15px são diferenciados por tamanho e cor, não por peso. O negrito, no sentido de peso 700 que a maioria das interfaces utiliza, é funcionalmente ausente.

Essa única restrição faz mais trabalho visual do que a paleta. Uma faixa de pesos larga — corpo 400, rótulos 600, títulos 700, hero 800 — é o padrão que todo framework de UI entrega e que toda interface gerada por IA reproduz. Isso soa estridente e genérico, porque a hierarquia está sendo gritada em vez de composta. Uma faixa estreita força a hierarquia a ser carregada por tamanho, espaçamento e cor, o que é mais demorado para acertar e muito mais difícil de imitar acidentalmente.

O detalhe da fonte variável é o que torna o peso 510 possível. Um peso de 510 não é um corte estático; ele existe porque a interface usa uma tipografia variável onde qualquer valor no eixo está disponível. Tentar reproduzir isso com pesos estáticos resulta em 500, o que é próximo, e esse pequeno erro é parte do motivo pelo qual as replicações parecem "quase certas".

Este é o detalhe que a maioria das reproduções ignora completamente, e é algo mensurável, não uma questão de gosto. O espaçamento entre letras no Linear torna-se negativo conforme o tamanho aumenta: tipos de exibição na faixa de 48–72px ficam em torno de -0.022em, títulos de médio porte em torno de -0.012em e tipos de corpo em torno de -0.010em. A relação é monotônica — quanto maior o tipo, mais apertado o tracking.

O motivo é óptico, não decorativo. Formas de letras desenhadas para serem legíveis a 16px possuem sidebearings dimensionados para 16px. Ao escalá-las para 64px, esses espaços também escalam, fazendo com que a palavra visualmente se desintegre em letras. O design tipográfico profissional compensa isso com tamanhos ópticos; o trabalho de interface compensa com uma rampa de tracking. A maioria dos design systems define um único valor de letter-spacing, ou nenhum, e seus títulos ficam com um aspecto "solto" que ninguém sabe nomear.

/* The ramp, expressed as tokens. Values shown are the pattern,
   not Linear's — pick your own by eye at each step. */
:root {
  --tracking-display: -0.022em;  /* 48px and up */
  --tracking-heading: -0.012em;  /* 20-32px */
  --tracking-body:    -0.010em;  /* 13-17px */
  --tracking-label:    0.02em;   /* small caps, 11-12px: loosens */
}

Note a inversão na parte inferior. Rótulos pequenos em caixa alta exigem tracking positivo pelo mesmo motivo óptico que tipos de exibição grandes exigem tracking negativo. Uma rampa que segue apenas uma direção é apenas metade da regra.

O Linear separa superfícies com bordas de larguras sub-pixel — 0.5px em telas que suportam essa renderização — e um conjunto escalonado de cinzas quase pretos, em vez de drop shadows. O canvas fica em aproximadamente #08090a, as superfícies de cards um degrau acima, por volta de #0f1011, e painéis elevados acima disso. As bordas utilizam um cinza de baixo contraste em torno de #23252a para arestas estruturais, com um degrau ligeiramente mais claro para separadores de seção.

Este é um trade-off genuíno, não necessariamente uma escolha superior, e vale a pena ser honesto sobre o custo. Sombras comunicam profundidade de forma pré-atentiva; o leitor sabe que um card está acima da página sem precisar analisá-lo. Hairlines não fazem isso. O que você ganha é uma superfície plana, densa e precisa, onde muita informação pode coexistir proximamente sem ruído visual — que é exatamente o que um rastreador de issues precisa e exatamente o que um site de marketing não precisa.

Essa última linha é a que deve nortear a ação. O motivo pelo qual um tratamento estilo Linear frequentemente falha em uma landing page não é porque foi mal executado; é porque a estratégia de elevação foi escolhida para densidade de informação e então aplicada a uma superfície com apenas quatro cards.

A observação sobre cores que as pessoas repetem é que "o Linear é roxo". No momento da escrita, a interface observável parece mais um quase-monocromático com um único acento de alta croma usado para a ação primária e estado ativo, além de um pequeno conjunto de preenchimentos cromáticos reservados para tags e rótulos. O matiz específico do acento mudou entre os redesigns; o fato estrutural, não.

O fato estrutural é uma proporção. O acento aparece em uma pequena porcentagem de pixels — um botão primário, um indicador de navegação ativo — e todo o resto é cinza. Copiar o matiz e aplicá-lo na densidade típica de um SaaS (títulos com acento, ícones com acento, links com acento, bordas com acento, hero com gradiente de acento) produz algo que compartilha a paleta do Linear, mas nada de seu caráter.

As cores das tags merecem ser separadas porque são um sistema diferente. Alguns preenchimentos cromáticos — um violeta, um teal, um coral, um verde — existem para tornar os rótulos distinguíveis à primeira vista, da mesma forma que séries categóricas funcionam em uma paleta de dashboard. Elas não são cores de marca nem cores de status; um sistema que confunde as três acaba incapaz de mostrar um erro em vermelho porque o vermelho já significa "marketing" em algum rótulo.

Os raios são reduzidos — aproximadamente 6px em controles e 12px em containers maiores — contrastando com o hábito do ecossistema de usar rounded-lg ou superior em tudo. O padding é compacto, na faixa de 8–12px para controles, em vez dos 16–24px que a maioria das bibliotecas de componentes entrega.

Ambos derivam da mesma fonte que as hairlines: densidade. Uma ferramenta densa não pode gastar 24px de padding por controle, e raios grandes em elementos pequenos começam a "comer" o elemento. A regra subjacente não é "use 6px" — é que o raio deve escalar com o elemento, enquanto a maioria dos sistemas aplica um único token de raio tanto a um botão de 28px quanto a um painel de 400px.

Copiar isso é o resultado errado, e não apenas por questões de marca registrada. Um design system é consequência de uma decisão de produto. A densidade do Linear serve a pessoas que vivem em um rastreador de issues por seis horas por dia; esse usuário tem necessidades diferentes de alguém que acessa uma página de preços por quarenta segundos. Transportar o tratamento de superfície através desse abismo resulta em uma interface otimizada para um trabalho que seu produto não realiza.

O que é transferível é o método. Cada observação acima tem a mesma forma: notar um padrão, deduzir a restrição que o produz e, então, escrever essa restrição como uma regra. Esse é um exercício repetível que você pode aplicar a qualquer produto que admire, e é isso que transforma um mood board em algo que um agente consegue executar.

1. 1

   Tire print de três telas, não de uma

   Uma única tela revela a paleta. Três revelam quais decisões são consistentes — e a consistência é o que distingue um sistema de uma página.

2. 2

   Meça, não tente estimar no olho

   Abra as dev tools e leia os valores computados: font-weight, letter-spacing, border-width, border-radius, padding. Anote os números reais. "Tight tracking" não é uma regra; -0.022em acima de 48px é.

3. 3

   Procure o intervalo, não o valor

   O insight raramente é um número único. É que todos os pesos ficam entre 400 e 510, ou que cada raio é 6 ou 12 e nada mais. Intervalos são regras; valores únicos são amostras.

4. 4

   Anote o que está ausente

   Sem sombras. Sem pesos acima de 510. Sem um segundo acento. Sem gradientes. As ausências são a parte de maior valor de um teardown e a parte que nunca sobrevive a uma exportação de paleta.

5. 5

   Converta cada observação em uma instrução

   "A elevação usa uma borda de 1px e um degrau de superfície, nunca um box-shadow" é executável. "Minimalista e preciso" não é. Este é o passo onde um teardown se torna um design system.

Amostramos 299 arquivos DESIGN.md publicados em repositórios e diretórios públicos para ver o que as diretrizes de design realmente contêm quando são escritas para serem lidas por um agente de IA. Os resultados explicam por que sistemas derivados de teardowns degradam.

Três quartos desses arquivos não contêm proibições. Mas, como mostra o teardown acima, as proibições são onde a identidade reside — sem negrito, sem sombras, sem um segundo acento. Um arquivo que lista os valores hex da Linear e omite suas restrições capturou a parte menos distintiva do sistema e descartou o resto.

O número de adjetivos vagos agrava a situação. "Clean" aparece em 39% desses arquivos e "modern" em 36%. Ambos são palavras que um modelo satisfará alegremente com a média de seus dados de treinamento, que é a razão pela qual interfaces geradas por IA convergem para o mesmo visual. Nenhuma das palavras impõe restrições.

Se o output de um teardown for para um agente de código, ele precisa sobreviver ao ser lido uma vez e aplicado em dezenas de arquivos. Isso significa tokens nomeados com propósitos declarados e uma lista de proibições explícita. Aqui está o formato:

## Type

Weights: 400 and 510 only. Never use 600 or above; hierarchy is
carried by size and colour, not weight.

Tracking ramps with size:
- 48px and up: -0.022em
- 20-32px:     -0.012em
- 13-17px:     -0.010em
- 11-12px uppercase labels: +0.02em

## Elevation

Never use box-shadow. Elevation is a surface step plus a 1px border:
- canvas   -> surface   -> elevated
- Border: --border-subtle for structure, --border-strong for sections

## Accent

One accent. It appears on primary buttons and active nav state only.
Do NOT use the accent for headings, links, icons, borders or gradients.
Tag fills are a separate categorical set and are not brand colour.

## Never

- No gradients
- No drop shadows
- No second accent colour
- No font-weight above 510
- No border-radius above 12px

Note quanto desse arquivo é a seção Never e as proibições inseridas em cada regra. Esse ratio é o ponto central. Se você entregar a um agente uma paleta e um nome de fonte, você deu a ele permissão para fazer todo o resto como quiser, e o resto é a maior parte da interface.

Existe uma versão deste exercício que produz algo pior do que o que você começou. Isso acontece quando o teardown se torna o objetivo: você monta um conjunto rigoroso de regras descrevendo o produto de outra pessoa, entrega a um agente e recebe de volta uma imitação competente sem razão para existir.

Design systems que são realmente bons são o resultado de um argumento sobre o leitor. O da Linear é o argumento de que um power user em uma ferramenta o dia todo quer densidade e sobriedade. Um produto de aprendizado pode argumentar por espaçamento generoso e calor. Um dashboard financeiro pode argumentar por cores de status reservadas e uma escala neutra que sobreviva a uma tabela densa. As regras derivam do argumento; elas não o substituem.

Portanto, use o teardown para calibração, não para conteúdo. Ele diz como é um sistema rigoroso — o quão específicos são os números, quantas coisas são proibidas, quão estreitos são os intervalos. Então, vá construir o seu próprio argumento sobre o seu próprio produto.