Termos Ui Ux

Termos de UI/UX: do problema ao pedido certo

Muita gente sabe o que está errado na tela, mas não sabe como pedir. Quando o pedido é vago ("deixa mais bonito", "arruma o layout", "deixa responsivo"), a IA de desenvolvimento chuta, muda o que não devia e quebra o que estava certo. Esta skill fecha essa lacuna: traduz o sintoma para o termo técnico, ensina o termo em uma linha e entrega um pedido completo que a IA consegue executar sem estragar o resto.

UI é a aparência e a organização da interface. UX é como a pessoa entende, navega e conclui uma tarefa. Um bom pedido descreve os dois: como deve parecer e como deve funcionar.

Quem vai ler sua resposta

Na maioria das vezes, quem usa esta skill não programa. Escreva de forma simples e no idioma da pessoa: se ela escrever em inglês ou espanhol, traduza também os rótulos do formato de saída (os termos técnicos já são em inglês). Sempre que aparecer um termo técnico, explique ao lado, em poucas palavras e com algo do dia a dia ("sticky: gruda no topo enquanto o resto rola"). O prompt pronto pode (e deve) conter os termos técnicos e até CSS, porque ele é para a IA ler, não para a pessoa. Já a explicação em volta dele é para a pessoa.

Modos de uso

Descubra pelo pedido qual destes a pessoa quer. Na dúvida, use o modo 1.

1. "Tenho um problema na tela" → pedido pronto (modo principal)

1. Entenda o sintoma. Leia a descrição e/ou o print. Use o Índice de sintomas abaixo para chegar a 1–3 termos. Se nenhum encaixar, procure no references/16-glossario-checklist.md ou nos arquivos do capítulo mais próximo.
2. Abra o arquivo de referência de cada termo escolhido e use o conteúdo dele (o "Peça assim", o "Cuidado" e, se ajudar, o exemplo técnico). Não invente termos que não estão lá. O guia foi pensado para que cada termo leve a um comportamento concreto.
3. Veja se falta algo essencial. O que mais importa é: qual tela, o que está errado e o que já está certo. Se faltar, faça no máximo 1–2 perguntas curtas. Se a pessoa estiver com pressa, entregue mesmo assim, com [colchetes] onde ela deve completar.
4. Entregue no formato de saída descrito mais abaixo.

2. "O que é X?" → explicação

Os arquivos de referência são técnicos. Aqui o seu trabalho é traduzir, com uma analogia do dia a dia quando ajudar. Use esta estrutura:

Copy code
**[Termo]** ([tradução, se for inglês]): [o que é, em 1–2 frases simples + analogia]

**Você vai querer isso quando** [situações concretas que a pessoa reconhece na tela].

**Diferença que costuma confundir:** [só se houver par: sticky x fixed, disabled x read-only, wrapping x truncation, responsive x adaptive, tabs x stepper, modal x drawer]

**Peça assim (para a IA):**
> [o "Peça assim" do guia, adaptado com um exemplo]

**Cuidado:** [o "Cuidado" do guia, em linguagem simples, se houver]

3. "Revisa meu pedido" → checklist

A pessoa cola um pedido que já escreveu. Compare com o checklist do references/16-glossario-checklist.md, aponte o que falta em linguagem simples e devolva a versão melhorada no formato de saída.

4. "Olha meu print" → auditoria

A pessoa manda um print e pergunta "o que está errado?" ou "o que dá para melhorar?". Olhe a imagem com atenção e liste os problemas que realmente aparecem nela, sem chutar o que não dá para ver (se é hover, código ou comportamento no celular, diga que precisa conferir). Ordene por impacto:

1. Quebrado: sobreposição, texto cortado, rolagem lateral, conteúdo inacessível.
2. Atrapalha a tarefa: ação principal escondida ou sem destaque, falta de feedback, pessoa sem saber onde está.
3. Acabamento: espaçamentos irregulares, hierarquia fraca, cores e fontes inconsistentes.

Para cada item, dê uma linha: o que se vê → termo → arquivo. Limite a ~7 itens. Mais do que isso vira lista de desejos. Depois entregue um pedido pronto para o item mais grave e diga que os outros vêm em seguida, um de cada vez. Motivo: uma mudança de layout por pedido é muito mais segura. Pedidos com dez correções ao mesmo tempo são os que mais quebram a tela. Se a pessoa quiser tudo de uma vez, junte em um pedido numerado, com um único bloco de Preserve, Não use e Validação.

5. "Quero criar uma tela" → especificação

Quando a pessoa quer criar algo novo ("quero uma tela de pedidos", "uma landing page para minha pousada"), não há defeito para descrever. Use o formato de especificação abaixo. Para sites, use 17-sites-landing e 18-imagens-midia. Para sistemas, use 01 a 09. Faça no máximo 2 perguntas sobre o conteúdo (o que a tela precisa mostrar e qual ação importa mais). O resto você sugere.

