UX/UI: heurísticas de Nielsen, prototipação, acessibilidade (WCAG/eMAG)

A ideia que organiza o assunto

Um sistema pode estar tecnicamente perfeito e ainda assim ser inútil. O cálculo está certo, a API responde em 40 ms, o dado é gravado — e a pessoa do outro lado da tela não acha o botão, não entende o rótulo do campo, preenche o formulário errado e liga para o suporte. Nada disso aparece em teste unitário, porque o defeito não está no código: está na distância entre o modelo mental de quem construiu e o de quem usa.

O assunto inteiro se organiza por quatro eixos que a banca embaralha de propósito, e quase todo item se decide sabendo em qual deles a frase está.

Usabilidade é facilidade de uso medida contra objetivos. A ISO 9241-11 a define como a medida em que um produto pode ser usado por usuários específicos para atingir objetivos específicos com eficácia, eficiência e satisfação em um contexto de uso específico. As três qualificações não são enfeite: usabilidade não existe em abstrato, existe para alguém, fazendo alguma coisa, em algum lugar.

Experiência do usuário (UX) é maior que usabilidade: abrange tudo o que a pessoa percebe antes, durante e depois do uso — expectativa, emoção, confiança, o e-mail de confirmação que chegou ou não chegou. Usabilidade é um componente da UX, não sinônimo dela. E UI é menor que as duas: é a camada concreta, o desenho visual e interativo da tela.

Acessibilidade é outro eixo, e é aqui que a maioria erra. Ela não é “usabilidade para deficientes”. É a propriedade de o conteúdo poder ser percebido, operado e compreendido por qualquer pessoa, independentemente de deficiência, de tecnologia assistiva ou de contexto. Um sítio pode ser altamente usável para quem enxerga e completamente inacessível para quem usa leitor de tela. Os eixos são independentes.

Inclusão é o quarto: projetar contemplando a diversidade de quem usa. Tons de pele variados na lista de emojis e avatar de gênero neutro são design inclusivo — não deixam o produto mais fácil de usar, deixam mais gente representada nele. A CEBRASPE já cobrou exatamente essa separação.

Por que se usa (e o que custa)

Para o setor público, acessibilidade não é boa prática: é obrigação. A Lei n.º 10.098/2000 estabeleceu as normas gerais de acessibilidade, o Decreto n.º 5.296/2004 alcançou os portais e sítios da administração pública e a Lei Brasileira de Inclusão (Lei n.º 13.146/2015) estendeu a exigência aos sítios mantidos por empresas com sede no país. Sobre essa base legal o Governo Federal publicou o eMAG, cuja observância nos sítios do governo federal foi tornada obrigatória por portaria em 2007.

A divisão de papéis é item de prova pronto: a W3C, pela iniciativa WAI, publica a WCAG, que é recomendação técnica internacional e não tem força de lei. Quem dá força legal no Brasil é a legislação brasileira; quem detalha o “como” para o governo federal é o eMAG. A W3C não estabelece bases legais aqui, e o eMAG não dispensa a W3C — ele se declara baseado nela.

O que se paga é real e a banca cobra que você admita. Acessibilidade e segurança competem com desempenho e com simplicidade de interface: acrescentar camadas de proteção degrada usabilidade, e isso é uma tensão legítima de projeto arquitetural, não um defeito de quem projetou. Do mesmo modo, prototipar custa tempo antes de existir código — e se paga porque erro de requisito e erro de interface são os mais caros de corrigir tarde.

Como funciona

As dez heurísticas de Nielsen

São o instrumento da avaliação heurística, um método de inspeção, feito por especialistas, sem usuários. Nielsen recomenda de 3 a 5 avaliadores independentes — cinco encontram cerca de três quartos dos problemas — e cada problema recebe severidade de 0 a 4.

