Módulo 06 — UX e interface

---

1. UX não é o mesmo que "deixar bonito" 🔄

Três termos que se confundem e não são a mesma coisa:

• UX (experiência do usuário): como a pessoa se sente usando o sistema, do primeiro contato até sair com a tarefa feita. Inclui achar o que procura, entender o que aconteceu, não travar no meio.
• UI (interface do usuário): a camada visível. Botões, cores, tipografia, layout. UI é parte da UX, não o todo.
• Usabilidade: o quão fácil e eficiente é usar. É o pedaço medível da UX.

Uma tela linda que confunde tem boa UI e péssima UX. Uma tela feia em que tudo funciona no primeiro clique tem UI fraca e UX razoável. Na prova, a meta é ter as duas, mas se um dia for preciso escolher, clareza ganha de beleza.

A usabilidade tem uma definição clássica de cinco componentes (Nielsen), e vale conhecer porque cada um vira uma pergunta concreta sobre o Wedding Pass:

Repara que as coisas boas que o módulo 05 construiu no código caem cada uma numa casinha dessa tabela. Isso não é coincidência: é o que esse módulo faz. Ele pega o que vocês já fazem por instinto e dá nome, critério e método.

---

2. As dez heurísticas de Nielsen, uma a uma no Wedding Pass 🆕

Heurísticas são regras práticas pra julgar se uma interface é boa. As dez de Jakob Nielsen (1994) são o padrão da indústria até hoje: aparecem em vaga de emprego, em curso, em auditoria de UX profissional e, com outras palavras, nos critérios de julgamento da banca.

Na Regional, a intuição de vocês bastava. Agora não basta mais: as dez entram com nome e endereço. Por três motivos:

1. Elas viram roteiro de auto-teste: uma passada pelas dez no fim do Módulo C acha problema de graça (o 🛠️ no fim desta seção).
2. Na apresentação individual (módulo D), citar a heurística pelo nome ao explicar uma decisão é um porquê pronto, e porquê é o que a banca quer ouvir.
3. Os descritores de julgamento de UX são, na prática, as heurísticas reescritas. Quem conhece a régua joga o jogo da régua.

2.1 Visibilidade do estado do sistema (Visibility of system status)

O sistema sempre diz o que está acontecendo. O usuário nunca fica olhando pra tela sem saber se clicou, se está processando, se deu certo.

No Wedding Pass isso já tem forma concreta: os quatro estados de tela do 05 §5.5 (carregando, vazio, erro, sucesso) são exatamente essa heurística em código. O spinner no botão enquanto a API responde, o toast do avisar(), o painel gigante do check-in: tudo visibilidade de estado.

O dashboard com setInterval de 15 segundos (05 §7.2) é a versão ambiciosa: o estado do salão quase em tempo real, sem a Olívia apertar F5.

E tem um nível acima da tela: o alerta de 90% da capacidade (04 §11.1) é visibilidade de estado no nível do negócio. Não é só a tela dizendo o que ela está fazendo, é o sistema avisando do problema antes de o problema acontecer. Quando forem explicar esse alerta na apresentação, o nome disso é heurística 1.

2.2 Correspondência entre o sistema e o mundo real (Match between system and the real world)

O sistema fala a língua de quem usa, não a língua de quem programou.

• Vocabulário do domínio: convidado, mesa, convite, check-in, acompanhantes. Nunca "registro", "entidade", "item".
• Datas no formato brasileiro: 12/10/2026, não 2026-10-12 (o banco guarda ISO, a tela traduz).
• O ENUM 'pendente' do banco vira o badge "Pendente" na tela. A tela sempre traduz o banco, nunca o expõe.

2.3 Controle e liberdade do usuário (User control and freedom)

Sempre tem saída. A pessoa entrou onde não queria? Volta. Abriu um modal sem querer? Fecha. Começou uma ação? Cancela.

