Quase todo software que você usa coloca uma janela no seu caminho em algum momento. Ela escurece a página, fica no meio da tela e não deixa você clicar em mais nada até respondê-la. Esse padrão tem um nome preciso, e o nome explica o comportamento: é um modal.
A palavra é usada de forma solta: as pessoas falam pop-up, lightbox, overlay, diálogo e modal como se fossem a mesma coisa. Não são, e essa diferença é o ponto mais importante para entender o padrão, porque é ela que torna um modal poderoso quando está certo e irritante quando está errado.
Este guia cobre a definição, a origem da palavra, os tipos de modal que você realmente vai construir, como um modal se compara aos padrões vizinhos, as oito regras que o tornam suportável, os requisitos de acessibilidade e os casos em que o número certo de modais é zero.
Principais conclusões
- Um modal bloqueia. A propriedade que o define não é o formato nem a sobreposição; é o fato de o resto da interface ficar inutilizável até que o modal seja resolvido.
- "Pop-up" não é sinônimo. Na fala do dia a dia, todo modal é um pop-up; a maioria dos pop-ups não é modal, porque dá para continuar trabalhando ao redor deles.
- A interrupção é o custo. Um modal gasta a atenção do usuário logo de cara, então precisa trazer algo que valha mais do que aquilo que ele estava fazendo.
- Um modal, uma tarefa. No momento em que um modal tem duas ações principais ou três parágrafos de explicação, ele deveria ter sido uma página, um tooltip ou uma notificação.
- Acessibilidade não é opcional. Retenção de foco, Esc para fechar,
role="dialog", foco devolvido ao fechar. Um modal que não pode ser fechado pelo teclado prende as pessoas. - A maioria das mensagens in-app não deveria ser modal. Tooltips, hotspots, banners e feeds de notificações cobrem a maior parte dos casos com uma fração do custo de interrupção.
O que é um modal?
Modal: definição
Um modal é uma janela que se abre sobre a página atual, cobre ou escurece o que está por trás e assume o controle da interface até que a pessoa lide com ela. Enquanto ele está aberto, o conteúdo ao fundo não pode ser clicado, rolado nem acessado com a tecla Tab. O nome descreve esse comportamento, e não a aparência: a aplicação entrou em um modo temporário em que uma única pergunta é a única coisa que você pode responder.
Essa única propriedade, o bloqueio, é o que separa um modal de tudo o mais que aparece sobre uma página. Um banner de cookies que você pode ignorar enquanto lê não é modal. Uma bolha de chat no canto não é modal. Um tooltip apontando para um botão não é modal. Uma caixa de confirmação perguntando se você realmente quer excluir doze registros é modal, porque não há mais nada que você possa fazer até responder.
Por isso, a melhor forma de entender um modal é como uma troca. Você toma a atenção do usuário à força e, em troca, promete que aquilo que está mostrando importa mais do que o que ele estava fazendo. A maioria dos modais mal recebidos são simplesmente trocas em que a segunda metade nunca foi verdade.
De onde vem a palavra "modal"
O termo é anterior à web. No software de desktop, uma interface podia ser modal ou não modal (modeless). Uma janela não modal deixava você continuar trabalhando na aplicação principal enquanto ficava aberta: um painel de localizar e substituir, por exemplo. Uma janela modal travava a aplicação até você fechá-la. A palavra veio da ideia de "modo": um estado temporário em que as mesmas entradas significam algo diferente do habitual.
É por isso que as expressões janela modal, diálogo modal e caixa modal descrevem a mesma coisa. "Janela" é uma herança dos sistemas operacionais de desktop, em que os diálogos eram de fato janelas separadas. Na web, o modal é apenas um elemento posicionado acima da página sobre uma sobreposição, mas o comportamento que ele herda é idêntico.
Teste rápido: se você ainda consegue clicar em algo por trás, não é um modal. Pode ser um popover, um toast, um banner ou um slideout: todos úteis, todos mais baratos e todos tratados mais abaixo.
A anatomia de um modal
Quase todo modal, seja qual for a finalidade, é construído com as mesmas seis partes. Conhecer a lista é útil porque a maioria dos problemas com modais acaba sendo uma parte ausente ou duplicada, e não um problema de design.
As seis partes de um modal. A maioria dos problemas com modais é uma parte ausente, geralmente o botão de fechar ou a ação principal única, e não um problema de estilo.
Duas das seis merecem destaque. O botão de fechar precisa existir mesmo quando você tem certeza de que o usuário deve agir, porque um modal sem saída é a forma de frustração com interfaces mais relatada de todas. E a linha de ações precisa conter exatamente um botão principal. Dois botões principais não são uma escolha, são um impasse.
Os 6 tipos de modal
Os modais se dividem em um número pequeno de funções reconhecíveis. O tipo determina quase todo o resto: o quanto ele pode insistir, se pode ser exibido mais de uma vez e se merece mesmo bloquear a interface.
-
Modal de boas-vindas
A primeira coisa que alguém vê depois de entrar pela primeira vez. A função dele é direcionar, não cumprimentar: confirmar quem é a pessoa, fazer no máximo uma pergunta que muda o que acontece a seguir e oferecer uma primeira ação óbvia. Parecido com uma tela de boas-vindas completa, mas diferente dela, já que a tela pode ocupar toda a área visível.
-
Caixa de confirmação
O modal original e o mais fácil de defender. Algo destrutivo ou irreversível está prestes a acontecer e o sistema quer um sim explícito. Diga a consequência no título ("Excluir 12 registros?" é melhor que "Tem certeza?") e rotule o botão com o verbo, e não com "OK".
-
Modal de anúncio
Usado para avisar os usuários atuais de que algo mudou. Justificado para mudanças que alteram a forma como alguém trabalha; não justificado para cada release. Na dúvida, o lugar dele é um feed ou um banner; veja como anunciar uma nova funcionalidade para escolher o canal.
-
Modal de formulário ou tarefa
Uma tarefa curta e independente tirada da página: convidar um colega, renomear um projeto, escolher um plano. Funciona quando a tarefa tem menos de uns cinco campos e o contexto da página por trás é útil. Não funciona quando vira um assistente em várias etapas: nesse ponto ela pede para ser uma página com uma URL à qual dá para voltar.
-
Modal de mídia ou lightbox
Abre uma imagem, um vídeo ou um documento em tamanho maior sobre a página. É o tipo menos polêmico, porque o usuário pediu por ele ao clicar. A tecla Esc e um botão de fechar visível importam mais aqui do que em qualquer outro lugar, já que as pessoas abrem esses modais esperando sair logo em seguida.
-
Modal de etapa de tour
Uma etapa de um walkthrough guiado grande demais para ficar ancorada a um único elemento, normalmente as etapas de abertura e de encerramento. As etapas do meio de um bom tour costumam ser tooltips. Exemplos reais estão reunidos nos nossos exemplos de modais de product tour.
Um modal de boas-vindas fazendo o seu verdadeiro trabalho: uma pergunta cuja resposta muda o que o usuário vê em seguida, em vez de um parágrafo de introdução.
Modal vs pop-up vs tooltip vs slideout vs banner
Todos os padrões vizinhos colocam conteúdo sobre uma página. O que os separa é quanto da atenção do usuário eles tomam e se a tomam à força. A tabela é o jeito mais rápido de escolher.
| Padrão | Bloqueia a página? | Custo de atenção | Use quando |
|---|---|---|---|
| Modal | Sim, nada por trás pode ser clicado | O mais alto | A decisão precisa acontecer agora, ou a tarefa merece foco total |
| Popover / dropdown | Não, fecha quando você clica fora | Baixo | Detalhes ou opções extras ligados a um controle específico |
| Tooltip | Não | Muito baixo | Explicar um elemento, no próprio lugar, sem interromper o fluxo |
| Slideout / painel lateral | Às vezes, depende da implementação | Médio | Conteúdo secundário que precisa de espaço, mas mantém a página como contexto |
| Banner / barra de notificação | Não | Baixo, e cai ainda mais com o tempo | Mensagens persistentes e não urgentes sobre as quais as pessoas podem agir depois |
| Toast | Não, some sozinho | O mais baixo | Confirmar que algo acabou de acontecer |
A regra prática que sai dessa tabela: comece pela linha de baixo e só suba quando for obrigado. A maioria das mensagens in-app lançadas como modais teria funcionado como tooltip ou banner, e as que são lançadas como banners muitas vezes falham pelo motivo oposto: as pessoas deixam de vê-las, um problema tratado em cegueira de banner.
Quando um modal é o padrão certo
Há quatro situações em que interromper é de fato a escolha correta, e vale a pena ser rigoroso com elas.
Excluir, cancelar, publicar para um público, gastar dinheiro. O custo de um clique acidental supera o custo da interrupção.
Menos de cinco campos, independente, e melhor com a página por trás como contexto do que como uma tela separada.
Primeiro login, antes de qualquer trabalho começar. Nada está sendo interrompido ainda, e é exatamente por isso que o modal de boas-vindas é a única mensagem que tem passe livre.
Ele clicou na miniatura, no botão "convidar", no link de pré-visualização. Um modal aberto a pedido não é interrupção nenhuma.
Quem está na metade de um formulário ou de um fluxo vai fechar sem ler, e vai gostar um pouco menos do produto do que antes.
Webinars, pesquisas, releases menores e upsells pertencem a um feed, a um banner ou a um e-mail; veja mensagens in-app para conhecer as alternativas.
Boas práticas de UX para modais: 8 regras
Nenhuma delas é estética. Cada uma vem de uma forma específica como os modais dão errado em produção.
- Um modal, uma tarefa
- Diga a consequência no título
- Sempre ofereça uma saída
- Nunca empilhe modais
- Respeite quando o modal é fechado
- Cuide da altura, não só da largura
- Repense tudo no mobile
- Acione pelo comportamento, não pelo relógio
1. Um modal, uma tarefa
Um modal deve fazer uma pergunta ou concluir uma tarefa. O sintoma mais claro de um modal fazendo duas coisas são dois botões principais, seguidos de perto por um título unido por um "e". Se você não consegue escrever o título como uma única frase curta, o conteúdo pede para ser uma página.
2. Diga a consequência no título
"Tem certeza?" não diz ao leitor nada que ele já não soubesse. "Excluir este workspace e os 34 documentos dele?" permite decidir sem nem ler o texto. O mesmo vale para os botões: rotule-os com o verbo (Excluir, Publicar, Convidar), nunca com OK. Nosso guia de microcopy para UX traz as fórmulas para os dois.
3. Sempre ofereça uma saída
Um botão de fechar visível, a tecla Esc e um clique na sobreposição devem fechar o modal. A única exceção legítima é um modal no meio de uma confirmação destrutiva, em que o clique na sobreposição é desativado para evitar acidentes, e mesmo assim a tecla Esc e o botão de fechar continuam lá.
4. Nunca empilhe modais
Um modal que abre outro modal gera duas sobreposições, duas retenções de foco e um usuário sem a menor ideia do que cada toque na tecla Esc vai fazer. Se um modal precisa de uma pergunta complementar, substitua o conteúdo no próprio lugar e mantenha um único contêiner.
5. Respeite quando o modal é fechado
Se alguém fecha um modal, isso é uma resposta. Mostrá-lo de novo no próximo carregamento de página transforma um leve incômodo em um motivo para ir embora. Modais de onboarding, em especial, devem ser exibidos uma vez e nunca mais, a não ser que a situação do usuário mude de verdade; a lógica para isso está em gatilhos de onboarding.
6. Cuide da altura, não só da largura
Designers testam modais em telas altas. Em um notebook com a barra de ferramentas do navegador, um modal que rola internamente esconde os próprios botões de ação, e o usuário não consegue ver aquilo em que deveria clicar. Limite a altura do conteúdo, faça rolar só o corpo e fixe a linha de ações.
7. Repense tudo no mobile
Um diálogo centralizado em um celular vira uma ocupação da tela inteira, quer você tenha planejado assim ou não. Torne isso intencional: largura total, um cabeçalho de verdade com o botão de fechar em uma posição que o polegar alcança e ações empilhadas em vez de lado a lado.
8. Acione pelo comportamento, não pelo relógio
"Mostrar após 5 segundos" interrompe quem por acaso estiver lendo no quinto segundo. Em vez disso, dispare modais em eventos significativos: um estado vazio alcançado, uma funcionalidade aberta pela primeira vez, um limite do plano atingido. O acionamento por comportamento também é o que impede o mesmo modal de chegar a usuários para os quais ele não se aplica, e é aí que a segmentação de usuários mostra o seu valor.
Acessibilidade em modais: o inegociável
Um modal é um dos poucos padrões que podem realmente prender um usuário. Quem navega pelo teclado ou com leitor de tela pode acabar sem conseguir chegar ao botão de fechar ou sem perceber que a página por trás ficou inerte. Os requisitos são curtos e vale tratá-los como uma checklist, e não como uma aspiração.
| Requisito | O que significa na prática |
|---|---|
| Anunciá-lo como diálogo | role="dialog" com aria-modal="true" no contêiner |
| Dar um nome a ele | aria-labelledby apontando para o elemento de título do modal |
| Levar o foco para dentro | Ao abrir, focar o título ou o primeiro elemento interativo, não a página por trás |
| Reter o foco | Tab e Shift+Tab circulam dentro do modal e nunca chegam ao fundo |
| Devolver o foco ao fechar | O foco volta ao controle que abriu o modal, para que o usuário não perca o lugar |
| Fechar com Esc | Sempre, com a única exceção de uma confirmação destrutiva em andamento |
| Ocultar o fundo | Marcar a página por trás como inerte para que as tecnologias assistivas não leiam através da sobreposição |
| Bloquear a rolagem do fundo | Rolar a página por trás de um modal desorienta no desktop e quebra no mobile |
Se você está construindo um onboarding que precisa cumprir um padrão formal de acessibilidade, os requisitos mais amplos (contraste, movimento, tempo, operação por teclado em tours e checklists) estão no nosso guia de onboarding acessível.
Modal: o que fazer e o que evitar
Faça
- Escreva o título como a consequência, não como uma pergunta sobre certeza
- Mantenha exatamente uma ação principal e uma forma discreta de fechar
- Acione pelo comportamento: um evento, um estado, um limite atingido
- Mostre modais de onboarding uma vez e depois confie no usuário
- Projete a versão mobile como uma folha em tela cheia, de propósito
- Teste tudo com o teclado antes de lançar
Não faça
- Interromper alguém no meio de um formulário ou de um fluxo
- Empilhar um segundo modal em cima do primeiro
- Esconder o botão de fechar para forçar uma decisão
- Usar um modal para novidades que caberiam em um feed
- Deixar o conteúdo rolar para além dos botões de ação
- Mostrar de novo um modal que já foi fechado
Como criar modais sem código com a Kompassify
A maioria dos modais de que um produto precisa depois do lançamento não são funcionalidades do produto; são mensagens. Um modal de boas-vindas para um novo segmento, um anúncio de uma mudança que altera o fluxo de trabalho de alguém, a etapa de abertura de um walkthrough. Construir cada um como um componente, lançá-lo em uma release e removê-lo em outra é o motivo pelo qual tantos deles nunca chegam a ser criados, e pelo qual os que são criados continuam no ar muito depois de deixarem de ser relevantes.
A Kompassify coloca essa camada fora do código do produto. Você cria o modal visualmente, define quem o vê com regras de segmentação, aciona-o em um evento real em vez de um temporizador e o configura para aparecer uma única vez. Cada modal mostra quantas pessoas o viram, o fecharam e agiram a partir dele, então a decisão de mantê-lo ou eliminá-lo é tomada com base em dados, e não em quem lembra que ele existe. O mesmo editor cobre os padrões mais baratos (tooltips, hotspots, checklists, anúncios in-app), e isso importa, porque a resposta honesta para "isso deveria ser um modal?" geralmente é não.
Um modal de anúncio criado sem uma release. Como ele vive fora do código, desativá-lo é um clique em um botão, e não um ticket.
Crie seu primeiro modal sem abrir ticket para a engenharia
A Kompassify permite que times de produto, onboarding e customer success criem modais, tooltips, checklists e anúncios in-app visualmente, direcionem cada um por segmento e comportamento e meçam o resultado de cada um. Grátis até 100 usuários ativos mensais, planos a partir de $129/mês, em conformidade com o GDPR e hospedado na UE.
Comece grátis →A versão em uma frase
Um modal é uma janela que interrompe todo o resto até ser respondida, o que faz dele o padrão mais forte que você tem, o mais caro que você pode usar e a resposta errada para a maioria das perguntas para as quais ele é usado.
Perguntas frequentes
O que é um modal?
Um modal é uma janela que se abre sobre a página atual, escurece ou cobre o que está por trás e assume o controle da interface até que a pessoa lide com ela. Enquanto ele está aberto, o resto da página não pode ser clicado, rolado nem acessado com a tecla Tab. A palavra descreve esse comportamento, e não a aparência: um modal coloca a aplicação em um modo temporário em que uma única pergunta é a única coisa que você pode responder. É por isso que uma caixa de confirmação, uma janela de boas-vindas no primeiro login e um convite de upgrade em tela cheia são todos modais, mesmo sem nenhuma semelhança visual entre eles.
Qual é a diferença entre um modal e um pop-up?
Pop-up é uma palavra vaga e informal para qualquer coisa que apareça sobre uma página, incluindo janelas do navegador abertas por script, avisos de cookies, bolhas de chat e anúncios. Modal é um termo técnico preciso: o conteúdo bloqueia a interação com tudo o que está por trás até ser fechado. Todo modal pode ser chamado de pop-up, mas a maioria das coisas que as pessoas chamam de pop-up não é modal, porque dá para continuar usando a página ao redor. No trabalho de produto, a distinção importa porque bloquear a interface é a parte cara, e isso precisa ser justificado.
O que é uma janela modal em web design?
Uma janela modal é o próprio elemento visível: um painel, geralmente centralizado, sobre uma camada escurecida que cobre a página. Na marcação, costuma ser um contêiner com role="dialog" e aria-modal="true", um nome acessível vindo do seu título, uma retenção de foco que mantém o foco do teclado dentro dele e um botão de fechar. Janela modal, diálogo modal e caixa modal se referem ao mesmo padrão; a palavra janela foi simplesmente herdada do software de desktop, em que os diálogos eram de fato janelas separadas do sistema operacional.
Modais são uma UX ruim?
Modais não são ruins por natureza; eles são caros. Interromper alguém se justifica quando a mensagem é de fato mais importante do que aquilo que a pessoa estava fazendo: uma ação destrutiva que precisa de confirmação, uma tarefa curta e focada ou uma mensagem de boas-vindas no primeiro acesso que prepara o resto da sessão. Vira UX ruim quando a interrupção serve à empresa e não ao usuário, quando aparece enquanto alguém está no meio de uma tarefa, quando se repete depois de ter sido fechada ou quando o conteúdo poderia ter sido um tooltip, um banner ou um item em um feed de notificações.
O que é um modal de boas-vindas?
Um modal de boas-vindas é o modal exibido na primeira vez que alguém entra em um produto. A função dele não é dizer olá, e sim direcionar: confirmar que a pessoa está no lugar certo, fazer no máximo uma ou duas perguntas que mudam o que ela verá a seguir e entregar uma única ação óbvia, como iniciar um tour curto ou criar o primeiro item. Ele deve aparecer uma vez, poder ser fechado sem penalidade e nunca servir de recipiente para uma lista de funcionalidades que ninguém pediu.
Como tornar um modal acessível?
Dê ao contêiner role="dialog" e aria-modal="true", rotule-o com o próprio título por meio de aria-labelledby, mova o foco do teclado para dentro do modal quando ele abrir e devolva o foco ao elemento que o acionou quando ele fechar, prenda Tab e Shift+Tab dentro dele para que o foco não escape para trás da sobreposição, feche-o com a tecla Esc, oculte o fundo das tecnologias assistivas e bloqueie a rolagem do fundo. Um modal que não pode ser fechado pelo teclado não é apenas incômodo: ele prende alguns usuários na página.