#	heurística	o que exige
1	Visibilidade do status do sistema	informar o que está acontecendo, em tempo razoável
2	Correspondência com o mundo real	linguagem do usuário, não do sistema; ordem natural
3	Controle e liberdade do usuário	saída de emergência: desfazer, refazer, cancelar
4	Consistência e padrões	mesma coisa, mesma palavra; obedecer à convenção da plataforma
5	Prevenção de erros	melhor impedir o erro do que avisar depois
6	Reconhecer em vez de lembrar	opções visíveis; não exigir memória entre telas
7	Flexibilidade e eficiência de uso	atalhos para o experiente sem atrapalhar o novato
8	Design estético e minimalista	nada de irrelevante competindo com o relevante
9	Reconhecer, diagnosticar e recuperar-se de erros	mensagem em linguagem simples, com a saída
10	Ajuda e documentação	disponível, buscável, focada na tarefa

A confusão clássica é entre a 5 e a 9: prevenir o erro (desabilitar a data inválida no calendário) é a 5; explicar o erro já cometido é a 9.

WCAG: POUR, diretrizes, critérios e níveis

A WCAG tem três andares, e a prova mora na diferença entre eles.

No topo, quatro princípios — o acrônimo POUR:

• Perceptível — informação e componentes têm de poder ser percebidos: alternativa em texto para conteúdo não textual, legenda e audiodescrição, contraste, não depender só de cor.
• Operável — a interface tem de poder ser operada: tudo pelo teclado, sem armadilha de foco, limites de tempo ajustáveis, nada que pisque de forma perigosa, navegação e títulos que orientem.
• Compreensível — informação e operação da interface têm de ser entendidas: idioma identificado, comportamento previsível, ajuda na entrada de dados e na correção de erros.
• Robusto — o conteúdo tem de ser interpretável por agentes variados, inclusive tecnologias assistivas: marcação válida, nome, função e valor expostos.

Sob os princípios vêm as diretrizes, e sob elas os critérios de sucesso, que são a única coisa testável. Cada critério tem um nível de conformidade: A é o mínimo, sem o qual há barreira que impede o acesso; AA é o alvo prático e o que a legislação costuma exigir; AAA é o máximo, e a própria W3C diz que não se recomenda exigi-lo como política para um sítio inteiro. Conformidade é cumulativa: alegar AA significa satisfazer todos os critérios A e AA. Não existe cumprir AA pulando um critério A.

eMAG

O eMAG — Modelo de Acessibilidade em Governo Eletrônico, versão corrente 3.1 — é a adaptação brasileira da WCAG para os sítios do governo. São 45 recomendações em seis seções:

seção	do que trata	recomendações que a banca cobra
Marcação	como o HTML é escrito	respeitar os padrões web; organizar o código de forma lógica e semântica; usar corretamente os níveis de cabeçalho; não usar tabelas para diagramação; separar links adjacentes; dividir as áreas de informação; não abrir novas instâncias sem solicitação do usuário
Comportamento (DOM)	o que a página faz sozinha	todas as funções disponíveis via teclado; não criar páginas com atualização automática periódica; não usar redirecionamento automático (META com http-equiv="refresh"); fornecer alternativa para modificar limite de tempo; não provocar intermitência de tela
Conteúdo / Informação	o texto e a orientação	identificar o idioma; título descritivo; migalha de pão informando a localização; descrever links clara e sucintamente; alternativa em texto para imagens; disponibilizar documentos em formatos acessíveis; explicar siglas
Apresentação / Design	o visual	contraste mínimo entre primeiro plano e fundo; não usar apenas cor para diferenciar; permitir redimensionamento; foco do teclado visualmente evidente
Multimídia	áudio e vídeo	alternativa para vídeo (legenda e transcrição) e para áudio; audiodescrição; controle de som automático
Formulário	entrada de dados	associar etiquetas aos campos; ordem lógica de navegação; instruções de preenchimento; identificar erros e confirmar o envio; agrupar campos; preferir estratégias de segurança alternativas ao CAPTCHA

Fora das recomendações, o eMAG padroniza elementos que devem constar das páginas de governo: barra de acessibilidade, teclas de atalho (1 conteúdo, 2 menu, 3 busca, 4 rodapé), mapa do sítio, página de acessibilidade e conteúdo alternativo para imagens.

Prototipação: a escada de fidelidade

A ordem é fixa, e a banca a inverte com prazer. Wireframe vem primeiro: esquema estrutural, baixa fidelidade, sem cor nem tipografia definitiva — responde “o que vai onde”. Mockup vem depois: ainda estático, mas de alta fidelidade visual, com cor, fonte e imagem — responde “com que aparência”. Protótipo é a evolução navegável: acrescenta interação e navegação, simula o funcionamento — responde “como se comporta”.

