Tokens de design em construtores de UI sem código ajudam equipes a definir cores, tipografia, espaçamento e variantes uma vez, e depois entregar uma UI consistente sem adivinhação.
UI inconsistente raramente começa como um “problema de design”. Começa como um problema de tempo. Alguém precisa de um botão agora, então copia outro de outra página e ajusta até ficar “mais ou menos”.
É assim que pequenas diferenças aparecem: dois azuis quase iguais, um raio de canto que muda de 6 para 8, um título “meio em negrito” e padding que depende de quem construiu a tela. Em construtores sem código, é ainda mais fácil fazer edições pontuais porque os controles estão à mão e as mudanças parecem inofensivas.
À medida que o produto cresce, a deriva acelera. Mais páginas significam mais padrões repetidos. Mais construtores significam mais gostos pessoais. Mais colegas significam mais “correções rápidas” feitas isoladamente. Se uma pessoa constrói o portal do cliente e outra constrói o painel administrativo, você acaba com duas interpretações diferentes da mesma marca.
O “a olho” aparece no trabalho diário: escolher uma cor até ela “parecer certa”, ajustar espaçamento alguns pixels porque a tela parece “apertada demais”, criar um novo estilo de botão em vez de usar um existente, misturar tamanhos de fonte porque o padrão parece “um pouco pequeno”, ou consertar uma tela sem checar o resto.
O custo aparece depois. Revisões ficam lentas porque o feedback vira subjetivo (“faça parecer mais com a outra página”). Retrabalho se acumula porque mudanças são difíceis de aplicar em todos os lugares. Web e mobile divergem porque pessoas diferentes tomam decisões parecidas, mas não idênticas.
Design tokens resolvem isso substituindo decisões de “mais ou menos” por valores compartilhados. A UI permanece consistente mesmo quando a equipe e o app crescem.
Design tokens são decisões nomeadas sobre a sua UI. Em vez de dizer “use este azul” ou “faça os botões parecerem espaçosos”, você dá nomes claros a essas escolhas que qualquer um pode reutilizar.
Um token não é o valor bruto. O valor bruto pode ser 16px, #2563EB, ou 600 (peso da fonte). O token é o rótulo que explica o que esse valor significa no seu produto, como space-4, color-primary ou font-weight-semibold.
Essa mudança resolve o problema do “a olho”. Quando as pessoas escolhem valores pelo feeling, você lentamente acumula cinco azuis diferentes, três títulos ligeiramente distintos e espaçamento que muda de tela para tela.
Tokens funcionam melhor como uma fonte única de verdade. Se cada tela e componente referenciar o mesmo conjunto de nomes, você pode alterar a aparência de todo o app atualizando alguns valores de token, não caçando dezenas de telas.
Tokens também fazem a ponte entre design e construção. Designers usam nomes de tokens nas especificações, e quem monta usa os mesmos nomes no construtor sem código, então o design sobrevive ao handoff.
A maioria dos conjuntos de tokens se divide em algumas categorias: papéis de cor (primary, background, text, danger), tipografia (família de fonte, tamanhos, pesos, altura de linha), passos de espaçamento (padding, margin, gaps), forma e profundidade (radius, larguras de borda, sombras) e, às vezes, motion (durações e easing).
A maioria das equipes não precisa de uma biblioteca enorme de tokens. Precisa de um conjunto pequeno e claro que cubra a maior parte das telas para que as pessoas parem de adivinhar valores. Isso importa ainda mais em ferramentas sem código, onde tweaks “só desta vez” se espalham rápido.
Um conjunto inicial prático cobre cinco grupos:
Uma regra mantém a biblioteca enxuta: se um valor aparece em três ou mais lugares, transforme-o em token. Se aparece uma vez, trate-o com desconfiança antes que vire “o novo normal”.
Bons nomes de token evitam discussões antes mesmo de começarem. Se as pessoas conseguem adivinhar um token sem procurar, elas vão reutilizá-lo. Se não conseguem, vão criar um novo e seu tema se dividirá.
Prefira nomes que descrevam o trabalho que o valor faz na UI, não como ele se parece. text-primary diz quando usar. blue-600 é só um balde de tinta.
Um padrão útil é ter duas camadas:
color-blue-600, space-16, font-14text-primary, bg-surface, border-mutedEm um construtor sem código, tokens semânticos ajudam não-designers a escolher o valor certo rapidamente, sem “a olho”.
A maioria das bibliotecas de token fica bagunçada porque “novo” vira o padrão. Faça da “reutilização” o padrão.
Mantenha regras simples:
Então padronize a nomenclatura. Escolha um estilo de casing (kebab-case funciona bem), use prefixos estáveis (text-, bg-, border-, icon-, space-) e mantenha as escalas numéricas consistentes (space-4, space-8, space-12, space-16).
Trate sua UI atual como evidência. Antes de criar algo novo, faça um inventário rápido: reúna screenshots, inspecione estilos e anote cada valor de cor, tamanho de fonte e espaçamento que você realmente vê em produção (incluindo valores “pontuais” que aparecem só em uma tela).
Em seguida, reduza duplicatas intencionalmente. Normalmente você encontra o mesmo cinza em cinco hexes ligeiramente diferentes, ou espaçamentos que pulam entre 14, 15 e 16. Escolha um valor para manter e mapeie os antigos para ele. É aqui que tokens se tornam práticos: você para de discutir gosto e começa a concordar em um pequeno conjunto de escolhas compartilhadas.
Uma primeira versão sólida pode ser construída em uma passada:
Para cada token, adicione uma frase de orientação: onde usá-lo e onde não usá-lo. Exemplo: “text-muted é para textos auxiliares, não para botões primários.”
Por fim, decida propriedade. Ajuda nomear uma pessoa (ou um pequeno grupo) para aprovar mudanças, com uma regra simples: “Adicione um novo token somente se um existente não couber.” Isso mantém o sistema estável enquanto o produto cresce.
Comece com padrões que cada tela herda: um estilo base de texto (fonte, tamanho, altura de linha, cor), estilos de título (H1–H3) e um pequeno conjunto de regras de espaçamento para que páginas não fiquem aleatórias.
Depois, mapeie tokens para o que sua ferramenta chama de configurações de tema: variáveis de tema, estilos globais, presets ou configurações do design system. O objetivo é que escolher “Primary” ou “Space/16” selecione um token, não um valor pontual.
Mantenha estilos reutilizáveis focados em padrões que você usa todo dia. Um conjunto inicial pode incluir um estilo de card (fundo, borda, raio, padding, sombra), um estilo de campo de formulário (label, input, texto de ajuda), estilos de botão e densidade de linha de tabela e estados de hover.
Estados são onde a inconsistência aparece, então defina-os cedo. Cada componente interativo deve ter valores dirigidos por tokens para hover, focus, disabled e error. O foco deve usar a mesma cor e espessura de contorno em todo lugar. Erro deve usar a mesma combinação de borda e cor de texto.
Finalmente, planeje compartilhamento. Se seu workspace suporta templates ou módulos reutilizáveis, coloque tokens e estilos base em um “app inicial” que novos projetos copiem. Assim, novas telas começam consistentes por padrão.
Variantes são onde um sistema de UI ou fica calmo e previsível ou vira uma pilha de ajustes pontuais. Variantes funcionam melhor quando são uma camada fina que mapeia para tokens de cor, tipografia e espaçamento.
Comece com um pequeno conjunto de componentes-chave usados em todo lugar: botões, inputs, badges, alerts e cards. Dê a cada um as mesmas duas dimensões de escolha: tamanho e intenção. Tamanho deve ser mecânico (tipografia e espaçamento). Intenção deve ter significado (cores semânticas).
Variantes de tamanho permanecem consistentes quando mudam apenas algumas propriedades baseadas em tokens: tamanho de fonte, padding e raio de borda. Variantes de intenção devem mudar principalmente papéis de cor (fundo, texto, borda) e nunca alterar espaçamento silenciosamente.
Um conjunto que cobre a maioria dos produtos:
Defina regras de estado que se apliquem a todo componente, não apenas botões. Por exemplo: foco sempre mostra um anel visível, hover aumenta contraste de forma consistente, e disabled usa a mesma opacidade e bloqueia cliques.
Adicione uma nova variante somente quando ela representar um significado recorrente (como “danger”). Se for uma necessidade de layout pontual, geralmente é um novo componente ou um wrapper, não uma variante que todos vão usar mal depois.
Quando um produto é lançado no web e mobile, “mesma marca” nem sempre significa “mesmos pixels”. O objetivo é que as telas pareçam da mesma família, mesmo quando plataformas têm padrões diferentes.
Comece com tokens compartilhados que viajam bem: papéis de cor (background, surface, text, primary, danger), uma escala tipográfica (tamanhos e pesos) e tokens de espaçamento (4, 8, 12, 16, 24). Isso elimina adivinhação e torna atualizações previsíveis.
Depois, aceite diferenças reais. Mobile precisa de alvos de toque maiores e frequentemente um pouco mais de espaçamento. Web precisa de tabelas mais densas, sidebars e layouts multi-coluna. Fontes podem diferir também: você pode usar uma fonte de marca na web mas preferir padrões da plataforma no iOS/Android por legibilidade e performance.
Uma abordagem prática é ter duas camadas: tokens globais que definem significado, e tokens de plataforma que definem como esse significado é renderizado.
color.text, color.primary, space.md, radius.sm, type.bodytype.family.web, control.height.web, space.tableRowtype.family.mobile, control.height.mobile, space.touchMantenha nomes de componente consistentes (Button/Primary) mesmo que tamanhos difiram. Exija checagens de contraste para ambos os temas antes do release.
Tokens só funcionam se permanecerem estáveis e compreensíveis. Sem uma governança leve, equipes adicionam silenciosamente “mais um azul” ou “mais um padding” e você volta a escolher “a olho”.
Mantenha o processo pequeno, mas real:
Mantenha um changelog simples com deprecações. Se um token antigo está sendo substituído, diga o que usar no lugar, mantenha-o funcionando por um tempo e marque-o claramente para que novas telas não o adotem.
Limpeza faz parte do trabalho. Uma vez por mês, remova tokens e variantes de componente não usados (ou ao menos sinalize-os).
Não-designers precisam de exemplos, não de teoria.
Faça: use a escada de espaçamento para gaps, e use a variante Primary Button para a ação principal.
Não faça: defina padding como “13px porque parece certo” ou crie um novo estilo de botão para combinar com uma tela.
Amarre o trabalho de tokens às prioridades do produto: novas features, rebrands e correções de acessibilidade devem guiar atualizações de tokens, não preferências pessoais.
A maneira mais rápida de perder os benefícios dos tokens é tratá-los como um depósito de coisas. Você começa com boa intenção, mas alguns consertos rápidos se acumulam e a equipe volta a escolher “a olho”.
Uma armadilha comum é criar tokens demais muito cedo. Se cada tela ganha seu próprio token de cor ou espaçamento, você não está construindo um sistema — está catalogando exceções. Adicione um token somente quando você puder apontar pelo menos dois lugares onde ele será usado.
Outro problema silencioso é deixar valores crus infiltrarem-se nos componentes. Alguém define padding de botão como 14px “só desta vez”, ou usa um hex direto em um card. Semanas depois ninguém lembra por que é diferente. Torne um hábito: se é visível e repetível, deve ser um token.
Também cuide para não misturar tipos de token. Tokens base (como gray-900 ou space-4) descrevem valores crus. Tokens semânticos (como text-primary ou surface-muted) descrevem significado. Problemas começam quando um componente usa tokens base e outro usa tokens semânticos para o mesmo papel.
Estados são outra dor tardia. Equipes frequentemente definem estilos normais e depois remendam foco, hover, disabled e error pouco antes do release. É assim que se obtém anéis de foco inconsistentes e três vermelhos diferentes para “erro”.
Antes de escalar, faça uma checagem rápida:
Antes de levar sua UI para mais telas, equipes ou produtos, verifique se a base é clara o suficiente para copiar sem adivinhar.
Uma equipe pequena está construindo dois apps ao mesmo tempo: um portal do cliente e um painel administrativo interno. Pessoas diferentes mexem em telas diferentes e constroem rápido dentro de um construtor sem código. Depois de algumas semanas, a UI começa a parecer “estranha”, mesmo que ninguém consiga apontar um problema específico.
Antes dos tokens, comentários de revisão se acumulam: botões são quase iguais mas não, espaçamento muda de tela para tela, campos de formulário não combinam e o portal parece “acolhedor” enquanto o admin parece “rígido” sem querer.
Eles resolvem introduzindo um conjunto pequeno e prático de tokens. Definem cores semânticas (Primary, Success, Danger, TextMuted), uma escala de espaçamento (4, 8, 12, 16, 24) e variantes de botão (Primary, Secondary, Ghost) com um raio e estados consistentes.
Agora colaboradores param de escolher hex aleatórios e tamanhos de fonte em cada tela. Eles escolhem tokens e variantes, então cada nova página herda as mesmas decisões.
A construção fica mais rápida porque as escolhas já estão feitas. Revisões mudam de nits visuais para problemas reais de UX. “Faça este botão a variante primary” substitui “Você pode deixá-lo um pouco mais azul e um pouco mais alto?”.
Depois, vem um rebrand pequeno: a cor primária muda e a escala tipográfica aperta. Com tokens, a equipe atualiza alguns valores uma vez e tanto o portal quanto o admin atualizam juntos.
Escolha um fluxo que as pessoas usam muito e que tem deriva óbvia, como onboarding, uma página de configurações ou um formulário simples. Converter um único fluxo é a maneira mais rápida de provar a ideia e parar o “a olho”.
Comece com um conjunto pequeno e seguro de tokens: primary/background/text/border/danger, uma escala curta de tipografia, uma escada de espaçamento e 2–3 níveis de raio e sombra. Depois crie um pequeno conjunto de componentes que usem apenas tokens: um botão, um input, um card e um alert. Adicione variantes só quando resolverem uma necessidade real.
Faça uma revisão curta com a equipe usando duas screenshots: uma tela “antes” com paddings e fontes inconsistentes e uma tela “depois” construída com tokens e variantes. Concordem em algumas regras (como “não usar cores hard-coded” e “espaçamento deve ser um token”) e corrijam as inconsistências principais primeiro.
Para rollout, converta telas novas primeiro e depois atualize as antigas conforme você as tocar. Quando o suporte pedir um novo filtro no admin, reconstrua aquele painel usando componentes baseados em tokens e substitua só o que estiver editando.
Se você está construindo produtos completos (backend, web e mobile) no AppMaster, ajuda definir tokens e estilos reutilizáveis cedo para que novas telas herdem as mesmas decisões. Assim, consistência visual e lógica de app avançam juntas sem limpeza repetida depois.
Por que a inconsistência de UI continua acontecendo mesmo quando temos um designer?A deriva de UI normalmente começa com pequenas edições do tipo “só desta vez”: copiar um componente, ajustar o padding ou escolher uma cor no olho. Com o tempo essas pequenas diferenças se acumulam entre páginas e colaboradores, e as revisões viram debates subjetivos em vez de verificações rápidas contra regras compartilhadas.
O que exatamente é um design token (sem a teoria)?Design tokens são decisões nomeadas sobre a UI que as pessoas reutilizam em vez de adivinharem valores crus. O valor pode ser 16px ou #2563EB, mas o nome do token explica o propósito, como space-16 ou color-primary, para que todo mundo escolha a mesma opção sempre.
Quais categorias de token devemos definir primeiro para um produto real?Comece com roles de cor, tipografia, espaçamento e um pequeno conjunto de raios e sombras. Isso cobre a maioria das telas e evita os problemas mais comuns de “a olho”, mantendo o conjunto de tokens pequeno o suficiente para que as pessoas realmente o usem.
Quando devemos adicionar um novo token versus manter um estilo pontual?Uma regra prática é criar tokens quando um valor aparece em duas ou mais ocasiões, ou quando suporta um estado real como hover, foco, desabilitado ou erro. Se um valor for realmente único, mantenha-o local ao componente para que não vire um padrão global por acidente.
Nossos nomes de token devem ser semânticos (como text-primary) ou crus (como blue-600)?Nomes semânticos descrevem o propósito, como text-primary ou bg-surface, para que as pessoas escolham corretamente sem decorar a paleta. Nomes crus como blue-600 podem servir como blocos base, mas depender deles em componentes facilita o uso incorreto das cores pelo app.
Como criar tokens a partir de uma UI inconsistente existente sem quebrar tudo?Faça um inventário do que já está em produção: cole as cores, tamanhos de fonte e espaçamentos que você realmente vê, depois una valores próximos de propósito. Com um conjunto pequeno e limpo, mapeie os valores antigos para os tokens mais próximos para que telas futuras reutilizem tokens em vez de reintroduzir valores “quase iguais”.
Como aplicamos tokens dentro de um construtor de UI sem código na prática?Defina padrões globais primeiro, depois mapeie tokens para o que a ferramenta chama de variáveis de tema ou estilos globais, para que os componentes referenciem nomes em vez de códigos hex e valores em pixels. Depois, crie um pequeno conjunto de estilos reutilizáveis para os componentes que você usa no dia a dia e garanta que hover, foco, desabilitado e erro também usem tokens.
Como construímos variantes de componente (botões, inputs) sem criar caos?Mantenha variantes simples e previsíveis limitando-as a tamanho e intenção. O tamanho deve apenas alterar algumas propriedades dirigidas por tokens, como tamanho de fonte e padding, enquanto a intenção deve trocar principalmente roles semânticos de cor, assim um botão “danger” não muda espaçamento ou tipografia de forma oculta.
Como manter temas web e mobile alinhados sem forçar pixels idênticos?Compartilhe tokens semânticos globais entre plataformas para que o significado se mantenha, e permita tokens específicos de plataforma para diferenças como tamanhos de toque e densidade. O objetivo é “mesma família, não mesmos pixels”, para que web e mobile sintam-se consistentes sem ignorar suas restrições.
Como governamos tokens para que o sistema permaneça limpo ao longo do tempo?Defina propriedade clara e use um fluxo de revisão pequeno para mudanças, assim novos tokens não viram gambiarras rápidas. Mantenha uma cadência para atualizações e desaproprie tokens antigos em vez de substituí-los silenciosamente — isso mantém o sistema estável mesmo quando mais pessoas constroem telas, inclusive em projetos AppMaster onde colaboradores avançam rápido.
21 de jan. de 2026
8 min
20 de jan. de 20268 min
20 de jan. de 20268 minExperimente o AppMaster com plano gratuito.
Quando estiver pronto, você poderá escolher a assinatura adequada.