• Todo formulário tem Cancelar, e cancelar não guarda lixo pela metade.
• Modal fecha com Esc e com clique fora. Duas linhas de JS, sensação de controle total.
• Ação destrutiva pede confirmação com o nome do que vai morrer: "Excluir Maria Silva?", não um "Tem certeza?" genérico. O módulo 08 transforma isso num componente pronto.

Desfazer de verdade (o Ctrl+Z de sistema) é caro de implementar e a prova não pede. A confirmação bem feita é o substituto barato: em vez de deixar desfazer, impede de fazer sem querer.

2.4 Consistência e padrões (Consistency and standards)

O mesmo tipo de coisa se comporta do mesmo jeito em todo lugar. Botão de ação principal sempre da mesma cor. "Cancelar" sempre à esquerda de "confirmar". Mensagem de erro sempre no mesmo lugar. Consistência reduz carga mental: aprendeu uma tela, entende todas.

Existem duas consistências:

• Interna: dentro do seu sistema. É a que vocês controlam 100%.
• Externa: com o que o mundo já faz. X fecha, lupa busca, lixeira apaga, link é azul ou sublinhado. Inventar convenção nova é gastar a paciência do usuário à toa.

Os tokens do 05 §3.4 são a arma secreta aqui: quando só existe --cor-acao, não tem como o botão de salvar sair de outra cor. A consistência deixa de ser esforço e vira consequência. É por isso que os tokens se decidem no dia de UX (§8) e se codam no primeiro dia de CSS.

2.5 Prevenção de erros (Error prevention)

Melhor que uma boa mensagem de erro é o erro que nem consegue acontecer.

No Wedding Pass, em ordem de esforço:

• required, type="email", maxlength, min/max no HTML: validação de graça, sem uma linha de JS (05 §10).
• Select de mesa em vez de campo de texto livre: não existe "digitou mesa errada", só existem as mesas que existem.
• Acompanhantes até 5 em três camadas: max="5" no HTML, validação na API, CHECK no banco (03 §7). A primeira camada é UX (impede o erro), as outras duas são segurança (garantem mesmo se a primeira falhar).

2.6 Reconhecimento em vez de memorização (Recognition rather than recall)

O usuário não deveria precisar decorar nada. As opções estão à vista, os campos têm rótulo claro, os ícones vêm com texto.

• O select de mesa mostra "Mesa 3 (2/8 lugares)": a informação necessária pra decisão está dentro da própria opção. A Olívia não precisa decorar a ocupação de cada mesa nem abrir outra tela pra conferir.
• Placeholder com exemplo real do formato: ABC12345 no campo de código. Ninguém precisa lembrar se o código tem 6 ou 8 caracteres.
• Badge de status com cor E texto: "Confirmado" em verde. Cor sozinha obriga a decorar o código de cores (e exclui quem não distingue cor, §9).

2.7 Flexibilidade e eficiência de uso (Flexibility and efficiency of use)

Aceleradores pra quem já sabe usar, sem atrapalhar quem está aprendendo.

• Autofocus no campo de código (05 §7.3): a tela de check-in abre pronta pra digitar.
• Enter submete o formulário (comportamento nativo do <form>, é só não quebrar).
• Depois de cada check-in, o foco volta pro campo, limpo. Próximo da fila.

Resultado: check-in completo em duas ações (digitar/colar o código + Enter). A Renata do §3 é a persona inteira dessa heurística: ela usa o sistema 200 vezes na mesma noite, cada clique economizado vale 200 cliques.

2.8 Estética e design minimalista (Aesthetic and minimalist design)

Cada elemento na tela compete por atenção com todos os outros. Informação irrelevante não é neutra: ela dilui a relevante.

• Dashboard: 3 ou 4 números grandes, não 20 métricas espremidas. Confirmados, pendentes, presentes, capacidade. O resto é detalhe que mora em outra tela.
• Tela de check-in quase vazia: um campo, um resultado gigante. É a tela mais importante do sistema justamente porque não tem nada além do essencial.