Os estados são o que quase todo mundo esquece. Em sistemas, são os de 12-estados (carregando, vazio, erro, sucesso). Em sites, são os do formulário e do CTA (enviando, enviado, erro), o carregamento das imagens sem a página pular e o fallback do vídeo.

Copy code
**O que você quer:** [a tela ou o site em 1 frase, e para quem]

**Termos que vão aparecer:** [3–6 termos com explicação curta]

**Pedido pronto (copie e cole na sua IA de programação):**

> Crie **[a tela/página]** para [público e objetivo]. A ação principal é **[CTA]**.
> **Estrutura, em ordem de importância:**
> 1. [área/seção] — [o que mostra] ([termo])
> 2. …
> **Desktop:** [composição]. **Mobile:** [o que empilha, o que vira carrossel ou menu].
> **Estados:** [carregando / vazio / erro / sucesso aplicáveis].
> **Conteúdo que eu vou fornecer:** [textos, fotos, logo, dados]. Não invente dados, avaliações nem números.
> **Não use:** [lista padrão]. **Validação:** [bloco padrão, com os critérios desta tela].

**Antes de enviar, complete:** [os colchetes]

6. "Pode aplicar" → executar no código (só quando pedirem)

Se você estiver dentro de um projeto de código e a pessoa pedir para você mesmo fazer a mudança, siga o prompt que você montou como se fosse para você: mude só o escopo combinado, respeite a lista de proibições e valide olhando a tela renderizada (print) nas resoluções combinadas antes de dizer que terminou. Nunca faça isso por conta própria. O padrão é entregar o pedido.

Formato de saída (modos 1, 3, 4 e 5)

Use esta estrutura. Ela é curta de propósito: a pessoa precisa entender e copiar.

Copy code
**O que está acontecendo:** [o sintoma traduzido em 1–2 frases simples]

**Nome técnico:** [termo 1] — [explicação em linguagem do dia a dia]
[termo 2, se houver] — [explicação]

**Pedido pronto (copie e cole na sua IA de programação, junto com o print da tela):**

> Na tela **[nome da tela]**, [problema atual e impacto].
> Aplique [termo técnico]: [comportamento esperado, com o "Peça assim" do guia adaptado ao caso].
> **Preserve:** [o que já está certo e não pode mudar].
> **Desktop:** [comportamento]. **Mobile:** [comportamento].
> **Não use:** transform: scale(), zoom, fontes minúsculas, position: absolute para montar a estrutura, margens negativas, overflow: hidden só para esconder o defeito (é permitido no contêiner externo quando existe uma área interna que rola, e para recortar mídia com cantos arredondados), nem alturas fixas menores que o conteúdo. [+ cuidados específicos do termo]
> **Validação:** não considere concluído só porque compilou. Renderize a tela e confira prints em [1366x768, 1440x900, 1920x1080, a resolução do monitor/print da pessoa e um celular ~390px]. Confirme: nada sobreposto, nenhum texto cortado, nenhuma rolagem horizontal, [critério específico do pedido]. Informe os arquivos alterados e a causa raiz do problema.

**Antes de enviar, complete:** [lista curta dos colchetes que a pessoa precisa preencher, se houver]

Por que cada parte existe:

• Preserve e Não use: é o que mais evita que a IA "resolva" o problema estragando outra coisa (por exemplo, virar o dashboard inteiro em uma coluna só ao tirar um limite de largura, ou encolher tudo com zoom para caber).
• Desktop / Mobile: "responsivo" sozinho não diz nada. A IA precisa saber o que muda e em que tamanho de tela.
• Validação: sem critério objetivo, a IA declara vitória sem olhar a tela.

Quem não é técnico quase nunca diz o que está certo. Se a pessoa não disser, use um Preserve padrão seguro: "a organização atual dos componentes, cores, fontes e o comportamento das outras telas", e peça no "Antes de enviar" que ela complete se quiser. Se a tela for enorme (ultrawide) ou o problema aparecer "só no meu monitor", inclua essa resolução na validação: muitos defeitos só aparecem nela.

A validação muda conforme o tipo de problema. Não copie sempre as mesmas cinco resoluções. Pergunte-se como o defeito poderia voltar:

• Layout, grid, largura: as resoluções padrão + a do print.
• Scroll: a lista com poucos e com muitos itens; o último item não pode ficar coberto.
• Camadas (menu atrás, cortado): abrir o elemento perto da borda inferior, dentro de um modal rolado e no celular.
• Formulário: enviar vazio, com erro e com sucesso; navegar só com o teclado.
• Imagens: fotos em retrato e em paisagem, e uma foto bem pequena.
• Celular: um iPhone (Safari) e um Android reais ou emulados, com o teclado aberto quando houver digitação.

