Há uns anos eu estava no meio de uma refatoração do design system da Memed quando uma agência de branding entregou a nossa paleta renovada. O timing parecia perfeito – cores novas para um sistema novo.

As cores de marca que eles nos deram eram ótimas para o logo e para os materiais de marketing. Foi pra isso que elas foram feitas. Mas uma plataforma de prescrição médica precisa de bem mais do que quatro ou cinco cores de marca. A gente precisava de tons claros para fundos, tons escuros para dar profundidade e uma porção de tons no meio para os estados interativos. Uns dez passos por cor. A paleta da agência não veio com nada disso, e por que viria? Manuais de marca focam na identidade central, e não em cada detalhe de uma interface.

Então sobrou pra gente “desdobrar” aquelas cores em rampas inteiras. Comecei no Google Sheets, escrevendo umas funções em Apps Script na marra pra converter entre modelos de cor e plotar os canais de matiz, saturação e brilho das nossas rampas…

Google Sheets e funções customizadas para converter valores de cor

Funcionou, e eu não tenho o menor orgulho daquilo. Mas agora que os LLMs de código já dão conta de ajudar a construir ferramentas de verdade, resolvi transformar aquela gambiarra em algo que eu realmente gostasse de usar. Foi assim que nasceu o Color Guru: um jeito de projetar rampas de cor moldando curvas, em vez de ficar ajustando os códigos hex um por um.

Pensando em curvas

Em UI, você geralmente quer mais passos nos extremos do que no meio. Os tons bem claros servem para fundos sutis, e os bem escuros dão profundidade. Já a faixa do meio precisa de contraste mais forte, porque é ali que ficam os textos e os botões. Ou seja: a curva de luminância tem que ser mais íngreme no meio e mais plana nas pontas.

Curvas de Bézier eram a ferramenta certa pra isso, porque você descreve essa forma uma vez e gera quantos passos quiser a partir dela. E a gente já usa curvas de Bézier o tempo todo para easing de animação, então já está acostumado.

Curva de saturação do Colorguru

Construindo em cima do ColorBox

Eu definitivamente não fui a primeira pessoa a pensar em rampas de cor desse jeito. O ColorBox v1, do Kevyn Arnott, era uma ótima ferramenta de rampas de cor baseada em curvas, e eu usei por um tempo. Então por que fazer outra ferramenta? Porque, conforme eu ia trabalhando em design systems, três coisas que ele não tinha começaram a me incomodar.

Primeiro, eu queria ver saturação e brilho juntos, e não em dois gráficos de linha separados. Quando você plota um contra o outro, aparecem problemas que passariam batido: as cores claras que perdem toda a saturação de uma hora pra outra e ficam acinzentadas, e as escuras que ganham intensidade demais e parecem neon. Esse gráfico Sat×Bri é o diagnóstico que eu queria ter tido na época da Memed.

Visualizando a curva de saturação x brilho

Segundo, eu queria controle fino sobre a forma das curvas. O ColorBox te deixa ver as curvas, o que já é bastante coisa. Mas eu queria poder mexer só na ponta clara, ou esticar o meio, ou concentrar mais contraste nos escuros, cada coisa de forma independente. Curvas cúbicas de Bézier com pontos de controle individuais fazem exatamente isso.

Terceiro, eu precisava de um jeito de fixar cores de marca. Voltando pro refresh da Memed: a agência nos deu códigos hex específicos, e eu tinha que montar uma paleta sistemática inteira em volta deles. Tentar fazer engenharia reversa das configurações de curva pra cair num hex exato era impossível. Hoje dá pra digitar o hex ou clicar numa cor do preview. O Color Guru encaixa essa cor na rampa pela luminância, e você molda o resto em volta.

Como eu uso na prática

Quando estou montando uma paleta nova, seja uma cor primária, os neutros ou as cores de status, o caminho costuma ser esse:

  1. Escolho quantos passos eu preciso. Não existe resposta certa aqui, mas dez a doze passos funcionam bem para a maioria dos design systems.

  2. Se tiver uma cor de marca vinda das guidelines, fixo essa cor antes de qualquer coisa e moldo as curvas em volta, com ela parada no lugar enquanto o resto se mexe.

  3. Depois eu ataco a luminância. Tento ficar em torno de 4% a 6% de luminância no tom mais escuro e 95% no mais claro. O truque é dar espaço suficiente no meio para contraste forte e deixar as pontas com pelo menos 3 tons variando levemente (bordas, fundos, estados de hover, essas coisas).

  4. Aí vem a curva de saturação. Baixo a saturação na ponta clara, mas não a ponto de os tons ficarem acinzentados, e aumento nos escuros pra não ficarem barrentos. Quase sempre acabo numa curva convexa que atinge o pico lá pelos 70% do caminho da rampa e depois suaviza até os tons mais escuros. Isso aí é gosto meu.

  5. Um pouquinho de desvio de matiz (opcional). Lembre que algumas cores têm mais luminância que outras, e dá pra usar isso a seu favor. Uma rampa geralmente azul, por exemplo, pode ter os tons claros puxando pro ciano e os escuros puxando pro roxo. O Erik D. Kennedy explica isso bem no artigo Color in UI Design: A (Practical) Framework.

  6. Olho o gráfico Sat×Bri. Se o arco está suave, está bom. Se tem uma quebra ou se a linha dobra em cima de si mesma, tem coisa errada, e volto para ajustar saturação e brilho. O Jeeyoung Jung se aprofunda nisso no artigo Designing Systematic Colors.

  7. Confiro o contraste. A ferramenta mostra as taxas de contraste em tempo real, então dá pra ver na hora quais combinações batem 4.5:1 para texto de corpo e 3:1 para texto grande e elementos de UI. Assim eu resolvo a acessibilidade enquanto ainda estou desenhando a paleta, em vez de descobrir problema depois.

Quando fico satisfeito, exporto pro Figma e testo em alguns componentes. Se estiver tudo certo, também dá para exportar como variáveis CSS, JSON ou texto puro.

Experimente

A ferramenta está no ar em colorguru.design, e o código está no GitHub. Se você achar útil e quiser contribuir, eu ia adorar.

Nota: Usei IA para ajudar a estruturar e refinar este post.