2.9 Ajudar o usuário a reconhecer, diagnosticar e se recuperar de erros (Help users recognize, diagnose, and recover from errors)

Quando o erro acontece, a mensagem diz o que houve e como resolver, na língua do domínio (§2.2).

A anatomia da mensagem boa: o que aconteceu + o próximo passo. Compara:

• "Erro" → não diz nada.
• "O e-mail precisa ter @" → diz o que consertar.
• "Esse convidado já fez check-in às 19h32" → diz o que houve, com o detalhe (o horário) que transforma a mensagem em informação de trabalho: a Renata sabe na hora que é entrada duplicada e pode agir.

Essa última é o 409 da corrida de check-in (04 §11.2) chegando na tela pelo painel vermelho do 05 §6. Banco, API e front alinhados numa frase.

2.10 Ajuda e documentação (Help and documentation)

A melhor interface não precisa de manual. Quando precisar de alguma ajuda, ela aparece no contexto, na hora da dúvida, não numa página separada.

Na prova, ajuda é microtexto:

• Placeholder que ensina o formato: ABC12345.
• Texto de apoio embaixo do campo: "Até 5 acompanhantes por convidado".
• Empty state que ensina o primeiro passo: "Nenhum convidado ainda. Clica em Novo convidado pra cadastrar o primeiro." A lista vazia deixa de ser beco sem saída e vira convite.

As dez numa tabela (o roteiro de auto-teste)

---

3. Personas e mapa de empatia enxutos 🆕

Persona é uma pessoa concreta, inventada, que representa um perfil real de uso. Não é enfeite de slide: é ferramenta de decisão. Quando duas soluções de tela empatam, a persona desempata: qual das duas ajuda mais essa pessoa, nesse momento, com essa pressa?

O Wedding Pass tem três perfis com login (o ENUM do banco: admin, organizador, recepcao) e um ator sem login (o convidado que responde o RSVP, módulo 07). Quatro personas, um mapa de empatia enxuto pra cada:

Renata, da recepção (perfil recepcao)

• Vê: fila de convidados na porta, tablet na mão, música alta, luz baixa.
• Sente: pressão. Cada segundo olhando pra tela é um casal parado na fila.
• Precisa: confirmar um código em segundos e saber na hora, sem ler nada pequeno, se a pessoa entra ou não.
• Dor nº 1: tela que faz pensar. Campo fora de foco, resultado discreto, mensagem ambígua.

Olívia, a organizadora (perfil organizador)

• Vê: a lista de convidados mudando toda semana, RSVPs pingando, mapa de mesas pra fechar.
• Sente: a responsabilidade de a conta fechar: confirmados dentro da capacidade, ninguém sem mesa.
• Precisa: cadastrar e editar rápido, acompanhar quem confirmou, enxergar a capacidade de longe.
• Dor nº 1: descobrir tarde que estourou a capacidade. O alerta de 90% (04 §11.1) existe pra ela.

Ada, a admin (perfil admin)

• Vê: o sistema inteiro: usuários, perfis, casamentos.
• Sente: que a chave é dela. Se alguém tem acesso a mais, o problema é dela.
• Precisa: gerenciar usuários e perfis sem risco de dar poder errado pra alguém.
• Dor nº 1: recepção com acesso de admin. É por isso que "o front esconde e o back barra" (04 §9): a Ada dorme em paz porque o back barra.

Caio, o convidado (sem login)

• Vê: um link no e-mail, aberto no celular, no meio do expediente.
• Sente: zero paciência. Se pedir cadastro ou senha, ele fecha e "responde depois" (nunca).
• Precisa: responder "vou / não vou" em menos de um minuto, no celular, de pé.
• Dor nº 1: atrito. Página pesada, formulário comprido, botão pequeno. A página pública de RSVP (módulo 07) é desenhada inteira pra ele.

O mapa de empatia completo da literatura tem mais quadrantes (o que a pessoa fala, faz, ouve). Na prova, esses quatro campos (Vê / Sente / Precisa / Dor nº 1) carregam todo o valor e cabem num canto de folha.

