Padrões de design de estados vazios que reduzem confusão e guiam os utilizadores para o próximo passo bem-sucedido da configuração, com copy, layout e checklists aplicáveis rapidamente.
Uma tela em branco não é neutra. Cria uma pausa em que as pessoas começam a adivinhar o que fazer, se perderam um passo ou se o produto funciona. Durante a configuração, essa pausa é cara. Transforma “estou a começar” em “volto mais tarde”.
Um estado vazio é o que o utilizador vê quando ainda não há nada para mostrar porque não criou, importou ou ligou nada. Não é uma tela de loading, uma mensagem de erro ou um aviso de permissões. É o momento imediatamente antes do valor, quando a app precisa de ajudar o utilizador a chegar ao primeiro resultado significativo.
Um bom estado vazio tem um objetivo: levar o utilizador à próxima ação bem-sucedida com o mínimo de pensamento possível. “Bem-sucedida” é importante. O próximo passo deve produzir um resultado real (um primeiro projeto, uma fonte de dados ligada, um primeiro item criado), não um formulário sem saída ou um tour vago.
Esses momentos surgem mais vezes do que as equipas esperam: primeiro login após o registo, um workspace novo, uma tab de funcionalidade sem itens ainda (projetos, clientes, ficheiros) ou um caminho de configuração em que a importação foi ignorada e nada existe.
Quando um estado vazio cumpre a sua função, responde a três perguntas rapidamente:
Exemplo: na Koder.ai, um novo utilizador pode abrir um workspace limpo e não ver apps ainda. Um bom estado vazio diz claramente que nada foi criado, oferece uma ação óbvia como “Crie a sua primeira app” e adiciona uma pequena nota de segurança (por exemplo, que a exportação do código-fonte e snapshots existem depois de começarem). O objetivo é transformar “nada aqui” em “consigo chegar a um primeiro resultado funcional”.
Para um utilizador pela primeira vez, uma tela vazia pode dar a sensação de que a app travou ou de que fizeram algo errado. A mente preenche o espaço rapidamente, normalmente a seu desfavor.
A maioria das pessoas faz silenciosamente as mesmas perguntas:
As emoções por trás dessas perguntas ditam o comportamento. A incerteza faz as pessoas hesitarem. O medo de errar leva-as a evitar o botão primário. A impaciência leva-as a fechar a app se um próximo passo claro não aparecer em poucos segundos.
Estados vazios para novos utilizadores e para utilizadores avançados resolvem problemas diferentes. Novos utilizadores precisam de contexto e segurança porque ainda não conhecem o seu vocabulário. Utilizadores de retorno querem velocidade: uma forma rápida de criar outro item, importar dados ou repetir uma ação familiar.
Estados vazios de configuração também diferem de estados de erro e de loading. Loading diz “espere, algo está a acontecer.” Erro diz “algo falhou, aqui está o motivo.” Configuração diz “aqui não há nada ainda, e isso é normal. Aqui está como começar.”
Um exemplo concreto: se alguém abre um workspace novo na Koder.ai e vê uma página Projects vazia, não estão a pensar nas funcionalidades. Estão a pensar: “Começo com um prompt, importo código ou escolho um template, e isso vai quebrar alguma coisa?” O seu estado vazio deve responder isso sem os enviar para a documentação.
Um bom estado vazio não parece vazio. Age como uma sinalização: “Isto é isto, e aqui está o próximo clique.”
Uma estrutura que funciona na maioria dos fluxos de configuração tem três partes:
Mantenha a explicação curta. Se precisar de um parágrafo para explicar a tela, está a pedir que os utilizadores pensem demais. Mire 1 a 2 frases curtas com palavras simples como “Adicione o seu primeiro projeto” ou “Crie o seu primeiro workspace.”
Depois torne o próximo passo óbvio com um único botão primário. Se mostrar três botões iguais, está a pedir que o utilizador escolha um caminho antes de entender a página. Se tiver de oferecer alternativas (importar, template, saltar), mantenha-as visualmente mais discretas que a ação principal.
Use a linha de tranquilização para remover medos comuns: cometer um erro, perder tempo ou precisar de habilidades técnicas. Pequenas indicações sobre o que acontece a seguir e o que pode ser desfeito ajudam mais do que explicações longas.
Exemplo de copy para um ecrã Projects para primeiro uso:
Título: Comece o seu primeiro projeto
Explicação: Os projetos guardam a configuração da sua app e as releases.
Ação primária: Criar projeto
Tranquilização: Leva cerca de 2 minutos. Pode renomeá-lo a qualquer momento.
Se o seu produto suporta múltiplas formas de começar (build from chat, importar ou template, como ferramentas tipo Koder.ai), mantenha “Criar” como predefinição e coloque “Importar” e “Usar um template” como ações secundárias abaixo.
Estados vazios falham quando a copy fala de funcionalidades em vez do que o utilizador ganha. As suas palavras devem responder rápido: O que é esta tela? Porque devo fazer alguma coisa aqui? O que faço a seguir?
Uma fórmula simples para títulos é Resultado + objeto. Nomeie o resultado e aquilo que vão criar, não o nome interno da funcionalidade.
Para o corpo do texto, use o que é + porque importa em uma ou duas frases:
"Clientes são as pessoas a quem vende. Adicione um agora para poder enviar uma fatura e acompanhar pagamentos."
Os CTAs devem começar com um verbo claro e incluir um substantivo específico. Evite botões vagos como “Começar” quando há múltiplos caminhos.
Adicione microcopy ao lado da escolha que pareça mais arriscada. Pequenas tranquilizações frequentemente fazem mais do que explicações longas:
Se o seu produto gera output para o utilizador (como a Koder.ai), defina expectativas para que as pessoas saibam que não estão a comprometer uma versão final: “Vamos criar um primeiro rascunho. Pode rever e editar antes de fazer deploy.”
Um bom estado vazio deve ler-se como uma sinalização, não um cartaz. O layout precisa de uma ordem clara para que as pessoas consigam perceber de relance e agir.
Use uma hierarquia simples que corresponda ao modo como os olhos vasculham uma página: título, uma frase curta, um CTA primário, depois uma ação secundária mais discreta (importar, template, saltar).
Mantenha o botão primário próximo da mensagem. Se o utilizador tiver de ler, fazer scroll e depois decidir, muitas vezes desiste. Um padrão comum é um bloco compacto (título + corpo + CTA), com mais espaço em branco entre esse bloco e o resto (navegação, rodapé, painéis laterais).
Ícones e pequenas ilustrações podem ajudar a fazer scanning, mas só se acrescentarem significado. Um ícone de pasta junto a “Sem projetos” é útil. Uma mascote aleatória normalmente não é. Se usar uma ilustração, mantenha-a pequena e coloque-a acima do título para que não compita com o CTA.
Um dos padrões mais fortes é mostrar uma pequena pré-visualização do sucesso: uma carta de exemplo, uma linha demo numa tabela ou um tile de exemplo esbatido. Numa ferramenta como a Koder.ai, o ecrã vazio “Apps” poderia mostrar um tile de app de exemplo (nome, estado, última atualização) para que os utilizadores percebam imediatamente o que vão criar.
Quando alguém entra num ecrã vazio, normalmente quer uma de três coisas: começar do zero, trazer dados ou avançar rápido com um starter. Bons estados vazios tornam esses caminhos claros sem forçar o utilizador a estudar o produto.
Lidere com “Criar” quando a primeira vitória real é fazer algo novo: um projeto, workspace, página ou o primeiro registo. Funciona melhor quando o utilizador pode terminar rapidamente e a ação é reversível.
Se a criação demorar mais, divida-a num primeiro passo menor (por exemplo, “Criar um rascunho”) para que possam avançar sem sentir-se bloqueados.
Lidere com “Importar” quando a maioria dos novos utilizadores chega com um sistema, ficheiro ou conta para ligar. O estado vazio deve indicar o que a importação suporta e o que obtêm depois (por exemplo, campos mapeados e itens criados).
Uma forma prática de escolher o CTA principal é usar o contexto. Se o utilizador veio de conteúdo de migração, destaque Importar. Se clicou num botão “novo projeto” vazio, destaque Criar. Se a configuração for complexa, destaque Template.
Lidere com templates quando o seu produto tem pontos de partida comuns e os utilizadores querem adaptar, não desenhar. Nomeie templates por resultado (“Pipeline de vendas”, “Planeador semanal”), não por funcionalidades.
Uma opção segura “Experimentar com dados de exemplo” reduz o medo. Deixe claro que pode ser eliminada. Para um construtor orientado por chat como a Koder.ai, um projeto de exemplo pode mostrar a forma de uma app funcional antes de o utilizador escrever o seu próprio prompt.
Estados vazios não são neutros. Os melhores tornam a próxima ação bem-sucedida óbvia, segura e rápida.
Exemplo: se alguém abre um CRM novo e vê a tab “Contacts” vazia, a vitória mais rápida é “Adicione o seu primeiro contacto.” Mantenha só nome + email, ofereça “Importar CSV” como alternativa e tranquilize que podem atualizar os campos depois.
A maioria dos estados vazios que deixam os utilizadores presos falham por uma razão: tornam o próximo passo arriscado ou pouco claro.
Se mostrar três botões que parecem igualmente importantes, os utilizadores hesitam. Escolha uma ação primária e uma secundária. Ponha todo o resto atrás de uma discreta linha “Mais opções”.
“Dashboards poderosos, roles flexíveis, settings avançados” não diz às pessoas o que fazer agora. Substitua por qual será a próxima vitória após o clique.
Exemplos:
Formulários longos num estado vazio parecem um compromisso. Se precisa de detalhes, ganhe-os depois. Comece pelo menor passo que produza algo visível.
Em vez de pedir nome, tamanho da empresa, cargo e objetivos antes de qualquer coisa carregar, peça apenas “Nome do projeto” e torne o resto opcional depois do primeiro ecrã existir.
Humor é aceitável, mas não onde o utilizador precisa de clareza. “Nada para ver aqui” desperdiça o momento. Diga exatamente o que acontecerá depois do clique e o que não acontecerá.
Alguns utilizadores não conseguem criar do zero. Ofereça um caminho de backup real: importar, começar por um template ou experimentar com dados de exemplo. Por exemplo, se alguém usa a Koder.ai e não tem uma ideia pronta, “Começar com uma app de exemplo” pode levá-los a um ecrã funcional sem escrever uma especificação completa.
Um novo utilizador deve entender o que é o ecrã, porque importa e o que fazer a seguir em cerca de cinco segundos.
A tranquilização é o que transforma hesitação em ação. Adicione uma pequena linha junto ao CTA que reduza o medo, como “Pode alterar isto depois” ou “Nada é publicado até confirmar.” Mantenha-a calma e específica.
Um teste simples: peça a um colega para olhar o ecrã por cinco segundos e depois explicar o que acha que vai acontecer se clicar no botão principal. Se não souberem responder, ajuste a copy ou a hierarquia.
Se estiver a construir fluxos de configuração num construtor orientado por chat como a Koder.ai, a mesma checklist aplica-se. O estado vazio deve convidar para uma ação bem-sucedida: começar por um template, importar dados ou gerar uma primeira versão funcional que possa editar com segurança.
Um fundador a solo regista-se na Koder.ai e abre um workspace novo. Cai numa página Projects com zero apps e sem ideia do que é “bom”.
Em vez de uma tabela vazia, o estado vazio mostra uma promessa curta, um próximo passo claro e uma pequena nota de segurança. Aqui está um exemplo da copy e do CTA (considere as estimativas de tempo como placeholders a validar):
Your workspace is empty.
Create your first app in 5 minutes. Start with a template or describe what you want in plain English.
[Create your first app]
Secondary: Import existing code | Browse templates
Note: You can export the source code anytime.
Depois do fundador clicar Create your first app, o ecrã seguinte pergunta uma única questão simples: “What are you building?” com um único campo e 2 prompts de exemplo (como “CRM for a small agency” ou “Landing page with signup”). Mantenha o caminho estreito: um campo óbvio, um botão óbvio.
O ecrã dois pode ser uma revisão rápida do plano (funcionalidades, páginas, dados), seguido por um passo de build e uma preview funcional. O primeiro momento de sucesso é quando o utilizador consegue fazer uma ação real nessa preview, como adicionar um registo ou submeter um teste de inscrição.
Quando existir dados, os utilizadores que regressam não devem ver o mesmo estado vazio. A tela Projects pode mudar para uma vista de “apps recentes” com uma ação rápida proeminente (por exemplo, New app) e ações menores (como Snapshots ou Deploy) com base no que fizeram da última vez.
Para saber se o seu estado vazio está a funcionar, acompanhe alguns números:
Escolha um fluxo de configuração para melhorar esta semana. Escolha aquele com maior desistência ou o que os novos utilizadores veem primeiro. Reescreva o seu estado vazio para responder rápido a três perguntas: O que é isto? Porque devo fazer isto agora? Qual é o próximo clique?
Mantenha a alteração pequena. Não está a redesenhar o onboarding. Está a tornar a primeira ação bem-sucedida óbvia.
Um plano simples de uma semana:
Depois de obter uma vitória, padronize. Crie um pequeno padrão interno para estados vazios: espaçamento, estilo de título, regras para ícones ou ilustrações e um layout consistente de CTAs. Quando as equipas seguem a mesma estrutura, os utilizadores aprendem uma vez e avançam mais rápido em todos os lados.
Se estiver a construir uma app nova e quiser prototipar passos de configuração rapidamente, a Koder.ai (koder.ai) pode ajudar a rascunhar um fluxo no Planning Mode e gerar a primeira versão para testar, depois iterar com base nos pontos onde as pessoas realmente hesitam.
Um estado vazio é aquilo que os utilizadores veem quando ainda não há nada para mostrar porque não criaram, importaram ou ligaram nada. Deve explicar para que serve o ecrã e apontar para a próxima ação bem-sucedida, em vez de deixar os utilizadores adivinharem.
Um ecrã de loading diz “aguarde, algo está a acontecer”, e um estado de erro diz “algo falhou, aqui está o motivo”. Um estado vazio de configuração diz “aqui não há nada ainda, e isso é normal” e depois orienta o utilizador a criar, importar ou começar por um template para atingir um primeiro resultado real.
Procure responder três coisas rapidamente: o que é este ecrã, por que está vazio e o que fazer a seguir. Se os utilizadores não conseguirem perceber isso em poucos segundos, é mais provável que hesitem, pensem que fizeram algo errado ou saiam.
Use uma estrutura simples: uma explicação curta do que a área serve, uma ação principal óbvia e uma linha de segurança que reduza o medo ou esforço. Mantenha o texto conciso para que os utilizadores não tenham de ler um parágrafo para saber onde clicar.
Adote um botão primário que corresponda ao próximo passo mais comum e torne todo o resto claramente secundário. Se mostrar múltiplos botões com o mesmo peso, as pessoas tendem a congelar porque não sabem qual caminho é o “certo”.
Lidere com “Criar” quando começar do zero for a forma mais rápida de obter uma vitória visível (por exemplo, um primeiro projeto ou registo). Lidere com “Importar” quando a maioria dos utilizadores já trouxer dados de outro lugar. Lidere com “Template” quando os utilizadores quiserem rapidez e um ponto de partida comprovado.
Escreva títulos como resultado + objeto, por exemplo “Crie o seu primeiro projeto”, em vez de etiquetas de funcionalidade como “Projetos”. No texto do corpo, adicione uma frase que explique o que acontece depois do clique para que o utilizador possa prever o resultado.
Coloque o título, uma frase curta e o botão primário num bloco compacto com hierarquia visual clara. Mantenha as ações secundárias mais discretas e próximas, e evite empurrar o botão principal para baixo da página onde o utilizador tem de fazer scroll ou procurar.
Adicione uma nota curta de segurança junto à ação, como “Pode alterar isto mais tarde” ou “Nada é publicado até confirmar”. Em ferramentas como Koder.ai, também ajuda mencionar ações reversíveis como snapshots/rollback ou a possibilidade de exportar o código-fonte depois de começarem a construir.
Meça com que frequência os utilizadores veem o ecrã vazio, clicam no CTA primário e completam o marco que ele pretende impulsionar. Observe também o tempo até à primeira vitória e a taxa de desistência entre o estado vazio e o passo seguinte, porque um estado vazio pode ter cliques mas ainda falhar ao gerar resultados.