Componentes comuns de UI em apps e quando usar cada um

Botões (primário, secundário, terciário)

Objetivo: botões disparam ações. Eles devem deixar claro o que acontece e o que é mais importante na tela.

Quando usar cada tipo

• Primário: a ação principal da tela (ex.: “Salvar”, “Continuar”, “Confirmar”). Use 1 por tela sempre que possível.
• Secundário: ações alternativas relevantes, mas não a principal (ex.: “Cancelar”, “Voltar”, “Editar”).
• Terciário (texto/ghost): ações de baixa ênfase ou contextuais (ex.: “Saiba mais”, “Pular”, “Ver detalhes”).

Comportamento esperado

• Feedback imediato: ao tocar, o botão muda de estado (pressionado) e a ação inicia (ou mostra carregamento).
• Prevenção de toque duplo: após disparar, desabilite temporariamente ou mostre loading para evitar duplicidade.
• Área de toque confortável: garanta área mínima de toque e espaçamento para evitar cliques acidentais.

Variações comuns

• Ícone + texto: útil quando o ícone reforça o significado (ex.: “Compartilhar”). Evite ícones ambíguos.
• Somente ícone: use apenas para ações muito reconhecíveis (ex.: lupa para buscar). Preferir com tooltip/label acessível.
• Botão destrutivo: para ações irreversíveis (ex.: “Excluir”). Diferencie visualmente e reforce com microcopy.
• Botão com loading: substitui o texto por indicador e mantém largura para evitar “pulo” de layout.

Estados (exemplos)

Microcopy: boas práticas

• Use verbo + objeto: “Adicionar endereço”, “Enviar mensagem”.
• Evite rótulos genéricos: “OK”, “Sim”, “Enviar” (enviar o quê?).
• Para ações destrutivas, seja explícito: “Excluir conta” em vez de “Excluir”.

Armadilhas

• Muitos primários na mesma tela: cria disputa de atenção e indecisão.
• Ações importantes como terciárias: o usuário não encontra ou não confia.
• Botões sem feedback: gera toque repetido e erros (duplicar pedidos, pagamentos etc.).

Passo a passo prático: escolhendo botões em uma tela

1. Liste as ações possíveis na tela.
2. Marque qual é a ação principal (o “próximo passo” mais comum).
3. Defina 1 botão primário para ela.
4. Transforme “Cancelar/Voltar” em secundário (ou link/terciário, se fizer sentido).
5. Rebaixe ações raras para terciário ou menu contextual.
6. Defina estados: desabilitado (regras), loading (após toque), e feedback de erro/sucesso.

Campos de texto (inputs)

Objetivo: coletar informações do usuário com o mínimo de esforço e erro.

Quando usar

• Quando a resposta é aberta (nome, e-mail, observação).
• Quando a lista de opções seria grande demais para um seletor.

Comportamento esperado

• Foco visível: ao tocar, destaque borda/linha e mostre cursor.
• Teclado adequado: e-mail, numérico, telefone, senha.
• Validação: preferir validação progressiva (enquanto digita) para regras simples; para regras complexas, validar ao sair do campo.
• Erros acionáveis: mensagem diz como corrigir, não só o que está errado.

Variações comuns

• Texto curto vs. área de texto: use área de texto para comentários/descrições.
• Máscara: para formatos (CPF, telefone). Cuidado para não atrapalhar colar/editar.
• Senha: com alternância “mostrar/ocultar”.
• Busca: com ícone e ação de limpar.

Estados (exemplos)

Microcopy: boas práticas

• Label > placeholder: placeholder some ao digitar; não use como única indicação.
• Exemplos no placeholder ajudam formato: “DD/MM/AAAA”.
• Mensagens de erro devem ser específicas: “Senha deve ter 8+ caracteres” em vez de “Senha inválida”.

Armadilhas

• Formulários longos: quebre em etapas quando possível.
• Validação tardia: avisar erro só no final frustra; prefira feedback antes.
• Máscaras rígidas: dificultam colar e editar no meio do texto.

Passo a passo prático: desenhando um campo de texto