---

4. Arquitetura da informação: organizar pra achar 🔄

Arquitetura da informação (AI) é como o conteúdo e a navegação se organizam: o usuário entende onde as coisas estão e como chegar nelas sem pensar.

Os três princípios da Regional continuam valendo:

• Agrupar o que é parecido: tudo de convidados num lugar, tudo de visão geral em outro.
• Menu claro: os nomes dizem pra onde levam. "Convidados", "Check-in", "Dashboard". Nunca "Módulo 1", "Área 2".
• Caminho curto: o que é usado o tempo todo fica a um clique, não escondido em três menus.

O aprofundamento é transformar "caminho curto" em regra que se verifica: a tarefa nº 1 de cada perfil sai em no máximo 2 ações a partir do login.

Repara que o redirect por perfil (05 §7.1) e o menu por perfil (05 §8) são exatamente isso: arquitetura da informação aplicada. Cada perfil enxerga um mapa do tamanho do trabalho dele, e o sistema já abre no lugar certo. Não foi capricho de código, foi decisão de AI.

Ferramenta prática: o inventário de telas. Antes de desenhar qualquer coisa, listar as telas que o sistema tem (login, convidados + formulário, check-in, dashboard, e a página pública de RSVP quando o módulo 07 chegar) e, pra cada uma: quem usa, qual a tarefa principal, de onde se chega, pra onde se vai. Meia página que vira o esqueleto do wireflow do §5.

---

5. Wireframe e protótipo rápido: a segunda 31/08 🆕

Wireframe é o rascunho estrutural da tela. Ele existe pra decidir layout e fluxo antes de gastar tempo codando, e pra errar barato: apagar um retângulo de caneta custa 5 segundos, refazer uma tela em CSS custa 40 minutos.

O que o wireframe TEM:

• Caixas representando os blocos (cabeçalho, busca, tabela, formulário).
• Hierarquia: o que é grande, o que vem primeiro, o que se destaca.
• Texto realista: "Mesa 3 (2/8 lugares)", não "lorem ipsum" nem rabisco. Texto de verdade denuncia problema de espaço e de clareza que o rabisco esconde.
• Anotações nas margens ("esse campo abre focado", "esse painel fica gigante").

O que o wireframe NÃO tem: cor, fonte, ícone caprichado, sombra. Se tem cor, virou desenho artístico e perdeu a função: a discussão vira "que verde bonito" em vez de "por que a busca está embaixo?".

Fidelidade: baixa (papel e caneta) contra alta (Figma e afins). Na prova, papel, sempre. Três motivos: é mais rápido, não tenta enfeitar, e o rascunho não é entregável, é ferramenta de pensar. Ninguém pontua o wireframe; pontua-se a tela que saiu certa de primeira por causa dele.

As quatro telas do Wedding Pass, conteúdo mínimo de cada

• Login: nome do sistema, campo de e-mail, campo de senha, botão entrar, espaço reservado pra mensagem de erro (o espaço já nasce no wireframe pra tela não "pular" quando o erro aparecer).
• Convidados: busca, botão "Novo convidado", tabela (nome, mesa, status do RSVP, check-in, ações), formulário em modal ou seção (nome, e-mail, telefone, mesa em select, acompanhantes).
• Check-in: campo de código com autofocus + painel de resultado gigante (verde ou vermelho). Opcional: lista das últimas entradas.
• Dashboard: 4 números grandes (confirmados, pendentes, recusados, presentes), barra de capacidade, situação das mesas.

Wireflow: as telas ligadas

Wireframe mostra a tela; wireflow mostra a viagem. As quatro telas na mesa, setas numeradas ligando: de onde vem, pra onde vai, o que dispara cada passagem. A seta que sai do login se divide em três, uma por perfil (o redirect do 05 §7.1 desenhado no papel antes de existir em código).

Teste de mesa: o protótipo de papel funcionando