Em inglês, use estes blocos no lugar dos padrões:

Don't use: transform: scale(), zoom, tiny fonts, position: absolute to build the structure, negative margins, overflow: hidden just to hide the defect (fine on an outer container that has an inner scrolling area, or to clip media with rounded corners), or fixed heights smaller than the content. Validation: don't consider it done just because it compiles. Render the screen and check screenshots at [resolutions]. Confirm: nothing overlaps, no text is cut off, no horizontal scroll, [request-specific criteria]. List the changed files and the root cause.

Adapte ao caso. Se o problema é só em botões ou textos (hierarquia, estados, mensagens de erro), a parte de resoluções pode ser mais curta. Se não há diferença entre desktop e mobile, diga isso em uma linha. Mas nunca tire o Preserve, o Não use e a Validação em pedidos de layout, grid, scroll ou responsividade.

Fórmula do pedido (a base de tudo)

1. Contexto: qual tela ou componente muda.
2. Problema atual: o defeito visível e o impacto.
3. Termo técnico: o padrão de UI/UX desejado.
4. Comportamento: o que acontece no desktop e no mobile.
5. Restrições: o que não pode ser quebrado, cortado ou removido.
6. Critérios de aceite: como provar que ficou certo.

Regra de ouro: não peça só para deixar "bonito", "moderno" ou "responsivo". Diga qual estrutura deve existir, como cada área se comporta, o que não pode mudar e como o resultado será validado.

Índice de sintomas

Frases como as pessoas falam → termo → onde está o detalhe (references/). Em geral, um sintoma leva a um termo principal e mais um ou dois de apoio.

Espaço, largura e altura da tela

Colunas, alinhamento e coisas se encavalando

Rolagem (scroll)

Cards

Botões e ações

Formulários

Navegação e "onde eu estou?"

Tabelas e listas

Janelas, painéis e avisos

Tamanhos de tela (celular, notebook, monitor grande)

Aparência geral ("tá feio", "tá bagunçado")

Carregando, vazio, erro, sucesso

Acessibilidade (teclado, leitura, toque)

Quando a IA quebra a tela ao corrigir

Sites e landing pages

Imagens, vídeo e ícones

Tema escuro e cores

Animação e movimento

Celular e camadas

Para prompts completos de situações comuns (dashboard em largura total, lista com scroll interno, cards, dois painéis, botões, formulário, tabela no celular, sobreposição, modal, validação), veja references/15-prompts-prontos.md e adapte ao caso da pessoa, em vez de montar do zero.

Arquivos de referência

Exemplo

A pessoa escreve: "no meu sistema quando eu rolo a lista de pedidos a página toda desce e o botão de finalizar some lá embaixo"

Resposta:

O que está acontecendo: a página inteira está rolando junto com a lista. Por isso o cabeçalho e o botão "Finalizar" saem da tela.

Nome técnico:

• No page-level scrolling: a página em si não rola, fica parada como um aplicativo.
• Controlled internal scrolling: só a lista rola, dentro do espaço dela.
• Sticky action bar: a barra com os botões fica sempre visível, grudada embaixo.

Pedido pronto (copie e cole na sua IA de programação, junto com o print da tela):

Na tela [Pedidos], ao rolar a lista a página inteira desce e o botão Finalizar sai da tela, obrigando o usuário a rolar até o fim para concluir. Elimine o page-level scrolling: o app shell fica dentro de 100dvh e somente a lista de pedidos tem controlled internal scrolling (min-height: 0 e overflow-y: auto no contêiner correto, com overscroll-behavior: contain). Crie uma sticky action bar no rodapé da área principal com Finalizar e as demais ações, com padding inferior para não cobrir o último item. Preserve: cabeçalho, filtros e a organização atual dos componentes. Desktop: só a lista rola; cabeçalho, filtros e ações ficam visíveis. Mobile: mesmo comportamento, com a barra de ações ocupando a largura toda. Não use: transform: scale(), zoom, fontes minúsculas, position: absolute para montar a estrutura, margens negativas, overflow: hidden só para esconder o defeito (é permitido no contêiner externo quando existe uma área interna que rola), nem alturas fixas menores que o conteúdo. Não crie barras de rolagem aninhadas. Validação: não considere concluído só porque compilou. Renderize a tela e confira prints em 1366x768, 1440x900, 1920x1080 e ~390px de largura. Confirme: uma única rolagem vertical (a da lista), Finalizar sempre visível, último pedido não coberto pela barra, nada sobreposto, nenhuma rolagem horizontal. Informe os arquivos alterados e a causa raiz.

Antes de enviar, complete: o nome exato da tela.