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 sensibilidade 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 organiza famílias, tons e regras de aplicação, com nomes reutilizáveis no design e no código. Ela pode combinar curadoria manual e geração assistida. 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: valores de referência numerados de 50 a 950 que podem ser curados manualmente ou gerados com ferramentas. Em produtos com temas, recomenda-se associar esses valores a tokens semânticos.
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 usar a escala de cores 50–950?
A convenção numérica organiza uma família do claro ao escuro. Na documentação atual do Tailwind, são 11 tons: 50, 100, 200, 300, 400, 500, 600, 700, 800, 900 e 950. A numeração facilita o handoff, mas não determina, por si, contraste, função semântica nem adequação ao produto.
Os números são medidas de contraste?
Não. O 50 é o extremo mais claro de uma família e o 950, o mais escuro; o 500 pode ou não coincidir com a cor principal da marca. Diferentes famílias têm cromas e contrastes distintos. A equipe precisa testar cada par de cor em contexto, não assumir que o tom 600 funciona para todos os botões.
Existe um algoritmo oficial para gerar a paleta do Tailwind?
O guia oficial do Tailwind v3 relata que suas cores padrão foram equilibradas manualmente. Ferramentas podem produzir escalas compatíveis com a nomenclatura Tailwind, mas não reproduzem automaticamente as cores oficiais. A versão 4 usa valores em oklch() para sua paleta padrão.
O ganho real da escala está na comunicação com desenvolvimento e na definição de tokens semânticos. Como mostra o IBM Carbon, os tokens por função são o elo entre paleta, temas e componentes.
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 — Construa e revise os 11 tons
Partindo da Key Color, esboce os valores de 50 a 950. É possível gerá-los em uma ferramenta, criar manualmente ou combinar as duas abordagens. Revise a separação visual entre os tons e o comportamento nos componentes: nenhum algoritmo substitui a avaliação do contexto real.
No gerador de paletas da CamaraUX, informe o HEX, selecione uma geração compatível com a escala numérica do Tailwind, revise os resultados e escolha a saída de CSS, Tailwind ou design tokens adequada ao projeto. Os tons gerados pela ferramenta não são cópias oficiais da paleta padrão do Tailwind.
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 | Uso possível | Validação importante |
|---|---|---|
| 50–100 | Superfícies claras | Contraste com elementos próximos |
| 200–300 | Separadores e superfícies secundárias | Legibilidade de bordas quando necessárias |
| 400–500 | Destaques e detalhes | Não presumir contraste suficiente para texto |
| 600–700 | Possíveis ações e links | Texto, hover e foco em contexto |
| 800–950 | Textos escuros e superfícies escuras | Temas e estados reais |
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 — Defina tokens semânticos para cada função
Tokens primitivos armazenam valores (por exemplo, brand-600); os semânticos representam papéis (como color.action.primary). Em sistemas com múltiplos temas ou marcas, a camada semântica simplifica a manutenção, pois componentes consultam a função e não precisam codificar HEXs diretamente.
O DTCG suporta aliases e referências entre tokens, mas não exige exatamente duas camadas. Este é um exemplo de arquitetura que você pode adaptar:
:root {
--brand-600: #3a56d4;
--brand-700: #2a3fa8;
--color-action-primary: var(--brand-600);
--color-action-primary-hover: var(--brand-700);
--color-on-action: #ffffff;
}Para mudar uma marca ou aplicar um novo tema, ajuste os mapeamentos pertinentes e reteste os contrastes. A alteração de variáveis propaga valores, mas não garante acessibilidade automaticamente. O Carbon Design System documenta exemplos de tokens orientados por papéis.
Passo 5 — Valide contraste, estados e temas
Pelas WCAG 2.2, o nível AA no critério 1.4.3 exige, com suas exceções, pelo menos 4,5:1 para texto comum e 3:1 para texto grande. O critério 1.4.11 exige 3:1 para elementos não textuais essenciais quando aplicável. Para o contraste aprimorado AAA, o critério 1.4.6 estabelece 7:1 para texto comum e 4,5:1 para texto grande, também com exceções.
AAA não se torna automaticamente obrigatório apenas porque um produto pertence ao setor financeiro, de saúde ou governamental. Consulte o contexto normativo e contratual. O importante é testar pares reais (texto e fundo, ícone e superfície, controles e estados), além de temas, foco e hover.
Use um verificador WCAG para testar as combinações. O ajuste Contrast Shift de um gerador ajuda a explorar alternativas, mas não certifica sozinho a paleta. Mensagens críticas não devem depender apenas de cor.
Como exportar sua paleta para Tailwind e CSS Variables
Com a escala validada, o passo seguinte é transformar os tokens em código. O gerador oferece formatos de exportação; confira qual corresponde à versão do seu projeto.
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:
// 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:
@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:
: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:
[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 lê --color-action-primary em ambos os temas, mas os pares devem ser testados em cada contexto.
Exemplo prático: uma paleta de cores CSS aplicada a um botão
Considere uma interface fictícia em que a ação principal utiliza #3a56d4. O par texto branco e esse fundo oferece aproximadamente 6.07:1, acima dos 4,5:1 exigidos para texto comum quando aplicável. Esse cálculo verifica apenas o par apresentado, não todos os estados e componentes.
:root {
--brand-600: #3a56d4;
--brand-700: #2a3fa8;
--color-action-primary: var(--brand-600);
--color-action-primary-hover: var(--brand-700);
--color-on-action: #ffffff;
}
.button-primary {
background: var(--color-action-primary);
color: var(--color-on-action);
}
.button-primary:hover { background: var(--color-action-primary-hover); }
.button-primary:focus-visible {
outline: 3px solid currentColor;
outline-offset: 3px;
}No handoff, documente também os estados, os valores efetivos em modo claro e escuro, o contraste de foco e os critérios de manutenção. Para outras decisões de arquitetura, acesse Figma Variables e Design Tokens. O exemplo não é uma paleta pronta para produção.
Checklist de documentação
| Camada | O que registrar | O que verificar |
|---|---|---|
| Cor primitiva | HEX ou OKLCH, nome e versão | Consistência visual |
| Token semântico | Papel, temas e estados | Uso nos componentes |
| Contraste | Par testado e proporção | Critérios WCAG aplicáveis |
| Entrega | Figma, CSS ou Tailwind | Correspondência com a interface |
Fontes técnicas e referências
Fontes oficiais consultadas: Tailwind – cores, Tailwind v3, Tailwind v4 – @theme, Design Tokens DTCG, IBM Carbon e WCAG 2.2. Nenhuma escala numérica garante contraste por conta própria.
Erros comuns ao criar uma paleta para design system
Forçar a cor da marca em todos os componentes. A cor-chave pode coincidir com o tom 500 ou não. Se ela falhar no contraste, avalie outro tom ou papel semântico para aquele uso, sem perder a identidade da marca.
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.
Esquecer cores neutras e de status. Muitas interfaces precisam de superfícies, textos, bordas, erros e avisos. A quantidade de famílias varia com o projeto; não existe número obrigatório. Valide os pares e não comunique estados somente pela cor.
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, conheça a consultoria de UX e veja como a avaliação do design system pode apoiar o projeto.
Perguntas frequentes sobre paleta de cores para design system
O que é uma Key Color em design system?
É a cor de referência usada para construir uma família de tons. Ela pode coincidir ou não com o tom 500, conforme a escala e a revisão visual.
Quantas famílias de cores um design system precisa?
Depende do contexto. Muitos produtos usam cores de marca, neutras e estados como erro e sucesso, mas não existe uma quantidade universal obrigatória.
Qual a diferença entre token primitivo e semântico?
O primitivo registra um valor como brand-600. O semântico nomeia a função, como color.action.primary, e pode mapear valores distintos para cada tema.
Uma escala de 50 a 950 garante contraste WCAG?
Não. Cada par de cores deve ser testado na interface. O WCAG AA, critério 1.4.3, pede 4,5:1 para texto comum e 3:1 para texto grande, observadas as exceções.
A mesma escala serve para modo claro e escuro?
Ela pode ser reutilizada, mas os papéis semânticos precisam de mapeamentos adequados para cada tema. Apenas inverter os tons não garante legibilidade.
Como diferem Tailwind v3 e v4 nas cores?
O Tailwind v3 geralmente usa theme.extend.colors em tailwind.config.js. O v4 configura principalmente variáveis de tema com @theme no CSS.
