Como eu parei de inventar números e passei a derivar tokens de design com Fibonacci e Φ
Vou contar um problema que qualquer dev que cuida do próprio front já viveu: você abre o CSS de um projeto com seis meses, procura o gap entre dois componentes e encontra 12px num lugar, 14px em outro, 13px num terceiro. Ninguém sabe de onde vieram. Provavelmente de um "parece certo" feito em três momentos diferentes, com estados de espírito diferentes.
Isso tem nome: é decisão sem critério. E ela acumula.
Passei alguns meses construindo um sistema para resolver isso de forma que fosse auditável — onde qualquer token publicado tivesse uma cadeia de raciocínio rastreável. O resultado foi um framework de derivação matemática usando três constantes: a Razão Áurea (Φ), a Sequência de Fibonacci e o Ângulo Áureo (θ).
O artigo explica o método. Não é magia — é uma estrutura de decisão.
O problema que eu queria resolver
Decisões arbitrárias de espaçamento e tipografia não são apenas esteticamente incômodas. Elas criam dívida técnica de design: valores sem critério que nenhum novo membro do time consegue reconstituir, exceções que se acumulam sem registro, sistemas que funcionam parte por parte mas não comunicam unidade formal.
A primeira pergunta que me fiz foi: existe uma forma de derivar tokens a partir de um método reproduzível, que qualquer pessoa com acesso à documentação consiga reconstruir do zero?
A resposta foi usar matemática como estrutura de relações — não como garantia de beleza, mas como fonte de consistência.
Por que Fibonacci para espaçamento?
A Sequência de Fibonacci (1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89...) tem uma propriedade útil para design: ela é aditiva com saltos crescentes. Isso produz uma escala que cobre bem o range de micro (2–8px) a macro (55–144px) sem exigir interpolação arbitrária.
A ideia é simples: você escolhe uma âncora — um step Fibonacci que vai corresponder a um valor em px que faz sentido ergonômico para o seu produto — e deriva o resto por proporção.
Exemplo com âncora F(9)=34 → 16px:
space(n) = F(n) × (16/34)
F(8)=21 → 9.88px → quantizado para 10px
F(9)=34 → 16.00px ← âncora
F(10)=55 → 25.88px → quantizado para 26px
F(11)=89 → 41.88px → quantizado para 42px
O token publicado não é 9.88px — é 10px. A derivação fica documentada internamente; o CSS recebe valores limpos.
:root {
--space-10: 10px;
--space-16: 16px; /* âncora F(9) */
--space-26: 26px;
--space-42: 42px;
--space-68: 68px;
--space-110: 110px;
}
E os componentes nunca usam esses primitivos diretamente — usam tokens semânticos:
:root {
--space-inset-md: var(--space-10); /* padding de botão */
--space-gap-lg: var(--space-16); /* gap entre grupos */
--space-section-sm: var(--space-42); /* entre seções */
}
.button {
padding: var(--space-inset-md); /* correto */
/* padding: var(--space-10); ← nunca isso */
}
Quando você muda a âncora, reconstrói a escala inteira. Quando você muda a semântica, refatora os tokens sem mexer no CSS dos componentes.
Por que Φ para tipografia?
A Razão Áurea (Φ ≈ 1.618) gera progressões geométricas com razão constante e auto-similar. Em tipografia, isso significa que cada step tem a mesma relação com os adjacentes.
Mas — e esse "mas" é importante — Φ não é bala de prata. Para dashboards e interfaces densas, uma escala com Φ produz headings gigantes:
| Nível | Razão Φ (BASE=16px) | Quarta Perfeita (1.333) |
|---|---|---|
| Body | 16px | 16px |
| H2 | 41.9px | 28.4px |
| H1 | 67.8px | 37.9px |
Um H1 de 67px convive bem num hero de landing page. Num dashboard onde heading e corpo dividem a mesma tela, é inapropriado. A escolha da razão é editorial — o framework oferece um menu de razões com nomes baseados em intervalos musicais:
| Razão | Nome | Caráter | Melhor para |
|---|---|---|---|
| 1.125 | Seg. Maior | Sutil | Admin panels, documentação |
| 1.250 | Terça Maior | Equilibrado | SaaS, dashboards |
| 1.333 | Quarta Perf. | Clara | Marketing, landing pages |
| 1.618 | Phi | Expressivo | Luxury brands, hero sections |
Em tipografia fluida com clamp(), os limites mínimo e máximo de cada step derivam das duas âncoras — base mobile e base desktop:
/* Quarta Perfeita, BASE mobile=14px → desktop=18px */
--text-body: clamp(0.875rem, 0.696rem + 0.536vi, 1.125rem);
--text-h2: clamp(1.556rem, 1.238rem + 0.952vi, 2.000rem);
--text-h1: clamp(2.075rem, 1.651rem + 1.270vi, 2.669rem);
O Golden Angle para distribuição de cores
O Ângulo Áureo (θ ≈ 137.508°) distribui matizes no círculo cromático de forma que cada nova cor adicionada ocupa o ponto de maior separação angular das já existentes. É uma propriedade matematicamente verificável, não apenas estética.
hue(n) = (H₀ + n × 137.508°) mod 360°
Com H₀ = 220° (azul-marca):
accent-1: 220.0° (azul)
accent-2: 357.5° (vermelho-rosa)
accent-3: 135.0° (verde)
accent-4: 272.5° (roxo)
accent-5: 50.0° (âmbar)
Para os tokens de cor, o framework usa oklch — um espaço de cor com luminosidade perceptualmente uniforme. hsl(60, 100%, 50%) (amarelo) parece muito mais claro que hsl(240, 100%, 50%) (azul) mesmo com L=50%. Em oklch, o canal L corresponde à luminância percebida pelo olho humano.
Um aviso importante, que descobri na prática: nem toda combinação de L, C e H em oklch cabe no gamut sRGB. Antes de publicar tokens em produção, valide clipping de gamut usando oklch.com. Copiar os valores sem verificar pode gerar comportamentos inconsistentes entre navegadores.
O que a matemática não resolve — e o documento não esconde
Esse é talvez o ponto mais importante, e o que diferencia esse framework de um manifesto:
Proporções matematicamente perfeitas frequentemente precisam de compensação óptica. Um círculo precisa ser ligeiramente maior que um quadrado de mesma área para parecer do mesmo tamanho. Texto centralizado geometricamente num botão parece baixo demais — o olho humano não lê o centro matemático como centro visual.
Harmonia proporcional não garante boa UX. Um componente com espaçamentos perfeitos pode ter hierarquia confusa, affordance inadequada, ergonomia insuficiente.
Phi não é lei perceptiva universal. Estudos sobre preferência pela proporção áurea têm resultados mistos e metodologias contestadas. O que Φ oferece é consistência de razão — não preferência universal garantida.
O framework foi escrito para deixar isso explícito. A matemática organiza o espaço de decisão. Dentro dele, julgamento editorial, contexto de produto e pesquisa de usuário continuam determinantes.
A arquitetura de governança
O que diferencia esse projeto de uma tabela de valores é a camada de governança. Cada token tem:
- derivação documentada (de qual fórmula veio)
- erro de quantização registrado
- mapeamento semântico explícito
- critério para abrir exceção
- sinal para recalibrar a âncora
Por exemplo, se mais de 25% dos componentes precisam de correção manual de line-height, o problema não está nos componentes — está na âncora de leading. Recalibrar é a resposta certa; acumular exceções é dívida técnica disfarçada de flexibilidade.
O documento define cinco níveis de precedência quando há conflito:
1 — Acessibilidade (absoluta — contraste WCAG, reduced motion)
2 — Ergonomia (tamanhos mínimos de toque, legibilidade)
3 — Percepção óptica (compensações necessárias)
4 — Coerência semântica (a intenção do token deve ser preservada)
5 — Derivação matemática (menor precedência em conflito)
A matemática tem a menor precedência. Ela é ponto de partida, não ponto de chegada obrigatório.
O resultado em números
O sistema derivado para um SaaS com base 16px, Quarta Perfeita (1.333) e T=150ms de animação:
/* Escala de espaçamento completa */
--space-2: 2px; --space-4: 4px; --space-6: 6px;
--space-10: 10px; --space-16: 16px; --space-26: 26px;
--space-42: 42px; --space-68: 68px; --space-110: 110px;
/* Durações de animação derivadas de Φ */
--duration-instant: 57ms; /* 150 × Φ⁻² */
--duration-fast: 93ms; /* 150 × Φ⁻¹ */
--duration-normal: 150ms; /* âncora */
--duration-slow: 243ms; /* 150 × Φ¹ */
/* Easing baseado em Φ⁻¹ = 0.618 */
--ease-harmonic: cubic-bezier(0.618, 0.000, 0.382, 1.000);
--ease-out-phi: cubic-bezier(0.000, 0.000, 0.382, 1.000);
Onde encontrar o documento completo
O framework está documentado num arquivo .md de aproximadamente 2.000 linhas, com:
- Derivação matemática de cada subsistema (espaçamento, tipografia, cor, animação, grid, border radius, elevação)
- Tabelas de referência por contexto (SaaS, marketing, editorial, mobile, dashboard)
- Critérios de validação por camada
- Anti-padrões documentados
- Processo de recalibração
- Métricas de sucesso para medir se o sistema está funcionando em produção
Se houver interesse, o repositorio é: https://github.com/MolinariBR/NebulaDesign. Aceito perguntas nos comentários — especialmente sobre os trade-offs de escolha de razão tipográfica e os casos onde o framework tem aplicabilidade limitada.
Uma observação final: esse framework é um método, não uma biblioteca. Os tokens são instanciações de uma configuração específica de âncoras. O valor real não está nos números — está na cadeia de decisão que eles tornam auditável.