1. Defina o tipo de dado (texto, e-mail, número, senha).
2. Escolha label claro e, se útil, placeholder com exemplo.
3. Defina regra de validação e quando ela ocorre (ao digitar, ao sair, ao enviar).
4. Escreva mensagens de erro com instrução de correção.
5. Inclua estados: foco, erro, desabilitado, loading (se houver verificação remota).

Seletores (radio, checkbox, switch)

Objetivo: permitir escolhas com clareza e previsibilidade. Cada seletor tem um significado diferente; usar o tipo errado confunde.

Radio (opção única)

Quando usar: escolha de uma opção entre poucas (ex.: “Forma de entrega: Padrão / Expressa”).

• Comportamento: selecionar uma opção desmarca as outras.
• Variações: lista vertical; opção com descrição; opção com preço.
• Armadilha: usar radio para ligar/desligar (isso é switch).

Checkbox (múltiplas opções)

Quando usar: selecionar várias opções independentes (ex.: “Preferências: E-mail, SMS, Push”).

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• Comportamento: cada item marca/desmarca sem afetar os demais.
• Variações: “Selecionar tudo”; estado indeterminado (alguns selecionados).
• Armadilha: usar checkbox para uma escolha única (gera dúvida).

Switch (liga/desliga imediato)

Quando usar: alternar um estado que entra em vigor imediatamente (ex.: “Ativar notificações”).

• Comportamento: tocar alterna e aplica na hora; se depender de rede, mostrar feedback (loading) e reverter em falha.
• Variações: com descrição; com dependência (desabilitar quando não aplicável).
• Armadilha: usar switch para uma escolha que exige confirmação (melhor radio/checkbox + botão “Salvar”).

Microcopy: boas práticas

• Rótulos de switch devem ser estado ou ação clara: “Receber notificações” (não “Notificações”).
• Em radio/checkbox, use rótulos curtos e, se necessário, uma descrição menor abaixo.

Estados (exemplos)

Listas

Objetivo: apresentar coleções de itens de forma escaneável (contatos, mensagens, produtos, configurações).

Quando usar

• Quando o usuário precisa percorrer e comparar itens rapidamente.
• Quando cada item leva a um detalhe (padrão “lista → detalhe”).

Comportamento esperado

• Item clicável claro: use affordance (seta, chevron, destaque ao toque).
• Separadores e agrupamento: divisórias, cabeçalhos de seção, espaçamento consistente.
• Estados de carregamento e vazio: skeleton/loading; estado vazio com instrução.

Variações comuns

• Lista simples: título + subtítulo.
• Lista com mídia: avatar/thumbnail + texto.
• Lista de configurações: label + valor atual + chevron; ou label + switch.
• Lista com ações: swipe actions ou menu contextual (use com cuidado).

Microcopy: boas práticas

• Itens devem começar com a informação mais útil (ex.: nome do contato, nome do produto).
• Subtítulo deve complementar (ex.: “Última mensagem: …”, “Entrega amanhã”).
• Estado vazio: diga o que aconteceu e o que fazer: “Você ainda não tem favoritos. Toque em ‘Adicionar aos favoritos’ em um item.”

Armadilhas

• Ações escondidas (swipe): pouca descobribilidade; ofereça alternativa visível para ações críticas.
• Itens com altura irregular: dificulta escaneabilidade.
• Sem estado vazio: usuário acha que quebrou.

Cards

Objetivo: agrupar conteúdo relacionado em um bloco visual, destacando uma unidade (produto, notícia, resumo de pedido).

Quando usar

• Quando há múltiplas informações por item e você quer hierarquia interna (título, imagem, preço, ação).
• Quando precisa de separação forte entre itens (feed, vitrine).

Comportamento esperado

• Card clicável vs. botões internos: se o card inteiro abre detalhes, evite colocar muitos botões dentro (conflito de toque).
• Feedback ao toque: destaque/elevação no pressionado.

Variações comuns

• Card informativo: sem ação direta, apenas leitura.
• Card com CTA: botão primário/ secundário dentro do card.
• Card horizontal: bom para carrosséis; cuidado com acessibilidade e navegação.