O protótipo demonstra conceitos, valida opções de projeto e apoia a elicitação e a validação de requisitos; por isso reduz risco de requisito. Ele não dispensa a identificação de requisitos — é técnica de elicitação. E tem limitação conhecida: as partes interessadas se prendem ao desenho apresentado e o desenvolvedor passa a achar que deve reproduzir a interface ao pé da letra.

O MVP é coisa distinta: mínimo em escopo, não em qualidade. A funcionalidade parcial que ele entrega tem de ter padrão comercial, porque será usada de verdade.

Avaliação, pesquisa e arquitetura da informação

A divisão que a prova usa separa métodos não empíricos (analíticos, de inspeção, feitos por especialistas sem usuário: avaliação heurística, percurso cognitivo, análise de tarefas) de métodos empíricos (com usuários reais: teste de usabilidade, card sorting, questionários, observação). O teste de usabilidade observa usuários reais executando tarefas reais para descobrir onde travam, erram e desistem — não é teste de responsividade nem de desempenho.

A arquitetura da informação, na formulação de Rosenfeld e Morville, tem quatro sistemas: organização, navegação, rotulação e busca.

O que decide os itens

Um item de Certo/Errado não é decidido por um assunto, e sim por uma distinção. Estas decidem aqui.

O eixo da frase — é o mais produtivo de todos:

se o item fala em	o eixo é	e a resposta mora em
leitor de tela, teclado, contraste, legenda, alternativa textual	acessibilidade	eMAG / WCAG
eficiência, satisfação, aprendizado, erro do usuário, tarefa	usabilidade	ISO 9241-11, Nielsen
expectativa, emoção, jornada, pesquisa com usuário, persona	UX	—
cor, tipografia, espaçamento, aparência e estados da tela	UI	—
representatividade, diversidade de quem usa	inclusão	—

Quem produz o quê — W3C publica a WCAG (recomendação, sem força de lei); a legislação brasileira obriga; o eMAG detalha para o governo federal, baseado na WCAG e sem substituí-la.

Fidelidade do artefato — wireframe (estrutura, estático) × mockup (aparência, estático) × protótipo (navegável, interativo) × MVP (produto reduzido em escopo, completo em qualidade).

Empírico × não empírico — com usuário ou sem usuário. Avaliação heurística, percurso cognitivo e análise de tarefas são inspeção. Teste de usabilidade e card sorting envolvem usuários.

Requisito funcional × não funcional — usabilidade, desempenho, segurança, confiabilidade, disponibilidade e manutenibilidade são não funcionais. Funcional é o que o sistema faz.

Qualidade interna e externa × qualidade em uso (ISO 9126) — funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade são do primeiro modelo. Qualidade em uso tem outras características: eficácia, produtividade, segurança e satisfação.

Etapa do design thinking — empatia, definição, ideação, prototipação, teste. Brainstorming é da ideação, não da prototipação. A lógica que o método emprega é a abdutiva.

Números que caem

número	de quê
10	heurísticas de Nielsen
3 a 5	avaliadores recomendados na avaliação heurística (5 acham ~75% dos problemas)
0 a 4	escala de severidade dos problemas
4	princípios da WCAG (POUR)
A, AA, AAA	níveis de conformidade da WCAG — cumulativos
4,5:1	contraste mínimo para texto normal (critério 1.4.3, nível AA)
3:1	contraste mínimo para texto ampliado (1.4.3, AA)
7:1	contraste reforçado (1.4.6, AAA)
200%	ampliação do texto sem perda de conteúdo ou funcionalidade (1.4.4, AA)
3.1	versão corrente do eMAG
45	recomendações do eMAG, em 6 seções
1, 2, 3, 4	teclas de atalho padronizadas: conteúdo, menu, busca, rodapé
6	características de qualidade da ISO 9126
4	sistemas da arquitetura da informação

Como a CEBRASPE derruba você aqui

