Módulo 3 · 4 de 7
O que projetar quando tudo dá errado
Leitura: ~6 min
Vamos começar com uma pergunta honesta: quando você projeta uma tela, qual cenário vem primeiro na sua cabeça? O usuário preencheu tudo certo, a API respondeu rápido, a lista está cheia de conteúdo e a conexão é perfeita. Esse é o caminho feliz. E a maioria dos designers para por aí.
O problema é que uma parcela significativa dos seus usuários vive no caminho triste. A internet caiu. O servidor demorou. O formulário deu erro. A busca não retornou nada. E quando isso acontece, o que eles veem? Na maioria das vezes, uma tela branca. Ou pior: uma mensagem genérica que diz "Erro" sem explicar nada.
Neste tópico, vamos falar sobre os estados que ninguém quer projetar, mas que separam interfaces amadoras de produtos profissionais.
O caminho feliz e o caminho triste
Pense comigo. Quando um arquiteto projeta um prédio, ele não desenha só os andares, as salas e a fachada bonita. Ele precisa projetar as saídas de emergência, os extintores, a sinalização de rota de fuga, o gerador de energia. Ninguém quer que o incêndio aconteça, mas se acontecer, as pessoas precisam saber para onde ir.
Projetar apenas o caminho feliz é como construir um prédio sem saída de emergência. Funciona no dia a dia, mas no momento que algo dá errado, ninguém sabe para onde ir. E em produtos digitais, "algo dá errado" não é exceção. É rotina.
Estados de erro são todas as situações em que a experiência ideal não acontece. Pode ser um dado que não carregou, uma ação que falhou, uma lista que está vazia, ou uma conexão que caiu. Cada uma dessas situações precisa de uma resposta visual pensada, projetada e testada.
Os quatro cenários que você precisa cobrir
Não existe uma lista infinita de coisas que podem dar errado. Na prática, a maioria dos estados de erro que o designer precisa cobrir se encaixa em quatro categorias. Vamos olhar cada uma.
1. A API não respondeu (timeout)
Imagine que o usuário abriu a tela de pedidos e a API que traz os dados está lenta. O que acontece enquanto ele espera? Se a resposta for "nada", você tem um problema. O usuário não sabe se o app travou, se a internet caiu ou se precisa esperar.
A solução mais comum é o skeleton loading: aquelas formas cinzas que imitam o layout do conteúdo enquanto ele carrega. Você já viu isso no LinkedIn, no YouTube e em vários outros apps. O skeleton comunica "calma, estou carregando" sem precisar de texto. E se o carregamento demora demais? Um botão de "Tentar novamente" (retry) dá ao usuário o controle de volta.
Na hora de projetar: crie uma variante do componente em estado de loading. No Figma, isso vira um variant do card, da lista ou da seção. O dev precisa desse estado tanto quanto precisa do estado final.
2. Sem conexão (offline)
O usuário está no metrô, no elevador ou em uma área com sinal ruim. A conexão caiu. O que o app mostra?
Os melhores produtos mostram o conteúdo que já foi carregado antes (cached content) e exibem um banner discreto avisando "Você está offline. Mostrando a última versão salva." Isso é muito melhor do que uma tela branca com um ícone de dinossauro.
Como designer, você precisa projetar esse banner. Onde ele aparece? Que cor tem? Ele some quando a conexão volta? Ele bloqueia ações que dependem de internet (como enviar um formulário) ou deixa o usuário tentar e mostra o erro depois? São decisões de design, não de código.
3. O formulário falhou
O usuário preencheu tudo, clicou em "Enviar" e... erro. Pode ser uma validação do front-end (campo obrigatório vazio, e-mail inválido) ou um erro do servidor (a API caiu no meio do processo). Em ambos os casos, o usuário precisa entender o que deu errado e o que fazer.
Para erros de validação, a boa prática é o inline error: a mensagem de erro aparece diretamente abaixo do campo que tem problema, em vermelho, explicando o que corrigir. "Este campo é obrigatório" é melhor que "Erro no formulário". "O e-mail precisa ter um @" é melhor que "Formato inválido".
Para erros de servidor, o padrão mais usado é o toast notification: aquela mensagem que aparece no canto da tela, geralmente em vermelho, avisando que algo falhou. "Não foi possível salvar. Tente novamente em alguns segundos." O toast precisa ser visível, mas não bloquear a tela inteira.
4. Dados vazios (empty state)
O usuário acabou de criar a conta. Abre a tela de "Meus projetos" e... não tem nenhum projeto. A lista está vazia. O que aparece?
Se a resposta for um espaço em branco, o usuário fica perdido. Empty states são uma oportunidade de guiar o usuário para a próxima ação. As melhores soluções combinam uma ilustração simpática, um texto que explica a situação ("Você ainda não tem projetos") e um CTA claro ("Criar primeiro projeto").
O mesmo vale para buscas sem resultado: "Nenhum resultado para 'xyzabc'. Tente outra busca ou veja os mais populares." Ofereça uma saída, não um beco sem saída.
Por que designers ignoram isso?
A resposta é simples: a gente projeta o caminho feliz porque é mais gostoso. É mais bonito no portfólio. É mais fácil de apresentar no review. E os stakeholders raramente pedem para ver o que acontece quando a internet cai.
Mas aqui vai a verdade: designers que projetam estados de erro entregam fluxos completos, e isso aparece. É a diferença entre "faz tela" e "pensa produto". Quando você entrega um fluxo completo, incluindo loading, erro, vazio e offline, o time de engenharia percebe. O PM percebe. E na próxima conversa sobre quem deve liderar o design de um fluxo crítico, seu nome aparece primeiro.
Não é sobre ser pessimista. É sobre ser completo.
Checklist rápido: seu fluxo está completo?
Da próxima vez que você entregar um fluxo no Figma, passe por essa lista:
- Loading: projetei o que aparece enquanto os dados carregam?
- Erro de servidor: projetei o que aparece se a API falhar?
- Offline: projetei o que aparece se o usuário perder conexão?
- Vazio: projetei o que aparece quando não há dados para mostrar?
- Validação: cada campo de formulário tem mensagem de erro específica?
- Retry: o usuário consegue tentar de novo sem recarregar a página?
Se você conseguir responder "sim" para todos, seu fluxo está profissional. Se não, você sabe exatamente o que falta.
Checagem rápida
Sem nota, sem pressão. Responda de cabeça e depois abra para conferir.
No review, um colega diz que o fluxo "está pronto" porque cobriu o caminho feliz. Quais quatro cenários você lembra que faltam?
Os quatro estados do caminho triste: a API que não respondeu (timeout), a conexão que caiu (offline), o formulário que falhou (validação ou erro de servidor) e a lista sem dados (empty state). Sem esses, o fluxo cobre só quando tudo dá certo, e uma parcela real dos usuários vai bater justamente no que ficou de fora.
Deu erro em um campo de e-mail inválido. Você usa inline error ou toast? E se a própria API cair no envio?
Para erro de validação, inline error: a mensagem aparece colada no campo com problema, dizendo o que corrigir ("O e-mail precisa ter um @"). Para erro de servidor, quando a API cai no meio do processo, toast: aquela notificação no canto avisando que a ação falhou e pedindo para tentar de novo, sem prender a mensagem a um campo específico.