Com os wireframes prontos, o teste mais barato do mundo: uma narra, a outra opera. Uma faz a Renata ("cheguei, tem fila, o convidado me deu o código ABC12345") e a outra aponta com o dedo, no papel, onde clica e o que acontece. Toda hesitação do dedo é um problema de tela achado de graça, antes de existir uma linha de código.

Os tokens no canto da folha

Última coisa da segunda-feira: anotar no canto do wireframe as decisões de estilo (§8): a cor de ação, as quatro cores de status, a escala de espaço, o raio. Na quarta-feira da semana do front, essas anotações viram o :root do 05 §3.4, sem discussão e sem inventar na hora.

---

6. Gestalt: por que uma tela parece organizada 🆕

Antes de ler qualquer palavra, o olho já agrupou a tela. Gestalt é o conjunto de regras desse agrupamento automático. Quem conhece as regras desenha telas que o olho entende sozinho; quem não conhece depende de sorte.

As cinco que resolvem interface, cada uma com a tradução em CSS:

• Proximidade: o que está perto parece do mesmo grupo. Tradução: espaço dentro do grupo menor que espaço entre grupos. Com a escala de 8 do 05 §3.2: --espaco-2 entre o label e o input dele, --espaco-5 entre seções do formulário. Se o espaçamento é uniforme, não existe grupo, existe sopa.
• Semelhança: o que parece igual, funciona igual. Mesma cara de botão = mesmo tipo de ação; todo badge de status com o mesmo formato. (É a heurística 4 vista pela ótica visual.)
• Continuidade / alinhamento: o olho segue linhas. Campos alinhados à esquerda formam uma linha invisível que guia a leitura de cima a baixo. Um campo desalinhado quebra a linha e incomoda o usuário sem ele saber dizer por quê. Tradução: grid e uma linha de alinhamento só.
• Figura e fundo: o que salta é figura, o resto é contexto. Card com --sombra sobe da página; modal com overlay escuro vira a única figura da tela inteira.
• Região comum: borda ou fundo compartilhado agrupa mais forte que proximidade. O card em volta do formulário diz "isso aqui é uma coisa só" sem precisar de título.

---

7. Hierarquia visual: as alavancas 🔄🆕

Hierarquia visual é dizer pro olho o que olhar primeiro. As alavancas são cinco, e toda tela boa usa várias ao mesmo tempo:

• Tamanho: o número do dashboard é grande, o rótulo dele é pequeno. Ninguém confunde o que importa.
• Peso: negrito no que carrega o sentido, nunca em tudo (negrito em tudo = negrito em nada).
• Cor: a cor de ação só na ação. É a alavanca mais forte e a mais fácil de desperdiçar.
• Posição: o canto superior esquerdo lê primeiro. O que abre a tela define o assunto dela.
• Espaço: respiro em volta de um elemento é destaque de graça, sem adicionar nada.

A regra 60-30-10: 60% da tela em cor neutra (fundos), 30% em estrutura (textos, bordas, superfícies), 10% em cor de ação. É o que faz o botão primário gritar: ele é praticamente a única coisa colorida da tela. Se a cor de ação está em todo lugar, não existe ação em lugar nenhum.

Cor semântica fixa: verde = confirmado/sucesso, vermelho = recusado/erro/perigo, amarelo = pendente/atenção. São os tokens de status do 05 §3.4. Regra dura: essas cores nunca aparecem fora do significado. Um título verde decorativo quebra o código de cores do sistema inteiro.

Scanning em F: em interface, ninguém lê, todo mundo escaneia: linhas horizontais no topo, depois uma descida rápida pela margem esquerda. Duas consequências práticas: a primeira palavra do rótulo carrega o sentido ("Confirmar check-in", nunca "Clique aqui para confirmar o check-in"), e a coluna mais importante da tabela fica à esquerda (nome do convidado primeiro, ações por último).