Acessibilidade é quase um terço do tópico, e o eMAG é o texto cobrado. Dos itens explicados aqui, cerca de trinta em cada cento tratam de eMAG, WCAG, contraste, leitor de tela ou deficiência — e a maioria deles é Certo: a banca transcreve a recomendação fielmente e espera que você a reconheça. Por isso o custo de errar está concentrado nos poucos que ela inverte. Leia a lista de recomendações do eMAG como se fosse artigo de lei.

Inversão da recomendação — 41% dos itens errados, o molde dominante do tópico. É barato de produzir: pega-se a recomendação e retira-se o “não”. “A utilização de tabelas para diagramação e disposição dos elementos na página web” como recomendação do eMAG — a recomendação é não utilizar; tabela é para dados. Elementos gráficos que “devem possuir baixo contraste com o plano de fundo”. “Agregar ou agrupar, sempre que possível, as áreas de informação para facilitar o gerenciamento e evitar a divisão da informação” — a recomendação é dividir. Uma nova janela “deve ser seguida necessariamente de notificação e aceitação do usuário” — o eMAG não abre nova instância sem solicitação prévia. Dados de formulário “gravadas sem confirmação do usuário”. E o meio-termo traiçoeiro: todos os elementos acessíveis por teclado “em páginas que devem ser atualizadas automaticamente” — metade certa, metade invertida, porque atualização automática é justamente o que o eMAG proíbe. Fora da acessibilidade, o mesmo molde nega uma prática consagrada: “É desnecessária a elaboração de protótipos”; “não é possível apresentar os dados estatísticos por meio de gráficos”; a etnografia “ineficaz em descobrir requisitos derivados da cooperação e do conhecimento das atividades das pessoas”, quando é exatamente nisso que ela é forte; “deve-se evitar o uso de recursos de interface recorrentes em outros sítios de Internet”, quando a convenção é o que barateia o aprendizado; obter “feedbacks dos usuários o mais tarde possível” no Lean UX; páginas de um mesmo sítio que “devem ter estrutura, identidade e interface próprias”. Inverte também ordens e escopos: o MVP que “dispensa padrões de qualidade comercial” ou que “seja completamente funcional e identifique o maior número de requisitos que agregam valor” — é mínimo em escopo e completo em qualidade; mockups “nas fases iniciais de projetos com protótipos, focando-se na estrutura e funcionalidade básica”, quando o wireframe vem antes e cuida da estrutura; o design thinking “centrada em processos” e voltada a problemas “que não sejam complexos”. A defesa é uma pergunta única e prévia: a versão correta desta frase é sim ou é não? Responda antes de ler o resto.

Troca de termo entre vizinhos — 30%. A definição está certa e o nome não. UI recebendo a definição de UX. “O princípio denominado perceptível” recebendo a definição de compreensível, no POUR. Acessibilidade definida como “tornar todas as informações e os documentos acessíveis por meio dos links de navegação”, que é navegabilidade — e a navegabilidade reduzida a um sítio em que “todos os seus links de navegação estão operacionais”, quando ela é saber onde se está. “O grau de intuição determina a facilidade para localizar informações” — intuitividade é saber operar; localizar é navegabilidade. O wireframe como algo que “designa a estrutura de informações em um banco de dados”, e o wireframe que “representa um protótipo navegável”, quando é estático. A engenharia de usabilidade encarregada do “desenvolvimento de interfaces entre sistemas”, quando cuida da interface entre o sistema e a pessoa. A arquitetura da informação promovendo “redução da informação”, quando organiza. Design inclusivo assinado como exemplos de “um design mais utilizável (usable)”. Teste de usabilidade servindo para “detectar problemas de responsividade dos sítios”. E os nomes próprios: “Microsoft Vision” na lista de leitores de tela, onde cabem Jaws, NVDA, Virtual Vision e Narrador. O reflexo certo: leia a definição primeiro, decida que nome ela tem e só então confira o nome que o item escreveu.

Atribuição errada de órgão, etapa ou modelo. “Compete ao comitê W3C estabelecer”, com fundamento na Lei n.º 10.098/2000, as bases legais da acessibilidade — a W3C recomenda, a legislação brasileira obriga e o eMAG detalha. O brainstorming “na etapa de prototipação do design thinking” — é da ideação. Requisitos de projeto “especificados na atividade de implementação do processo de desenvolvimento” — decidir projeto antecede implementar. Atributos lançados no bloco errado da ISO, “do modelo para qualidade em uso” quando são de qualidade interna e externa. E o Zend, framework PHP de servidor, apresentado como “parte fundamental do desenvolvimento web front-end”.