Microcopy: boas práticas

• Título curto e específico; evite truncar informação essencial.
• Se houver CTA, use verbo + objeto: “Ver pedido”, “Repetir compra”.

Armadilhas

• Card como “caixa genérica” para tudo: vira ruído visual; use quando o agrupamento realmente ajuda.
• Muitos elementos competindo: imagem, tags, preço, botões; priorize 1 ação.

Chips/Tags

Objetivo: representar categorias, filtros, atributos ou seleções compactas.

Quando usar

• Filtros rápidos: “Entrega grátis”, “Aberto agora”.
• Seleção múltipla compacta: interesses, preferências.
• Tags informativas: “Novo”, “Promoção”, “Pendente”.

Comportamento esperado

• Selecionável: muda estado visual ao ativar/desativar.
• Removível: pode ter “x” para remover um filtro/seleção.

Variações comuns

• Assist chip: ação rápida (ex.: “Usar localização”).
• Filter chip: alterna filtros.
• Input chip: representa itens escolhidos (ex.: destinatários).
• Status tag: apenas informativa, sem clique.

Estados (exemplos)

Microcopy: boas práticas

• Use termos curtos (1–3 palavras).
• Evite siglas internas; prefira linguagem do usuário.

Armadilhas

• Chips demais: vira “nuvem de tags” difícil de escanear; agrupe e permita “Ver mais”.
• Chips clicáveis sem parecer clicáveis: garanta affordance (contorno, preenchimento, feedback).

Tabs (abas)

Objetivo: alternar entre seções no mesmo nível hierárquico (ex.: “Detalhes / Avaliações / Perguntas”).

Quando usar

• Quando existem 2 a 5 seções principais equivalentes.
• Quando a troca deve ser rápida sem sair da tela.

Comportamento esperado

• Indicador claro de aba ativa: sublinhado, cor, peso.
• Persistência: manter a aba selecionada ao voltar para a tela.
• Gestos: swipe entre abas pode ajudar, mas não deve ser o único meio.

Variações comuns

• Tabs fixas: todas visíveis.
• Tabs roláveis: para muitas abas; cuidado com descobribilidade das que ficam fora.
• Tabs com ícone + texto: útil quando o texto é curto; evite redundância.

Microcopy: boas práticas

• Rótulos consistentes e paralelos: “Ativos / Concluídos” (mesma classe gramatical).
• Evite frases longas; prefira palavras.

Armadilhas

• Usar tabs para etapas: etapas são sequenciais; use um stepper/fluxo, não tabs.
• Muitas abas: vira navegação escondida; considere menu ou filtros.

Modais e Bottom Sheets

Objetivo: interromper o fluxo para pedir decisão, mostrar informação crítica ou apresentar opções/contexto sem sair da tela.

Quando usar modal (diálogo)

• Confirmação crítica: excluir, sair sem salvar, pagar.
• Permissões/decisões binárias: “Permitir / Não permitir” (quando aplicável).

Quando usar bottom sheet

• Escolha de opções: lista de ações (“Compartilhar”, “Copiar link”, “Denunciar”).
• Formulário curto/contextual: inserir cupom, escolher variação.
• Detalhe rápido: resumo sem navegação completa.

Comportamento esperado

• Fechamento claro: botão “Cancelar/Fechar” ou gesto; não esconda como sair.
• Foco: bloquear interação com o fundo (modal) ou manter contexto (sheet).
• Teclado e rolagem: em formulários, garantir que campos e botões não fiquem cobertos.

Variações comuns

• Modal de confirmação: título + mensagem + 2 botões (primário e secundário).
• Modal informativo: 1 botão “Entendi” (use com parcimônia).
• Bottom sheet parcial/expandida: começa pequena e pode expandir.

Microcopy: boas práticas

• Título orientado à ação: “Excluir item?”
• Mensagem objetiva: explique consequência: “Isso remove o item do seu carrinho.”
• Botões específicos: “Excluir” e “Cancelar” (evite “Sim/Não”).

Estados (exemplos)

