Escolher uma cor bonita não é o trabalho. O trabalho começa quando você precisa fazer essa cor funcionar em um botão desabilitado, um estado de hover, um modo escuro, um componente de alerta — e tudo isso precisa ser consistente, acessível e documentado para que o time de desenvolvimento implemente exatamente o que foi desenhado.
É aí que a maioria dos projetos quebra. Não pela falta de talent visual, mas pela falta de um sistema. Uma paleta de cores para design system não é uma coleção de tons que combinam. É uma infraestrutura que determina como a cor se comporta em qualquer contexto do produto.
Este guia cobre o processo completo: da Key Color à exportação em Tailwind e CSS Variables, com decisões técnicas que você pode aplicar hoje.
O que é uma paleta de cores para design system?
Uma paleta de cores para design system é uma escala estruturada de tons gerada a partir de uma ou mais cores-base, nomeada com convenções padronizadas e exportada como variáveis reutilizáveis tanto no design quanto no código. Ela define não apenas quais cores existem no produto, mas onde cada tom pode ser usado, com qual função e com quais restrições de acessibilidade.
Diferente de uma paleta visual comum — uma seleção de cores que “combinam” — a paleta de design system tem três camadas:
Escala primitiva: os tons brutos numerados de 50 a 950, gerados algoritmicamente a partir da cor-base. Nenhuma dessas variáveis é usada diretamente nos componentes.
Tokens semânticos: variáveis com nome funcional que referenciam a escala primitiva. color.button.primary.background aponta para brand-600. Esses são os tokens que os componentes consomem.
Documentação de uso: regras que definem quais tons são permitidos em quais contextos, garantindo que qualquer pessoa do time tome decisões cromáticas consistentes sem precisar reinventar a roda a cada componente novo.
Por que a escala 50-900 se tornou o padrão do mercado
Antes de o Tailwind CSS popularizar o modelo numérico, o jeito mais comum de nomear variações de cor era com sufixos como -light, -dark, -muted. O problema é que esses nomes são relacionais, não absolutos. O que é “light” depende do contexto — e quando o sistema cresce, os nomes deixam de fazer sentido.
A lógica matemática por trás dos números
O modelo numérico resolve isso com uma progressão de luminância padronizada. Cada número representa um ponto fixo na escala de claro para escuro, independente do matiz. O 50 é sempre o tom mais claro (quase branco para paletas saturadas). O 950 é sempre o mais escuro (quase preto). O 500 é, convencionalmente, o tom central — onde reside a identidade da cor.
Essa progressão não é linear. Os números não são calculados em passos iguais de brilho. Algoritmos como o do Tailwind CSS usam curvas de luminância calibradas para que a diferença perceptual entre cada passo seja visualmente consistente — o salto de 100 para 200 parece o mesmo que o salto de 700 para 800 para o olho humano, mesmo que os valores matemáticos sejam diferentes.
Como o Tailwind CSS popularizou esse modelo
O Tailwind não inventou as escalas tonais, mas foi o primeiro framework a torná-las o padrão de fato para desenvolvimento web. Quando o Tailwind lançou sua paleta com 11 tons por cor (do 50 ao 950), milhões de projetos passaram a usar essa nomenclatura. Isso criou uma convenção de mercado: hoje, qualquer desenvolvedor que trabalha com Tailwind entende imediatamente o que brand-700 significa sem precisar de documentação adicional.
O resultado prático para quem cria design systems no Figma é que a escala 50-950 virou uma língua comum entre design e desenvolvimento. Usar essa mesma nomenclatura elimina uma camada inteira de tradução no handoff.
Como criar sua paleta de cores em 5 passos
Passo 1 — Defina a Key Color (cor-chave da marca)
A Key Color é o tom que representa a identidade visual da marca — geralmente o que aparece no logo principal. Ela não precisa ser exatamente o tom 500 da escala final, mas é o ponto de partida do algoritmo.
Antes de escolher a Key Color, responda duas perguntas:
Qual é o contexto de uso predominante? Se o produto é usado em ambientes escuros ou a noite (apps de produtividade, plataformas de dados), tons com saturação média funcionam melhor que cores vibrantes, que causam fadiga visual. Se o produto é um marketplace de consumo ou e-commerce, tons mais saturados criam mais energia e senso de ação.
Quais são as restrições de acessibilidade? Produtos com requisito WCAG AA precisam garantir contraste 4.5:1 entre texto e fundo. Isso afeta diretamente quais tons da escala podem ser usados para tipografia — e isso é um dado que você precisa saber antes de começar a gerar a escala, não depois.
Passo 2 — Gere a escala algorítmica
Com a Key Color definida, o próximo passo é gerar a progressão completa de 50 a 950. Fazer isso manualmente — ajustando luminosidade e saturação um tom de cada vez — é impraticável e propenso a inconsistências.
Use nosso gerador de paleta de cores para design system para gerar a escala completa a partir da sua Key Color. Insira o código HEX, selecione o algoritmo Tailwind CSS para compatibilidade máxima com projetos web modernos, e defina o Naming Pattern como 50, 100...900. O gerador produz os 11 tons com progressão matematicamente calibrada — e já entrega o código pronto para CSS Variables, Tailwind config e Design Tokens W3C.
Passo 3 — Atribua função a cada faixa de tons
Gerar a escala é técnico. Atribuir função é estratégico. Cada faixa de tons tem um papel específico na interface:
| Faixa | Função principal | Exemplos de uso |
|---|---|---|
| 50 a 100 | Superfícies e backgrounds sutis | Fundo de página, fundo de inputs desabilitados |
| 200 a 300 | Bordas, separadores, estados desabilitados | Border de cards, placeholder text |
| 400 a 500 | Cor de identidade, ícones secundários | Badges, tags, ícones de suporte |
| 500 a 600 | Cor principal de ação | Botão primário, links, estado ativo |
| 700 a 800 | Hover, estados pressionados, texto sobre fundo claro | Hover de botão, texto de link |
| 900 a 950 | Tipografia de alto contraste, estado de foco | Texto em fundo branco, outline de foco |
Uma observação importante: o tom 500 não é necessariamente o que você usa no botão primário. Em paletas com saturação alta, o 500 pode falhar nos requisitos de contraste WCAG quando usado com texto branco. Teste antes de fixar.
Passo 4 — Crie a camada de tokens semânticos
A escala primitiva (50 a 950) nunca deve ser consumida diretamente pelos componentes. O que os componentes consomem são design tokens semânticos — variáveis com nomes que descrevem a função, não o valor.
A estrutura recomendada pelo W3C Design Tokens Community Group usa dois níveis:
Nível 1 — Tokens de escala (primitivos):
css
:root {
--brand-50: #f0f4ff;
--brand-100: #e0e9ff;
--brand-500: #4f6ef7;
--brand-600: #3a56d4;
--brand-700: #2a3fa8;
--brand-900: #1a2563;
}Nível 2 — Tokens semânticos (funcionais):
css
:root {
--color-action-primary: var(--brand-600);
--color-action-primary-hover: var(--brand-700);
--color-action-primary-text: #ffffff;
--color-surface-base: var(--brand-50);
--color-border-subtle: var(--brand-100);
}O componente de botão referencia --color-action-primary, não --brand-600. Isso significa que se a marca mudar a cor primária de azul para verde, você altera apenas o token primitivo e os componentes todos atualizam em cascata — sem tocar em nenhum arquivo de componente.
Passo 5 — Valide o contraste antes de implementar
Toda paleta precisa passar por validação de contraste antes de ir para código. As diretrizes WCAG definem dois níveis mínimos:
WCAG AA — 4.5:1 para texto normal, 3:1 para texto grande. Este é o requisito mínimo para a maioria dos produtos digitais.
WCAG AAA — 7:1 para texto normal. Necessário em produtos financeiros, de saúde ou governamentais.
Os pares mais críticos para validar:
- Texto escuro sobre fundo claro (ex:
brand-900sobrebrand-50) - Texto de label sobre botão de ação (ex:
#ffffffsobrebrand-600) - Texto de placeholder sobre fundo de input (ex:
brand-400sobrebrand-50) - Ícone de status sobre superfície (ex: tom de feedback sobre
brand-100)
Se algum par falhar, ajuste o Contrast Shift no gerador e regere a escala antes de exportar. Descobrir problemas de contraste depois que os componentes foram implementados custa muito mais tempo do que descobrir na fase de escala.
Como exportar sua paleta para Tailwind e CSS Variables
Com a escala validada, o passo seguinte é transformar os tokens em código. O gerador entrega os três formatos principais prontos para copiar.
Tailwind CSS v3 — tailwind.config.js
No Tailwind v3, as cores customizadas são declaradas no tailwind.config.js dentro de theme.extend.colors. Isso preserva as cores padrão do Tailwind e adiciona suas cores de marca:
js
// tailwind.config.js
module.exports = {
theme: {
extend: {
colors: {
brand: {
50: '#f0f4ff',
100: '#e0e9ff',
200: '#c7d7fe',
300: '#a5bbfd',
400: '#7c97fb',
500: '#4f6ef7',
600: '#3a56d4',
700: '#2a3fa8',
800: '#1e2d7a',
900: '#151f52',
950: '#0d1233',
},
},
},
},
}Com isso, você terá disponíveis classes como bg-brand-600, text-brand-900, border-brand-200 em todo o projeto.
Tailwind CSS v4 — CSS Variables nativas com @theme
O Tailwind v4 mudou o modelo de configuração. As cores agora são definidas como CSS Variables dentro do bloco @theme no arquivo CSS principal, sem necessidade de tailwind.config.js:
css
@import "tailwindcss";
@theme {
--color-brand-50: #f0f4ff;
--color-brand-100: #e0e9ff;
--color-brand-200: #c7d7fe;
--color-brand-300: #a5bbfd;
--color-brand-400: #7c97fb;
--color-brand-500: #4f6ef7;
--color-brand-600: #3a56d4;
--color-brand-700: #2a3fa8;
--color-brand-800: #1e2d7a;
--color-brand-900: #151f52;
--color-brand-950: #0d1233;
}A vantagem do v4 é que essas variáveis também ficam disponíveis nativamente no CSS, sem necessidade de declaração dupla. var(--color-brand-600) funciona em qualquer propriedade CSS do projeto.
tailwind.config.js.CSS Variables puras — compatível com qualquer framework
Se o projeto não usa Tailwind, a abordagem de CSS Variables puras é universalmente compatível com React, Vue, Angular, Svelte e qualquer outro framework:
css
:root {
/* Escala primitiva */
--brand-50: #f0f4ff;
--brand-100: #e0e9ff;
--brand-200: #c7d7fe;
--brand-300: #a5bbfd;
--brand-400: #7c97fb;
--brand-500: #4f6ef7;
--brand-600: #3a56d4;
--brand-700: #2a3fa8;
--brand-800: #1e2d7a;
--brand-900: #151f52;
--brand-950: #0d1233;
/* Tokens semânticos */
--color-action-primary: var(--brand-600);
--color-action-primary-hover: var(--brand-700);
--color-surface-base: var(--brand-50);
--color-border-default: var(--brand-200);
--color-text-primary: var(--brand-900);
--color-text-secondary: var(--brand-700);
}Para dark mode, você adiciona um segundo bloco que sobrescreve apenas os tokens semânticos — a escala primitiva permanece a mesma:
css
[data-theme="dark"] {
--color-action-primary: var(--brand-400);
--color-action-primary-hover: var(--brand-300);
--color-surface-base: var(--brand-950);
--color-border-default: var(--brand-800);
--color-text-primary: var(--brand-50);
--color-text-secondary: var(--brand-200);
}O componente de botão não precisa saber se o modo escuro está ativo. Ele sempre lê --color-action-primary e o sistema cuida do valor correto.
Erros comuns ao criar uma paleta para design system
Usar a Key Color diretamente no tom 500. O tom 500 da escala é calculado pelo algoritmo com base na progressão de luminância — ele pode não ser idêntico à cor do logotipo. Isso é esperado. Não force o encaixe; deixe o algoritmo trabalhar e ajuste o token semântico para apontar para o tom que melhor representa a marca em contexto real.
Criar a paleta no escuro. Paleta nunca se valida em isolamento. Sempre aplique os tons em componentes reais — botão, input, card, badge — antes de considerar a escala finalizada. Tons que parecem certos na escala abstrata frequentemente revelam problemas de contraste ou de legibilidade quando aplicados.
Pular a camada de tokens semânticos. É tentador usar --brand-600 diretamente nos componentes. O problema aparece na primeira mudança de marca ou na primeira vez que você implementa dark mode. Sem a camada semântica, você vai precisar rastrear e atualizar cada referência individualmente — um trabalho de horas que devia ser de segundos.
Criar uma paleta só de tons primários. Um design system completo precisa de pelo menos três escalas: primária (cor da marca), neutra (cinzas para texto e superfície) e de feedback (vermelho, verde, amarelo para estados de erro, sucesso e alerta). Começar só pela primária e “resolver o resto depois” resulta em inconsistência nas cores de feedback.
Não documentar as restrições de uso. Gerar a escala e exportar os tokens é metade do trabalho. A outra metade é documentar: quais tons são permitidos para tipografia, quais são exclusivos de superfície, quais têm restrição de contraste em determinados contextos. Sem isso, cada desenvolvedor toma suas próprias decisões — e a consistência do sistema se dissolve em semanas.
Da paleta ao design system: o próximo passo
Uma paleta de cores bem estruturada é a fundação, não o destino. Com a escala gerada e os tokens semânticos definidos, o próximo passo é integrá-los aos componentes — botões, inputs, cards, badges, modais — e documentar as regras de uso para todo o time.
Para projetos que estão começando o design system do zero, use nosso gerador de paleta de cores para criar sua escala primária, de feedback e neutra. Exporte os três conjuntos em CSS Variables, configure os tokens semânticos e teste os pares de contraste antes de implementar qualquer componente.
Se o design system já existe mas a paleta está desorganizada — sem nomenclatura padronizada, sem tokens semânticos, com valores HEX espalhados pelo código — o processo começa por uma auditoria. Identificar o estado atual é o primeiro passo para saber o que reorganizar e em que ordem.
A CamaraUX trabalha com equipes nesse processo: da documentação de design e handoff à estruturação de tokens e componentes. Se o seu time está nesse momento, fale com a gente — sem compromisso, só para entender o contexto do projeto.
Perguntas frequentes sobre paleta de cores para design system
O que é uma Key Color em design system?
Key Color é a cor-base usada como ponto de partida para gerar a escala algorítmica. Ela representa a identidade visual da marca e serve de input para o algoritmo de geração de tons. A Key Color não precisa ser idêntica ao tom 500 da escala final — ela é o parâmetro de entrada, e o algoritmo calcula os 11 tons a partir das suas propriedades de matiz, saturação e luminância.
Quantas paletas preciso criar para um design system completo?
No mínimo três: uma paleta primária (cor da marca), uma paleta neutra (tons de cinza para texto, fundos e bordas) e uma paleta de feedback (vermelho para erro, verde para sucesso, amarelo/laranja para alerta e azul para informativo). Projetos maiores adicionam uma paleta secundária ou de acento para estados especiais e componentes de destaque.
Qual a diferença entre tom primitivo e token semântico?
Tom primitivo é o valor bruto da escala — brand-600: #3a56d4. Token semântico é uma variável que referencia o primitivo e descreve a função — color.button.primary.background: var(--brand-600). Os componentes sempre consomem tokens semânticos, nunca primitivos diretamente. Isso permite trocar a cor de toda uma categoria de componentes em um único lugar.
Posso usar a paleta gerada em projetos com dark mode?
Sim. A escala 50-950 foi projetada para suportar dark mode. Em vez de criar uma segunda escala, você inverte a hierarquia de tokens semânticos: no modo claro, surface.base aponta para brand-50; no modo escuro, aponta para brand-950. Os componentes leem sempre o token semântico e o sistema entrega o valor correto para cada tema automaticamente.
Como validar se a paleta atende ao WCAG AA?
Teste os pares de cor mais críticos: texto sobre fundo de página, label sobre botão, texto sobre input. A proporção mínima é 4.5:1 para texto normal e 3:1 para texto grande. Nosso gerador de paleta permite ajustar o Contrast Shift para calibrar a separação entre tons antes de exportar, facilitando atingir os requisitos de contraste sem ajustes manuais posteriores.
Devo usar Tailwind v3 ou v4 para gerenciar tokens de cor?
Se o projeto está começando do zero em 2025, use Tailwind v4. A abordagem com @theme e CSS Variables nativas elimina a necessidade de tailwind.config.js e torna os tokens disponíveis tanto nas classes utilitárias do Tailwind quanto em qualquer propriedade CSS customizada. Para projetos existentes em v3, a migração de cores é simples — mas avalie se os outros breaking changes do v4 fazem sentido para o contexto do projeto antes de migrar.