Contraste tem número: 4.5:1 pra texto normal, 3:1 pra texto grande (WCAG). Os exemplos práticos e a checagem no DevTools estão no 05 §3.8; o que pertence a este módulo é a decisão: escolher combinações de texto e fundo que passam antes de codar, no dia dos tokens. Contraste não se conserta no fim, se decide no início.

---

8. Design system mínimo: decidir uma vez, usar sempre 🆕

Design system de empresa tem centenas de componentes documentados e um time cuidando. O da prova cabe num canto de folha e se decide uma vez, na segunda 31/08:

• 1 cor de ação (e só ela chama clique)
• 4 cores de status: verde, vermelho, amarelo, cinza neutro
• Escala de espaço de 8: 4 / 8 / 16 / 24 / 32 / 48
• 1 raio de borda pra tudo que é arredondado
• 1 sombra pra tudo que eleva
• 2 pesos de fonte (400 e 700) e 3 tamanhos além do base

O CSS disso já existe: é o bloco :root do 05 §3.4. A divisão de trabalho entre os módulos é essa: aqui é onde ele é decidido, lá é onde ele vive. Token não é técnica de CSS, é decisão de design congelada em código. Quando a decisão vem antes, o CSS vira digitação.

A segunda metade do design system é o inventário de componentes: a lista fechada de peças com que todas as telas são montadas.

(No celular, a tabela rola horizontal dentro do próprio container, 05 §4. Os estados da linha da tabela são os quatro estados do 05 §5.5.)

Oito componentes. Todas as telas do Wedding Pass são combinações dessas oito peças com os mesmos tokens. É pouca coisa de propósito: pouco e consistente ganha de muito e bagunçado, sempre.

---

9. Acessibilidade que pontua 🔄

Acessibilidade é fazer a interface funcionar pra mais gente: quem usa leitor de tela, quem enxerga pouco, quem não usa mouse, quem está num celular ruim no sol. E o melhor argumento pra prova: quase tudo que é acessível é melhor pra todo mundo. A Renata no tablet com pressa se beneficia dos mesmos cuidados que um usuário de leitor de tela.

Os oito itens baratos que pontuam:

1. Contraste: os números do §7 (4.5:1 e 3:1), decididos junto com os tokens. Checagem: DevTools ou o WebAIM Contrast Checker (referências).
2. Label ligado ao campo: <label for="email"> casando com o id do input (05 §2.3). Clicar no rótulo foca o campo, leitor de tela anuncia o nome certo. Custo zero.
3. Foco visível: nunca outline: none sem substituto. Com :focus-visible dá pra trocar o outline padrão por um contorno na cor de ação: fica bonito e acessível.
4. Navegação por teclado: Tab percorre os elementos na ordem do DOM (mais um motivo pro HTML em ordem lógica, 05 §2). Teste concreto: fazer um check-in inteiro sem tocar no mouse. No Wedding Pass isso nem é acessório: é o fluxo real da Renata.
5. Semântica: button é <button>, link é <a>. O leitor de tela entende button, não entende div clicável.
6. Alt em imagem: informativa descreve ("Logo do Wedding Pass"), decorativa leva alt="" vazio de propósito, pro leitor de tela pular em vez de ler o nome do arquivo.
7. Alvo de toque: 44 a 48px de altura pra botão e link no mobile. (O mínimo formal do WCAG 2.2 é 24px; dedo de verdade, com pressa, agradece o dobro.) Botão pequeno no tablet da recepção é erro de digitação em série.
8. Erro junto do campo, com cor E texto: borda vermelha + mensagem embaixo do campo que falhou. Cor sozinha exclui quem não distingue cor; mensagem longe do campo obriga a caçar o problema.

---

10. Microcopy: as palavras da interface 🆕

As palavras da interface são interface. Um botão mal nomeado é um bug de UX igual a um layout quebrado, só que mais barato de consertar.

A regra de ouro pra botão: verbo + objeto. O botão diz o que acontece quando é apertado.

As regras por trás da coluna da direita:

