Tela bonita do Dribbble não é especificação: os estados que o shot não mostra

O painel de agendamentos da clínica veterinária ficou idêntico ao shot que o cliente mandou: cards arredondados, avatar do pet, horário em destaque. Na primeira semana, a recepcionista cadastra "Maria Aparecida dos Santos Albuquerque" como tutora, e o nome atravessa o card e cobre o botão de confirmar. Num dia sem agendamentos, a tela fica branca, e ela liga achando que o sistema caiu. O shot mostra um único estado, o feliz. O produto vive em todos os outros.

A resposta curta: use a referência para tom visual, não como especificação. Antes de implementar, liste para cada tela os estados que ela pode ter (carregando, vazio, erro, parcial, texto longo, sem permissão) e defina como cada um aparece. Depois teste com teclado, com contraste medido e com dados feios de propósito.

Por que o shot engana

Um shot de portfólio é feito para impressionar em poucos segundos numa vitrine. O dado é escolhido a dedo: nomes curtos, números redondos, três itens que cabem perfeitamente. Não há mensagem de erro porque nada falha numa imagem estática. Não há foco de teclado porque ninguém navega por um PNG. O contraste suave fica elegante na tela calibrada do designer.

Nada disso é defeito do shot. Ele cumpre o papel dele. O problema começa quando a equipe trata a imagem como a especificação completa e implementa exatamente o que está nela. O resultado é uma tela que só existe na condição da foto. E copiar o padrão visual de um aplicativo de outra área, como um app de banco para um blog, também traz decisões de interação que não fazem sentido para o seu caso.

Como transformar a referência em especificação

1. Separe o que é tom do que é fluxo. Da referência, leve paleta, tipografia, espaçamento e densidade. O fluxo vem do seu problema.
2. Liste os estados de cada tela numa matriz simples e desenhe, nem que seja em rascunho, cada um deles.
3. Escreva os textos de verdade: mensagem de erro, instrução do vazio, rótulo do botão. Texto de mentira esconde problema de espaço.
4. Defina foco e contraste antes de implementar, não como ajuste no fim.
5. Monte um conjunto de dados feios para testar: nomes longos, zero itens, cem itens, valores grandes.
6. Teste só com teclado e com zoom de 200% antes de chamar a tela de pronta.

A matriz de estados do painel de agendamentos

No caso da clínica, a especificação que faltava cabia numa lista:

• Carregando: esqueleto dos cards na mesma altura dos reais, para a tela não pular. Se passar de alguns segundos, uma frase diz que ainda está buscando.
• Vazio, primeiro uso: "Nenhum agendamento ainda. Cadastre o primeiro pelo botão Novo agendamento." Com o botão ali.
• Vazio, dia sem horários: "Nenhum agendamento para 14/10. Veja os próximos dias." É diferente do primeiro uso e precisa de outra instrução.
• Erro ao carregar: mensagem que diz o que aconteceu e um botão de tentar de novo, sem apagar o que já estava na tela.
• Parcial: a lista carregou, mas as fotos dos pets não. O card funciona sem a foto, com as iniciais.
• Texto longo: nome de tutor e de pet quebram linha em vez de vazar; o botão nunca fica coberto.
• Sem permissão: o veterinário vê os próprios horários; a tela diz isso em vez de mostrar uma lista suspeitamente curta.
• Ação em andamento: ao confirmar, o botão indica que está processando e não aceita segundo clique.

O vazio, em especial, é a primeira tela que todo cliente novo vê. O post sobre lista vazia como instrução mostra como escrever esse texto para que ele leve à próxima ação.

O CSS que o shot não precisava

Três regras resolvem boa parte dos problemas de texto longo e foco:

/* foco visível para quem navega por teclado */
:focus-visible {
  outline: 3px solid #1d4ed8;
  outline-offset: 2px;
}

/* nomes longos quebram em vez de vazar do card */
.card-agendamento .tutor,
.card-agendamento .pet {
  overflow-wrap: anywhere;
}

/* em linhas flex, permite que o texto encolha e o botão continue visível */
.card-agendamento .info {
  flex: 1 1 auto;
  min-width: 0;
}
.card-agendamento .acoes {
  flex: 0 0 auto;
}

O min-width: 0 é o detalhe que mais gente esquece: por padrão, um item flex não encolhe abaixo da largura do seu conteúdo, e é por isso que o nome longo empurra o botão para fora. Nunca remova o contorno de foco sem colocar outro no lugar; o outline: none copiado de um CSS de vitrine deixa quem usa teclado sem saber onde está.

Contraste com número, não com impressão

O cinza-claro sobre branco do shot raramente passa nas diretrizes de acessibilidade. O WCAG pede, no nível AA, contraste de pelo menos 4,5:1 para texto normal e 3:1 para texto grande e para os contornos de componentes de interface, como bordas de campo e ícones que carregam informação. Meça com o verificador de contraste das ferramentas de desenvolvedor do navegador. Se a cor da marca não passa, escureça o tom no texto e mantenha a cor original em áreas decorativas.

Ícone sozinho também não é rótulo. O botão de confirmar com um "check" bonito precisa de texto, visível ou ao menos acessível; o post sobre emoji não substituir o nome do botão trata disso. E se a tela vem de um kit de componentes pronto, lembre que o preview do componente não prova acessibilidade.

O teste com dado feio

Tenha um conjunto de dados de teste feito para quebrar a tela, e rode a tela com ele antes de cada entrega visual:

• um nome de 60 caracteres sem espaços e outro com acentos;
• zero itens, um item e duzentos itens;
• um valor monetário com sete dígitos;
• uma imagem que não carrega;
• a rede lenta, simulada no navegador;
• zoom de 200% e tela de celular estreita.

Depois, desconecte o mouse e percorra a tela com Tab, Shift+Tab, Enter e Espaço. A ordem do foco deve seguir a ordem visual, e todo botão precisa ser alcançável e acionável.

Erros comuns

• Implementar só o estado do shot: a primeira lista vazia ou o primeiro erro de rede viram uma tela branca, e o cliente acha que o sistema caiu.
• Usar texto de mentira no protótipo: nomes curtos escondem o problema de espaço que aparece no primeiro cadastro real.
• Remover o contorno de foco: quem navega por teclado perde a posição, e a tela fica inutilizável para essa pessoa.
• Aprovar contraste no olho: o cinza elegante falha em tela comum, sob sol, e para quem enxerga menos.
• Tratar todo vazio igual: "sem resultados" no primeiro uso não diz ao cliente o que fazer.
• Copiar padrão de outra categoria de app: interações pensadas para outro contexto confundem o seu público.

Checklist

• Cada tela tem a lista de estados: carregando, vazio, erro, parcial, texto longo, sem permissão.
• Cada estado tem texto final escrito, não placeholder.
• Nomes longos quebram linha e nenhum botão fica coberto.
• O foco é visível em todos os elementos interativos.
• O contraste de texto foi medido e atinge 4,5:1 (ou 3:1 em texto grande).
• A tela foi usada só com teclado, do começo ao fim.
• A tela foi vista com zoom de 200% e em largura de celular.

Pegue agora a tela mais bonita do seu sistema e desligue a internet antes de recarregar. Onde aparece a mensagem de erro, e o que ela diz para a pessoa fazer?