Quando um Design System começa a ser usado em fluxos reais, a maior fonte de inconsistência não costuma ser a falta de componentes, e sim a falta de definição (e prova) de como esses componentes se comportam em diferentes estados e interações. “Estado” é a condição visual e funcional de um elemento em um determinado momento (por exemplo: botão padrão, hover, pressionado, desabilitado, carregando). “Interação” é o evento que provoca a mudança de estado (por exemplo: passar o mouse, tocar, focar via teclado, clicar, preencher um campo). Prototipação orientada a sistema é a prática de prototipar usando os componentes do sistema (e seus estados) como fonte de verdade, de modo que o protótipo valide consistência visual, acessibilidade básica e regras de comportamento antes do handoff.
A diferença entre “prototipar telas” e “prototipar com sistema” é que, no segundo caso, você evita criar exceções visuais no protótipo e evita “simular” estados com camadas soltas. Em vez disso, você alterna estados por variantes, propriedades e interações do protótipo. O resultado é um protótipo que funciona como especificação viva: ele mostra o que acontece, quando acontece e como deve parecer, sem depender de anotações extensas.
Estados essenciais: o que precisa existir no sistema
Nem todo componente precisa de todos os estados possíveis, mas alguns estados são recorrentes e devem ser tratados como parte do contrato do componente. Abaixo está um conjunto prático de estados para a maioria dos elementos interativos. O objetivo é padronizar o vocabulário e a aparência, para que o usuário reconheça padrões e para que o time implemente com menos ambiguidade.
1) Default (padrão)
É a aparência “em repouso”, sem interação. Deve ser o estado mais neutro e o que aparece com maior frequência. Se o default já for “forte demais”, você perde contraste de hierarquia quando precisar destacar hover/pressed.
2) Hover (passagem do mouse)
Indica que o elemento é interativo e está sob o cursor. Em sistemas que precisam funcionar bem em desktop, hover é um estado importante para feedback. Em mobile, hover não existe, então o sistema deve ser consistente sem depender dele.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
3) Pressed / Active (pressionado)
É o feedback imediato do clique/toque. Normalmente envolve mudança de cor, sombra, ou leve “afundamento”. Deve ser perceptível, mas não tão dramático que pareça outro componente.
4) Focus (foco de teclado)
É obrigatório para acessibilidade e navegação por teclado. O foco não é “hover”; ele precisa de um indicador claro (por exemplo, um outline). Um erro comum é remover o foco por estética, o que quebra navegação e auditorias de acessibilidade.
5) Disabled (desabilitado)
Comunica indisponibilidade. Deve reduzir ênfase e, ao mesmo tempo, manter legibilidade mínima. Também precisa ser consistente: se “disabled” em botões reduz opacidade para 40%, não faça inputs com 10% e links com 70% sem motivo.
6) Loading (carregando)
É um estado funcional, não apenas visual. Em botões, costuma bloquear cliques repetidos e substituir o texto por um spinner (ou manter o texto e adicionar spinner). Defina regras: o botão mantém largura? O label some? O ícone some? Essas decisões evitam “pulos” de layout e inconsistências.
7) Error / Success / Warning (validação e feedback)
Estados de validação aparecem muito em formulários e componentes de feedback. O sistema deve definir: cor, ícone (se houver), mensagem, espaçamento, e como o estado se comporta com foco (por exemplo: input com erro e foco ao mesmo tempo).
8) Selected / Checked / On (seleção)
Para tabs, chips, toggles, checkboxes, radios e itens selecionáveis. O estado selecionado precisa ser distinguível do hover e do foco. Em listas e menus, “selected” geralmente é persistente; “hover” é transitório.
Consistência visual: regras que evitam variações acidentais
Consistência visual em estados não significa “tudo igual”; significa que mudanças seguem regras previsíveis. Em um sistema, você quer que o usuário aprenda rapidamente: “quando algo está desabilitado, fica assim”, “quando está em foco, aparece esse contorno”, “quando está em erro, a borda e a mensagem seguem esse padrão”. Para isso, defina regras de transformação por estado, aplicáveis a várias famílias de componentes.
Regras práticas de transformação por estado
Hover: ajuste leve de cor (ex.: aumentar contraste ou escurecer 5–10%), ou elevação/sombra sutil. Evite mudar tipografia ou espaçamento.
Pressed: reduza elevação e/ou escureça um pouco mais que o hover. Se houver sombra, ela geralmente diminui.
Focus: use um indicador consistente (outline/anel) com espessura e offset padronizados. Evite depender apenas de mudança de cor de fundo.
Disabled: reduza ênfase de fundo e texto, e remova sombras. Mantenha o cursor/affordance coerente (no protótipo, não dá para “bloquear” totalmente, mas dá para sinalizar).
Error: borda e mensagem com cor de erro, e ícone opcional. Defina se o erro aparece ao blur, ao submit, ou em tempo real (isso é comportamento, não só visual).
Selected: use cor de destaque e/ou indicador (underline, check, pill). Não use o mesmo tratamento do hover para selected.
Uma forma de garantir consistência é pensar em “camadas” do componente: container (fundo/borda), conteúdo (texto/ícone), e indicador (outline, badge, underline). Em cada estado, você decide quais camadas mudam e quais permanecem. Exemplo: no foco, muda apenas o indicador; no hover, muda o container; no disabled, muda container e conteúdo, e remove indicador.
Prototipação orientada a sistema: princípios
Prototipar orientado a sistema significa que o protótipo deve ser montado com componentes do sistema e que as interações devem acionar estados definidos no próprio componente. Isso reduz “gambiarras” como duplicar frames para simular hover, ou desenhar manualmente um erro em um input sem que o componente suporte esse estado.
Princípio 1: o protótipo deve demonstrar regras, não exceções
Se um fluxo exige um comportamento novo (por exemplo, botão com loading e ícone ao mesmo tempo), isso é um sinal para evoluir o componente, não para improvisar no arquivo do produto. O protótipo é um teste de maturidade do sistema.
Princípio 2: estados devem ser acionáveis por interação
Se você tem variantes de estado, mas não consegue alterná-las por interações no protótipo, o protótipo vira apenas uma galeria. O objetivo é permitir que alguém “sinta” o comportamento: passar o mouse, focar, clicar, ver feedback.
Princípio 3: o protótipo deve ser legível para design e dev
Interações precisam ser simples de entender. Evite redes de links confusas. Prefira interações locais (no próprio componente) para estados (hover/focus/pressed) e interações de navegação (troca de tela) para mudanças de rota (ir para outra página, abrir modal, avançar etapa).
Passo a passo: modelando estados em componentes para prototipar sem ruído
O passo a passo abaixo foca em como preparar componentes para que o protótipo consiga alternar estados de forma consistente. A ideia é que você consiga reutilizar o mesmo componente em várias telas e ainda assim demonstrar interações.
Passo 1: liste estados e eventos do componente
Escolha um componente crítico (por exemplo, Button). Faça uma matriz simples: estados (default, hover, pressed, focus, disabled, loading) x eventos (mouse enter, mouse leave, mouse down, mouse up/click, tab focus, blur). Decida quais estados realmente serão prototipados e quais serão apenas documentados.
Exemplo de matriz mínima para botão em protótipo:
Default
Hover (mouse enter)
Pressed (mouse down)
Focus (tab)
Disabled (sem interação)
Loading (após click, opcional)
Passo 2: garanta que o layout não “pule” entre estados
Antes de criar interações, verifique se os estados mantêm dimensões consistentes. Loading é o maior vilão: se o texto some e o botão encolhe, o layout muda e o protótipo fica enganoso. Uma regra prática é manter largura e altura constantes e trocar apenas conteúdo interno (texto por spinner, por exemplo) sem alterar padding.
Passo 3: crie variantes de estado com nomes previsíveis
Padronize o nome da propriedade de estado (por exemplo, State) e valores (Default, Hover, Pressed, Focus, Disabled, Loading). Se cada componente usar um nome diferente (Status, Mode, Interaction), o protótipo vira um caos para manter.
Exemplo de estrutura de propriedades (conceitual):
Button / Variant properties: Size, Hierarchy, State, Icon, WidthMesmo que o componente tenha outras propriedades, o importante é que State exista e seja consistente entre componentes interativos.
Passo 4: defina o indicador de foco como parte do componente
Não desenhe foco “por fora” em cada tela. Coloque o outline/anel dentro do componente, como uma camada que pode ser ativada no estado Focus. Isso garante que o foco tenha sempre a mesma espessura, raio e offset.
Se o componente tiver cantos arredondados, o foco deve acompanhar o raio. Se houver variações de raio por tamanho, o foco precisa acompanhar essas variações.
Passo 5: configure interações locais para estados transitórios
Estados como hover e pressed são transitórios e devem ser demonstrados no próprio componente. Configure interações do tipo “ao passar o mouse” para ir ao estado Hover e “ao sair” para voltar ao Default. Para pressed, use “ao pressionar” para ir ao estado Pressed e “ao soltar” para voltar ao Hover ou Default (dependendo do contexto).
Uma sequência comum em desktop:
Mouse enter: Default → Hover
Mouse down: Hover → Pressed
Mouse up: Pressed → Hover
Mouse leave: Hover → Default
Para foco via teclado, use uma interação que simule “ao focar” quando o usuário clicar ou navegar. Em protótipos, muitas vezes você simula foco ao clicar no componente (porque o protótipo não reproduz teclado perfeitamente). O importante é existir um estado Focus claro e reutilizável.
Passo 6: trate estados persistentes como propriedades controladas
Selected/Checked/On são estados persistentes. Em vez de depender de hover/pressed, você precisa de uma lógica de alternância. Para um Toggle, por exemplo, crie uma propriedade Value (Off/On) e uma propriedade State (Default, Hover, Focus, Disabled). A interação de clique alterna Value, e os estados transitórios continuam funcionando.
Exemplo conceitual:
Toggle properties: Value (Off/On), State (Default/Hover/Focus/Disabled)Isso evita misturar “selecionado” com “hover” na mesma propriedade e facilita prototipar cenários como “Toggle On + Focus”.
Passo 7: modele validação de formulário com regras claras
Inputs e componentes de formulário precisam de estados combináveis: Default, Focus, Filled, Error, Disabled. Um erro comum é criar um único estado “Error” que não considera foco, resultando em dúvida: quando o usuário está com o campo em erro e clica nele, o foco aparece? A borda fica vermelha ou azul? O sistema deve definir prioridade visual.
Uma regra prática de prioridade:
Error define cor de borda e mensagem.
Focus adiciona outline/anel por fora, sem remover o erro.
Assim, o usuário entende que há erro e também entende onde está o foco.
Passo a passo: prototipando um fluxo com estados (exemplo de formulário + CTA)
Agora, um roteiro prático para montar um protótipo que valida estados e consistência em um cenário comum: login com validação e botão com loading. O objetivo não é “fazer um app completo”, e sim testar se o sistema cobre as interações sem precisar de ajustes manuais.
Passo 1: monte a tela com componentes do sistema
Use componentes de Input (email e senha), Checkbox (lembrar), Link (esqueci a senha) e Button (entrar). Evite desenhar qualquer elemento “solto” que já exista no sistema, porque isso mascara lacunas.
Passo 2: defina o comportamento esperado antes de ligar interações
Escreva em uma lista (para você e para o time) as regras do fluxo:
Ao clicar em “Entrar”, se campos vazios: mostrar erro nos campos obrigatórios.
Ao preencher e clicar em “Entrar”: botão entra em loading por 1–2s e depois navega.
Ao focar em um campo com erro: manter borda de erro e mostrar foco por outline.
Essas regras guiam quais estados você precisa demonstrar no protótipo.
Passo 3: crie frames de “cenários” quando necessário (sem duplicar estados)
Para validação, muitas vezes você precisa de cenários (antes do submit, após submit com erro, após submit com sucesso). Em vez de duplicar componentes para simular estados, você pode duplicar apenas o frame do cenário e, dentro dele, ajustar propriedades dos componentes (por exemplo, Input State = Error). O componente continua sendo o mesmo; você só muda a propriedade.
Cenários típicos:
Login / Default
Login / Error
Login / Loading
Home (destino)
Passo 4: conecte interações de navegação entre cenários
Conecte o botão “Entrar” do cenário Default para o cenário Loading (após clique). Do cenário Loading, conecte para Home após um delay. Do cenário Default, se quiser simular erro, conecte para Login / Error ao clicar em “Entrar” (ou use uma condição simulada via diferentes hotspots, dependendo do nível de fidelidade desejado).
O ponto-chave: o estado Loading do botão deve ser uma variante do componente, não um botão separado desenhado manualmente.
Passo 5: valide consistência de estados no protótipo
Ao executar o protótipo, verifique:
Hover/pressed do botão são perceptíveis e coerentes com outros botões.
Foco é visível e não conflita com erro.
Disabled realmente parece desabilitado (e não apenas “mais claro”).
Loading não altera largura do botão nem desloca layout.
Mensagens de erro têm espaçamento consistente e não quebram o grid.
Microinterações e feedback: como padronizar sem exagero
Microinterações são pequenos feedbacks que ajudam o usuário a entender o que aconteceu: um botão que responde ao clique, um campo que evidencia foco, um toast que aparece e some. Em um sistema, microinterações devem ser previsíveis e discretas. O objetivo é reduzir carga cognitiva, não “animar por animar”.
Duração e easing: consistência perceptível
Mesmo sem entrar em detalhes de tokens, defina faixas de duração para transições comuns. Exemplo prático:
Hover/pressed: transição rápida (curta), para parecer responsivo.
Abertura de dropdown/modal: transição um pouco mais longa, para dar contexto espacial.
Loading: indicador contínuo, sem “piscadas”.
Se cada componente tiver uma duração diferente, o produto parece “costurado”. No protótipo, use transições consistentes para simular essa sensação.
Feedback de ação: o que acontece depois do clique
Um clique pode resultar em: navegação, mudança de estado (selected), abertura de overlay, ou processamento (loading). Padronize o feedback por tipo de ação:
Ação imediata: pressed + mudança de estado (ex.: favoritar).
Ação com processamento: pressed + loading + resultado (sucesso/erro).
Ação de navegação: pressed + transição de tela.
Isso evita que um botão “Salvar” em uma tela mostre loading e em outra não, sem justificativa.
Checklist de consistência para estados e protótipos
Use esta lista para revisar componentes e fluxos antes de compartilhar com desenvolvimento:
Todo componente interativo tem State com valores consistentes (Default, Hover, Pressed, Focus, Disabled, Loading quando aplicável).
Foco é visível e padronizado (espessura, cor, offset, raio).
Estados não alteram dimensões do componente (principalmente loading e error).
Selected/Checked/On são propriedades persistentes separadas de estados transitórios.
Erro em formulário tem regra de prioridade com foco (erro permanece, foco adiciona indicador).
Interações locais (hover/pressed) estão no componente; navegação está no fluxo.
Não existem “estados desenhados” manualmente em telas (ex.: borda vermelha solta); tudo vem de variantes.
O protótipo demonstra pelo menos um exemplo real de: hover/pressed, foco, disabled, loading e validação.
Padrões comuns de problemas e como corrigir no sistema
Problema: hover e pressed quase iguais
Se o usuário não percebe diferença, o feedback de clique fica fraco. Ajuste a regra: hover muda cor levemente; pressed muda mais e reduz elevação. No protótipo, teste rapidamente alternando estados para ver se a diferença é perceptível.
Problema: foco some em componentes com fundo forte
Se o outline tem pouco contraste com o fundo, ele desaparece. Solução: aumentar contraste do anel, adicionar offset, ou usar dupla borda (anel externo + interno) quando necessário. Mantenha a regra consistente para todos os componentes.
Problema: disabled parece “apenas mais claro”, mas ainda chama atenção
Disabled precisa reduzir hierarquia e remover affordances como sombra. Se o componente ainda parece clicável, ajuste: reduza contraste do texto, remova sombra, e evite cores saturadas.
Problema: erro quebra layout por causa da mensagem
Mensagens variam de tamanho. Defina comportamento: a mensagem ocupa uma linha e quebra, ou limita e usa tooltip? No protótipo, simule um erro longo para ver se o layout aguenta. Se não, o componente precisa prever esse caso.
Problema: loading muda largura do botão
Se o label some e o botão encolhe, o layout “pula”. Solução: manter o label com opacidade 0 (ocupando espaço) ou reservar espaço fixo. O protótipo deve refletir a regra escolhida.
