Aprenda / UI/UX para quem programa

IntermediárioAula 16 de 1624 min0% da trilha

Projeto guiado: revisando uma tela ruim

Pega uma tela real de cadastro cheia de problemas e aplica, um a um, os quinze princípios anteriores da trilha.

Chegou a hora de juntar tudo. Imagine uma tela de cadastro de projeto com a seguinte descrição: um cabeçalho com gradiente roxo-azul-rosa cobrindo a tela inteira, um título com um emoji 🚀 antes do texto, um card de formulário com efeito de vidro (glassmorphism) sobre esse fundo, cinco cores diferentes espalhadas nos elementos (incluindo bordas laranja e ícones verdes sem relação nenhuma entre si), campos de input só com placeholder (sem label), nenhum feedback de erro visível além de uma borda vermelha, textos todos do mesmo tamanho e peso, elementos desalinhados entre si, e um botão final escrito apenas "Enviar".

Essa lista de problemas não é exagero — é uma combinação real de tudo que as quinze lições anteriores ensinaram a evitar. Vamos revisar um por um.

1. Hierarquia visual (lição 2)

Título, labels e texto de apoio com o mesmo tamanho e peso não dão nenhuma pista de onde começar. A correção: título maior e mais pesado, labels com peso médio, texto de apoio menor e com contraste reduzido — estabelecendo uma ordem clara de leitura.

2. Cor com propósito, não cinco cores brigando (lição 3)

Reduzir pra uma paleta de três papéis seguindo 60-30-10: uma cor neutra dominante de fundo, uma secundária pra textos de apoio e ícones, e uma única cor de destaque reservada pro botão principal — nada de laranja, verde e roxo competindo sem relação entre si.

3. Cortando o visual genérico de IA (lição 9)

O gradiente decorativo, o emoji 🚀 no título e o glassmorphism sem propósito saem. No lugar: um fundo sólido neutro, um título sem emoji (ou com um ícone SVG de verdade, se fizer sentido), e o card do formulário com uma superfície opaca de contraste real, sem depender de blur.

Antes
🚀 Novo projeto
nome do projeto
Depois
Novo projeto
Nome do projeto
ex: Site institucional

4. Labels de verdade, não só placeholder (lições 6 e 11)

Cada campo ganha um label visível e associado por htmlFor/id, além do placeholder que serve só de dica de formato. Isso resolve tanto a affordance do campo quanto o problema de o placeholder desaparecer assim que a pessoa começa a digitar.

5. Erro com mais de um canal (lição 11)

A borda vermelha sozinha vira borda vermelha + ícone + texto explicando o problema — garantindo que a informação chegue mesmo pra quem não distingue bem a cor vermelha isoladamente.

Antes
usuario@email
Depois
usuario@email
Falta o domínio do e-mail (ex: @gmail.com)

6. Alinhamento e grid de espaçamento (lição 10)

Cada campo, label e botão passa a se alinhar à mesma borda esquerda do card, e os espaçamentos internos (entre label e campo, entre campos, antes do botão) seguem uma escala de 8px em vez de valores soltos — nada fica "quase alinhado".

7. Microcopy específica no botão (lição 13)

"Enviar" vira "Criar projeto" — o texto do botão passa a dizer exatamente o que a ação faz, sem exigir que a pessoa releia o formulário inteiro pra ter certeza.

8. Estado de loading no envio (lição 8)

Ao clicar em "Criar projeto", o botão reduz opacidade e mostra um indicador de carregamento, impedindo clique duplicado enquanto a requisição não retorna — resolvendo a confusão entre "não funcionou" e "está processando".

Exercício

A mesma tela também tem dois botões com exatamente a mesma aparência visual: "Criar projeto" (ação principal) e "Cancelar" (ação secundária, que descarta o formulário). Qual princípio das lições anteriores explica por que isso é um problema, e como corrigir?

Quiz rápido

Numa revisão de tela, qual é a ordem de raciocínio mais direta pra identificar hierarquia visual quebrada?
Ao revisar uma tela com visual 'genérico de IA' (gradiente decorativo, emoji em vez de ícone, glassmorphism sem propósito), qual é o critério prático pra decidir o que trocar?