Escopo esticado. A regra certa, ampliada além do domínio. As recomendações brasileiras que “substituem, sem nenhuma perda, os padrões web internacionais definidos pelo W3C” — o eMAG complementa a WCAG, não a substitui. O teste de usabilidade estendido às “deficiências de suporte tecnológico”. E a definição correta de requisito funcional — o que o software deverá fazer — alargada logo em seguida: “Esses requisitos incluem tempo de resposta, utilização de volumetria estática, escalabilidade, disponibilidade, segurança e usabilidade”, que são atributos de qualidade e, portanto, requisitos não funcionais.

Causa inventada, ligada por “pois” ou “uma vez que”. “Lean UX e Agile UX são mutuamente exclusivas, pois o Agile UX está focado em cortar processos desnecessários” — enxugar desperdício é do Lean, e as duas são complementares. A prototipação que “dispensa a identificação dos requisitos do software” porque ela própria elicitaria tudo. E, num item de código, “este é um exemplo de programação assíncrona, uma vez que as três funções não dependem umas das outras para serem executadas” — independência entre funções não implica execução assíncrona. Oração explicativa no fim do item pede leitura em dobro.

Exceção omitida na WCAG. Rara — um item —, e a mais discreta. “Sugestões para correção de erros devem ser apresentadas independentemente do propósito do conteúdo”: o critério 3.3.3 ressalva os casos em que a sugestão comprometeria a segurança ou a finalidade do conteúdo. Critério da WCAG que soa absoluto tem lista de exceções logo abaixo; “independentemente de”, “em qualquer caso” e “sem exceção” são o sinal.

As heurísticas de Nielsen — ainda não medidas. Nenhum dos itens explicados deste tópico cita Nielsen, avaliação heurística ou qualquer das dez heurísticas pelo nome. A tabela permanece na nota porque é vocabulário clássico do assunto e aparece com frequência em outras bancas, mas não organize sua revisão em torno dela: no corpus da CEBRASPE, quem decide os itens de interface é o eMAG, e depois dele o par wireframe × protótipo e o par UX × UI.

Erros clássicos

Tratar acessibilidade e usabilidade como a mesma coisa. Um sítio pode ser fácil e inacessível, ou acessível e confuso. São eixos independentes, e o item quase sempre avisa em qual está pela palavra que usa.

Achar que o eMAG substitui a WCAG. Ele é baseado nela e manda seguir os padrões web e as diretrizes da W3C, além de avaliar a acessibilidade. Item que diga que o eMAG substitui “sem nenhuma perda” os padrões internacionais está errado por construção.

Confundir os princípios da WCAG com os níveis. POUR são quatro princípios; A, AA e AAA são níveis de conformidade dos critérios. Não existe “princípio AA” nem “nível perceptível”. E AA não é um conjunto separado de A: conformar em AA exige cumprir A e AA.

Colocar usabilidade nos requisitos funcionais. Usabilidade, desempenho, segurança e disponibilidade são não funcionais. Requisito funcional diz o que o sistema faz.

Misturar qualidade em uso com qualidade interna e externa. As seis características da ISO 9126 — incluindo usabilidade — são de qualidade interna e externa. Qualidade em uso é eficácia, produtividade, segurança e satisfação.

Supor que o usuário navega em ordem. A cartilha de usabilidade do governo parte do contrário: as pessoas varrem a página, entram por qualquer ponto e não leem de forma sistemática. Item que atribua ao usuário comportamento metódico e coerente costuma ser E.

Querer que cada sítio tenha identidade própria. Em governo eletrônico vale o oposto: padronização de estrutura, identidade e interface entre as páginas vinculadas, e aproveitamento das convenções já consagradas em outros sítios. Originalidade de interface é custo cognitivo, não virtude.

Confundir prevenir com explicar o erro. Heurística 5 impede que o erro aconteça; heurística 9 ajuda a reconhecer, diagnosticar e sair dele. Mensagem de erro clara não é prevenção de erro.