• Dizer o que acontece, não "OK".
• Nomear a coisa afetada (Maria Silva, não "o registro").
• No erro, dar o próximo passo (conferir os 8 caracteres).
• Falar a língua do domínio (§2.2), com o tom de quem ajuda.

O módulo 08 volta nisso com a biblioteca completa de mensagens do sistema, prontas pra reusar. Aqui o que importa é o critério: cada texto da interface passa no teste "isso ajuda a pessoa a decidir o que fazer agora?".

---

11. Como o CIS enxerga UX 🎯

UX é quase toda avaliação por julgamento (0 a 3), porque é qualitativa. Onde a nota aparece:

E como um descritor de julgamento de UX tipicamente escala, pra vocês saberem em que degrau cada entrega está:

• Nível 0: confuso, sem feedback; o avaliador precisa de ajuda pra completar a tarefa.
• Nível 1: dá pra usar, mas com tropeços: rótulo ambíguo, erro genérico, telas inconsistentes entre si.
• Nível 2: claro e consistente; as tarefas saem sem ajuda; feedback presente nas ações principais.
• Nível 3: claro, consistente, feedback em tudo, mensagens que ajudam de verdade, e detalhes de cuidado que impressionam: autofocus, empty state que ensina, "atualizado às 19h42".

A diferença entre 2 e 3 é o nosso jogo inteiro, e nesse critério ela é feita de detalhes que custam minutos. Poucos pontos da prova são tão baratos por unidade de esforço.

---

12. Autoavaliação do módulo

1. Qual a diferença entre UX, UI e usabilidade? Dá um exemplo de boa UI com péssima UX.
2. Quais são os cinco componentes da usabilidade? Qual deles o autofocus do check-in melhora mais?
3. Sem olhar a tabela: quantas das dez heurísticas você cita de cabeça, cada uma com um exemplo do Wedding Pass?
4. "Registro inserido com sucesso" quebra qual heurística? Reescreve a mensagem pro padrão nota 3.
5. O que é uma avaliação heurística e em que momento da prova ela entra?
6. Quem são Renata, Olívia, Ada e Caio? Qual a dor nº 1 de cada?
7. Por que o alerta de 90% da capacidade é uma decisão de UX, e não só uma regra de negócio?
8. A tarefa nº 1 de cada perfil sai em quantas ações a partir do login? Por que isso é arquitetura da informação?
9. O que um wireframe tem e o que ele não tem? Por que texto realista importa?
10. Como funciona o teste de mesa com o protótipo de papel?
11. Explica a proximidade (Gestalt) usando a escala de espaço do módulo 05.
12. O que é a regra 60-30-10 e qual token é os 10%?
13. Por que decorar os próprios tokens no treino economiza tempo na prova?
14. Cita três cuidados de acessibilidade baratos e o que o Lighthouse verifica por você.
15. Reescreve pra nota 3: o botão "OK", uma lista vazia em branco e a mensagem "Erro".
16. UX vale 10% da prova. Por que ele influencia bem mais que 10% da nota final?

---

---

Referências do módulo

Do plano de curso (bibliografia da UC16):

• NUNNALLY, B.; FARKAS, D. UX Research: guia prático de técnicas de pesquisa de usuário. (Novatec)
• KALBACH, J. Mapeamento de experiências. (Alta Books)
• ROGERS, Y.; SHARP, H.; PREECE, J. Design de Interação: além da interação humano-computador. (Bookman)
• TEIXEIRA, F. Introdução e boas práticas em UX Design. (Casa do Código)

Da web (mercado):

• 10 Usability Heuristics for User Interface Design (Nielsen Norman Group) — o texto original das dez, curto e em inglês simples. Ótimo pra treinar scanning (módulo 09).
• Laws of UX — os princípios de UX em cartões visuais, um por página.
• WebAIM Contrast Checker — cola as duas cores e ele diz se passa nos 4.5:1.
• W3C WAI: Introduction to Web Accessibility — a referência oficial de acessibilidade, direto da fonte.