• Normal: conteúdo legível, botões claros.
• Pressionado: feedback nos botões.
• Desabilitado: se houver campo obrigatório no modal/sheet, desabilite CTA e explique.

Armadilhas

• Modais demais: interrompem e cansam; prefira inline quando possível.
• Empilhar modais: difícil de entender onde está; evite modal sobre modal.
• Sheet com ações destrutivas sem destaque: se houver “Excluir”, diferencie e, se necessário, confirme.

Passo a passo prático: criando um modal de confirmação

1. Defina a ação crítica e a consequência.
2. Escreva título em forma de pergunta (“Excluir endereço?”).
3. Escreva 1–2 frases com impacto (“Você não poderá usar este endereço novamente.”).
4. Defina botões: primário destrutivo (“Excluir”) + secundário (“Cancelar”).
5. Garanta fechamento alternativo (X ou gesto) apenas se não aumentar risco de erro.
6. Teste o caso de erro (falha de rede): mostre mensagem e mantenha o usuário no contexto.

Banners

Objetivo: comunicar informação importante de forma persistente na tela, sem interromper como um modal (ex.: aviso de conexão, atualização necessária, promoção relevante).

Quando usar

• Status do sistema: “Sem conexão. Tentando reconectar…”
• Ação recomendada: “Complete seu perfil para melhorar recomendações” com CTA.
• Aviso contextual: “Seu cartão expira em breve” com ação “Atualizar”.

Comportamento esperado

• Não bloquear tarefa principal (a menos que seja crítico).
• Ser dispensável quando não for crítico (botão “Fechar”).
• Persistência adequada: se o problema continua (ex.: offline), o banner permanece.

Variações comuns

• Informativo: sem ação.
• Com CTA: botão secundário/terciário.
• Crítico: maior destaque; pode exigir ação para prosseguir (use com cuidado).

Microcopy: boas práticas

• Comece pelo fato: “Você está offline”.
• Depois a orientação: “Algumas ações podem falhar. Tente novamente mais tarde.”
• CTA específico: “Atualizar agora”, “Ver detalhes”.

Armadilhas

• Banners promocionais permanentes: viram ruído e reduzem confiança.
• Mensagem vaga: “Ocorreu um erro” sem orientação.

Toasts (mensagens temporárias)

Objetivo: dar feedback rápido e não intrusivo sobre uma ação (ex.: “Salvo”, “Copiado”, “Falha ao enviar”).

Quando usar

• Confirmação leve: ação concluída sem necessidade de decisão.
• Erro recuperável: falha temporária com instrução curta.

Quando não usar

• Para informações críticas que o usuário não pode perder (prefira banner/modal).
• Para erros que exigem correção imediata no formulário (prefira mensagem inline no campo).

Comportamento esperado

• Duração curta: aparece e some automaticamente.
• Não cobrir controles essenciais: posicione para não bloquear CTA.
• Ação opcional: em alguns casos, “Desfazer” (undo) é melhor que confirmação.

Microcopy: boas práticas

• Curto e direto: “Link copiado”.
• Para erro: “Falha ao salvar. Tente novamente.”
• Se houver undo: “Item removido” + “Desfazer”.

Estados (exemplos)

• Normal: mensagem neutra.
• Sucesso/erro: diferenciar por cor/ícone, sem depender só de cor.
• Pressionado: se houver ação (ex.: “Desfazer”), botão com feedback.

Armadilhas

• Toast como única confirmação de algo importante: usuário pode não ver.
• Excesso de toasts: polui e interrompe leitura; agrupe feedback quando possível.

Checklist rápido de consistência (para qualquer componente)

• Objetivo claro: o componente escolhido combina com o tipo de decisão (ação, entrada, escolha única/múltipla, status)?
• Estados definidos: normal, pressionado, desabilitado, erro (quando aplicável), carregando (quando aplicável).
• Microcopy acionável: rótulos específicos, mensagens de erro com correção, CTAs com verbo + objeto.
• Armadilhas evitadas: ações críticas não ficam escondidas; interrupções (modais) são raras e justificadas.