Manual Técnico de Frontend, UI, UX, Design e IA para Produtos Digitais

Versão: 1.0
Data de revisão: 1º de agosto de 2026
Idioma: Português do Brasil
Objetivo: servir como guia técnico, crítico e prático para estudar, projetar, desenvolver, avaliar e governar interfaces e produtos digitais.

Aviso de escopo

Este documento trata frontend, UI, UX, design de produto, acessibilidade, desempenho, segurança, testes, design systems e integração com inteligência artificial como disciplinas interdependentes.

Ele não presume que:

uma biblioteca popular seja automaticamente a melhor;
um layout visualmente bonito seja uma boa experiência;
uma interface gerada por IA esteja pronta para produção;
React seja obrigatório;
“mais tecnologia” signifique “mais qualidade”;
boas práticas dispensem pesquisa, medições e testes com usuários;
acessibilidade possa ser resolvida apenas por ferramentas automáticas;
um design system seja somente uma biblioteca de botões.

As recomendações estão classificadas informalmente como:

Consolidado: prática sustentada por padrões, documentação oficial, ampla experiência de mercado ou pesquisa consistente.
Contextual: depende do produto, da equipe, da infraestrutura e do perfil dos usuários.
Tendência: prática relevante e promissora, mas que exige validação antes de virar padrão interno.
Antipadrão: abordagem que costuma produzir mais riscos que benefícios.

Sumário

Conclusão executiva
O que são frontend, UI, UX e design
Como um produto digital funciona
Fundamentos da plataforma web
Processo completo de UX e produto
Pesquisa com usuários
Arquitetura da informação
Interação e usabilidade
Fundamentos visuais de UI
Responsividade e múltiplos dispositivos
Acessibilidade digital
Conteúdo, microcopy e comunicação
Estados de interface
Formulários, tabelas e dashboards
Arquitetura de frontend
Renderização: CSR, SSR, SSG, streaming e ilhas
Componentes, composição e organização do código
Estado, dados e comunicação com APIs
Frameworks e bibliotecas mais conhecidos
CSS, estilização e bibliotecas de interface
Design systems
Ferramentas de design e desenvolvimento
Testes de frontend
Desempenho e Core Web Vitals
Segurança e privacidade
SEO, internacionalização, PWA e offline
Observabilidade, analytics e experimentação
IA aplicada a frontend, UI e UX
Sites oficiais de desenvolvedores de IA
Personalidades e autores influentes
Livros, artigos, padrões e estudos
Fóruns, comunidades e fontes de atualização
Como avaliar a confiabilidade de uma fonte
Matrizes para escolha de tecnologias
Arquiteturas recomendadas por tipo de projeto
Recomendação para sistemas corporativos com Java
Projeto prático: sistema de manutenção
Trilha de estudo progressiva
Checklists operacionais
Antipadrões frequentes
Glossário
Diretório de referências oficiais
Recomendação final

1. Conclusão executiva

1.1 A verdade central

Frontend profissional não é apenas “fazer a tela”. É a engenharia da parte do produto com a qual o usuário interage, incluindo:

estrutura semântica;
apresentação visual;
comportamento;
fluxo de tarefas;
comunicação com serviços;
acessibilidade;
segurança no cliente;
desempenho;
compatibilidade;
estados de erro;
instrumentação;
testes;
manutenção;
coerência com o negócio.

UI não é UX. UI é a camada de interface. UX é a experiência completa criada pela combinação entre utilidade, usabilidade, clareza, desempenho, conteúdo, confiança, acessibilidade, suporte e resultado obtido.

Um produto pode ter uma UI bonita e uma UX ruim. Exemplos:

animações elegantes, mas carregamento lento;
dashboard moderno, mas sem indicar de onde vêm os dados;
formulário visualmente limpo, mas que apaga o preenchimento após um erro;
sistema com ícones minimalistas, mas sem rótulos compreensíveis;
botão “Concluir” que não informa consequências;
menu sofisticado que esconde tarefas frequentes;
chatbot de IA com aparência premium que inventa respostas sem indicar incerteza.

1.2 Hierarquia correta de decisões

A ordem recomendada é:

Problema e objetivo do usuário
Risco e regra de negócio
Conteúdo e fluxo
Acessibilidade e usabilidade
Arquitetura de informação
Arquitetura técnica
Comportamento e estados
Sistema visual
Animações e refinamento
Otimização contínua por evidências

Começar pela cor, pelo framework ou pela animação é começar pelo fim.

1.3 Stack não substitui engenharia

Uma aplicação com React, Next.js, Tailwind e uma biblioteca de componentes pode ser ruim.
Uma aplicação com HTML, CSS e JavaScript simples pode ser excelente.

A qualidade depende de:

adequação ao problema;
competência da equipe;
simplicidade operacional;
coerência da arquitetura;
testes;
acessibilidade;
métricas;
governança;
manutenção futura.

1.4 Recomendação geral

Para a maioria dos sistemas corporativos internos:

não comece com microsserviços;
não use uma SPA complexa quando páginas renderizadas no servidor resolvem;
não crie um design system completo antes de haver padrões repetidos;
não adote bibliotecas sem avaliar acessibilidade, manutenção e lock-in;
não exponha segredos de API no navegador;
não valide UX apenas com opinião de gestor ou desenvolvedor;
não trate dashboards como “coleção de gráficos”.

2. O que são frontend, UI, UX e design

2.1 Frontend

É a camada executada ou apresentada no dispositivo do usuário. Em aplicações web, normalmente envolve:

HTML;
CSS;
JavaScript;
TypeScript;
DOM;
APIs do navegador;
componentes;
roteamento;
formulários;
gerenciamento de estado;
comunicação HTTP;
tratamento de erros;
cache;
autenticação no cliente;
testes;
build e distribuição.

Frontend também pode existir em:

aplicativos móveis;
aplicações desktop;
terminais industriais;
smart TVs;
painéis embarcados;
interfaces de voz;
realidade aumentada;
sistemas multimodais.

2.2 UI — User Interface

É a interface pela qual o usuário percebe e opera o sistema.

Abrange:

layout;
tipografia;
cores;
componentes;
ícones;
espaçamento;
movimento;
feedback;
estados;
responsividade;
densidade de informação.

2.3 UX — User Experience

É a experiência resultante antes, durante e depois do uso.

Abrange:

descoberta do produto;
expectativas;
utilidade;
facilidade;
eficiência;
confiança;
prevenção e recuperação de erros;
acessibilidade;
suporte;
satisfação;
percepção de valor;
consequências operacionais.

2.4 Product Design

Integra:

objetivos do usuário;
estratégia de produto;
experiência;
interface;
restrições técnicas;
métricas;
viabilidade;
impacto de negócio.

2.5 Interaction Design

Define como o sistema responde às ações:

cliques;
gestos;
teclado;
voz;
foco;
arrastar e soltar;
seleção;
confirmação;
desfazer;
transições;
feedback.

2.6 Visual Design

Trabalha percepção e hierarquia visual:

composição;
cor;
tipografia;
contraste;
ritmo;
alinhamento;
forma;
identidade;
consistência.

2.7 Information Architecture

Organiza conteúdo e caminhos:

hierarquias;
taxonomias;
navegação;
nomenclatura;
busca;
filtros;
agrupamentos;
relacionamentos.

2.8 Content Design e UX Writing

Planejam o conteúdo necessário para o usuário cumprir uma tarefa.

Não se limitam a “escrever textos bonitos”. Incluem:

nomes de campos;
títulos;
instruções;
mensagens de erro;
confirmações;
avisos;
status;
ajuda contextual;
conteúdo legal;
tom de voz.

2.9 Service Design

Analisa a experiência além da tela:

atendimento;
pessoas;
processos;
sistemas internos;
políticas;
canais;
evidências físicas;
dependências operacionais.

2.10 Design System

É um sistema governado de decisões reutilizáveis, composto por:

princípios;
tokens;
componentes;
padrões;
conteúdo;
acessibilidade;
documentação;
processos de contribuição;
versionamento;
critérios de qualidade.

Uma pasta no Figma e uma biblioteca de botões não constituem, sozinhas, um design system.

3. Como um produto digital funciona

3.1 Fluxo básico de uma aplicação web

Usuário
   ↓
Navegador
   ↓
HTML + CSS + JavaScript
   ↓ HTTP/HTTPS
API ou servidor de aplicação
   ↓
Regras de negócio
   ↓
Banco de dados e integrações

3.2 Responsabilidades recomendadas

Navegador

exibir a interface;
coletar entradas;
oferecer feedback imediato;
realizar validações de conveniência;
chamar APIs;
apresentar estados;
manter dados transitórios permitidos;
respeitar acessibilidade.

Backend

validar dados definitivamente;
autenticar e autorizar;
executar regras;
proteger segredos;
consultar e persistir dados;
integrar sistemas;
registrar auditoria;
impor consistência;
limitar abusos.

Banco de dados

persistir;
impor integridade;
indexar;
suportar transações;
garantir recuperação;
aplicar controles de acesso.

3.3 Regra crítica

Nunca confie apenas no frontend para regras de segurança ou negócio.

O usuário pode:

desabilitar JavaScript;
alterar requisições;
chamar a API fora da interface;
modificar valores no DevTools;
automatizar chamadas;
usar versões antigas do cliente.

Validação no frontend melhora a experiência. Validação no backend protege o sistema.

4. Fundamentos da plataforma web

4.1 HTML

HTML define estrutura e significado.

Elementos semânticos importantes:

header
nav
main
section
article
aside
footer
form
label
button
table
dialog

Princípios:

use o elemento correto antes de simular comportamento com div;
associe label e campo;
use button para ação;
use a para navegação;
preserve hierarquia de títulos;
forneça texto alternativo adequado;
represente tabelas como tabelas quando os dados forem tabulares.

Referências:

4.2 CSS

CSS controla apresentação e parte da responsividade.

Conceitos indispensáveis:

cascade;
specificity;
inheritance;
box model;
flow;
flexbox;
grid;
positioning;
stacking context;
media queries;
container queries;
logical properties;
custom properties;
layers;
transitions;
animations;
typography responsiva.

Referências:

4.3 JavaScript

JavaScript controla comportamento e comunicação.

Fundamentos:

tipos;
funções;
escopo;
objetos;
arrays;
módulos;
promises;
async/await;
eventos;
DOM;
fetch;
tratamento de erros;
closures;
imutabilidade contextual;
event loop.

Referências:

4.4 TypeScript

TypeScript adiciona análise estática de tipos ao ecossistema JavaScript.

Benefícios:

contratos mais claros;
melhor refatoração;
autocomplete;
detecção antecipada de incompatibilidades;
documentação pelo código;
maior segurança em bases extensas.

Limitações:

tipos não validam automaticamente dados externos em execução;
aumenta configuração e conceitos;
tipos complexos podem virar um projeto paralelo;
o navegador não executa TypeScript diretamente.

Use validação de runtime para dados externos, com ferramentas como Zod, Valibot, ArkType ou validação manual.

Referência:

TypeScript Handbook

4.5 DOM

O DOM é a representação estruturada do documento disponibilizada ao JavaScript.

O framework não elimina o DOM. Ele abstrai ou organiza operações sobre ele.

4.6 HTTP

HTTP é o protocolo usado para troca de mensagens entre cliente e servidor.

Conceitos mínimos:

método;
URL;
cabeçalhos;
corpo;
status;
cache;
cookies;
CORS;
autenticação;
HTTPS.

Métodos comuns:

Método	Uso típico
`GET`	consultar
`POST`	criar ou executar ação
`PUT`	substituir
`PATCH`	alterar parcialmente
`DELETE`	remover

Status frequentes:

Código	Significado
`200`	sucesso
`201`	criado
`204`	sucesso sem corpo
`400`	requisição inválida
`401`	não autenticado
`403`	autenticado sem permissão
`404`	recurso não encontrado
`409`	conflito
`422`	dados semanticamente inválidos
`429`	excesso de requisições
`500`	falha interna

Referências:

4.7 APIs

APIs são contratos de comunicação.

Estilos comuns:

REST;
GraphQL;
RPC;
WebSocket;
Server-Sent Events;
webhooks;
gRPC, normalmente entre serviços.

Critérios de qualidade:

contrato claro;
versionamento coerente;
erros previsíveis;
idempotência;
paginação;
filtros;
limites;
autenticação;
documentação;
exemplos;
observabilidade.

4.8 JSON

JSON é um formato de dados, não uma linguagem de programação.

{
  "ordem": 3124,
  "status": "em_andamento",
  "prioridade": "alta"
}

Java, JavaScript, Python, C#, Go e outras linguagens podem produzir e consumir JSON.

5. Processo completo de UX e produto

5.1 Processo recomendado

Entender → Definir → Explorar → Prototipar → Validar → Construir → Medir → Aprender

Não é uma linha rígida. É um ciclo.

5.2 Etapa 1 — Entender

Investigue:

quem usa;
contexto de uso;
tarefa;
frequência;
consequências do erro;
ambiente;
dispositivos;
limitações;
objetivos;
processos atuais;
dados disponíveis;
métricas;
restrições legais e técnicas.

5.3 Etapa 2 — Definir

Produza:

problema delimitado;
público;
cenário;
hipótese;
resultado esperado;
critério de aceite;
risco;
métrica;
fora de escopo.

Exemplo ruim:

Criar um dashboard moderno.

Exemplo melhor:

Reduzir de 15 para 5 minutos o tempo necessário para o supervisor identificar os três maiores desvios de consumo energético do dia, mantendo rastreabilidade da origem do dado.

5.4 Etapa 3 — Explorar

Gere alternativas de:

fluxo;
arquitetura;
interação;
visualização;
conteúdo;
prioridade;
automação.

Não escolha a primeira ideia porque “parece óbvia”.

5.5 Etapa 4 — Prototipar

Níveis:

esboço;
wireframe;
protótipo navegável;
protótipo de alta fidelidade;
código experimental.

Escolha fidelidade conforme a dúvida.

Não use alta fidelidade para esconder que o fluxo ainda não foi resolvido.

5.6 Etapa 5 — Validar

Métodos:

teste moderado;
teste não moderado;
entrevista;
avaliação heurística;
teste de acessibilidade;
revisão técnica;
teste de conteúdo;
análise de tarefa;
experimento controlado, quando apropriado.

5.7 Etapa 6 — Construir

Inclua:

requisitos;
estados;
regras;
responsividade;
acessibilidade;
erros;
instrumentação;
testes;
documentação.

5.8 Etapa 7 — Medir

Meça comportamento e resultado, não apenas pageviews.

Exemplos:

taxa de conclusão;
tempo de tarefa;
erros;
abandono;
retrabalho;
chamados;
sucesso na primeira tentativa;
desempenho;
satisfação;
incidentes;
acessibilidade;
consumo de recursos.

5.9 Etapa 8 — Aprender

Compare:

hipótese;
resultado;
efeitos colaterais;
grupos afetados;
custos;
limitações;
próximos testes.

6. Pesquisa com usuários

6.1 Princípio

A equipe conhece o sistema. O usuário conhece o trabalho real.

Nenhum dos dois, isoladamente, conhece toda a solução.

6.2 Métodos qualitativos

entrevistas;
observação contextual;
shadowing;
teste de usabilidade;
diário de uso;
análise de incidentes;
card sorting;
tree testing;
estudo de campo.

Servem para compreender:

motivos;
modelos mentais;
linguagem;
dificuldades;
exceções;
improvisos;
contexto.

6.3 Métodos quantitativos

analytics;
funis;
coortes;
logs;
pesquisas estruturadas;
tempo de tarefa;
taxa de sucesso;
testes A/B;
telemetria;
volume de suporte.

Servem para estimar:

frequência;
distribuição;
tendência;
magnitude;
correlação;
impacto.

6.4 Combinação recomendada

Quantitativo responde frequentemente o que acontece e quanto.
Qualitativo ajuda a compreender por que acontece.

Uma pesquisa de opinião não substitui observação de comportamento.

6.5 Entrevista: erros comuns

induzir resposta;
defender solução;
perguntar “você usaria?”;
pedir previsão de comportamento;
entrevistar somente patrocinadores;
transformar opinião isolada em requisito;
confundir reclamação com causa;
registrar apenas frases que confirmam a hipótese.

6.6 Perguntas melhores

“Conte a última vez em que isso aconteceu.”
“O que você fez primeiro?”
“Que informação faltou?”
“O que acontece quando há erro?”
“Quem precisa aprovar?”
“Que planilha ou sistema você consulta?”
“Como você sabe que terminou?”
“Qual é a consequência de uma decisão errada?”

6.7 Personas

Contextual.

Personas são úteis quando sintetizam pesquisa real e mudam decisões.

São inúteis quando viram personagens decorativos com idade, foto genérica e hobbies irrelevantes.

Alternativas ou complementos:

perfis comportamentais;
segmentos por tarefa;
papéis operacionais;
níveis de experiência;
contextos de uso;
Jobs to Be Done;
cenários.

6.8 Amostragem

Não existe número universal.

Para testes qualitativos:

pequenos ciclos recorrentes costumam ser melhores que uma grande rodada tardia;
diferentes perfis e tarefas podem exigir amostras separadas;
sistemas críticos exigem maior cobertura;
resultados qualitativos não devem ser apresentados como estimativas estatísticas.

6.9 Ética e privacidade

informe objetivo;
obtenha consentimento;
minimize dados;
proteja identidade;
limite acesso;
defina retenção;
evite gravação desnecessária;
não use dados sensíveis em ferramentas de IA sem autorização.

Referências:

7. Arquitetura da informação

7.1 Objetivos

Ajudar o usuário a:

encontrar;
reconhecer;
compreender;
relacionar;
decidir;
retornar;
recuperar contexto.

7.2 Elementos

organização;
nomenclatura;
navegação;
busca;
filtros;
hierarquia;
metadados;
taxonomia.

7.3 Card sorting

Pode ser:

aberto;
fechado;
híbrido.

Ajuda a compreender agrupamentos percebidos, mas não define sozinho a arquitetura final.

7.4 Tree testing

Avalia se usuários encontram itens dentro de uma hierarquia sem influência visual.

7.5 Navegação

Critérios:

rótulos claros;
localização atual;
caminho de retorno;
consistência;
previsibilidade;
acesso às tarefas frequentes;
não depender somente de ícones;
busca quando volume justificar.

7.6 Filtros

Boas práticas:

mostrar filtros aplicados;
permitir limpar;
preservar estado quando útil;
informar quantidade;
evitar filtros sem efeito;
lidar com ausência de resultados;
oferecer ordenação separada;
usar valores compreensíveis.

8. Interação e usabilidade

8.1 Dez heurísticas de Nielsen

As heurísticas são princípios de diagnóstico, não leis matemáticas.

Visibilidade do estado do sistema
Correspondência com o mundo real
Controle e liberdade do usuário
Consistência e padrões
Prevenção de erros
Reconhecimento em vez de memorização
Flexibilidade e eficiência
Design estético e minimalista
Reconhecimento, diagnóstico e recuperação de erros
Ajuda e documentação

Referência:

Nielsen Norman Group — 10 Usability Heuristics

8.2 Princípios cognitivos úteis

Lei de Fitts

Alvos maiores e mais próximos tendem a ser mais fáceis de atingir.

Aplicação:

botões importantes com área clicável adequada;
ações frequentes próximas ao contexto;
não usar pequenos ícones como únicos alvos.

Lei de Hick

Mais opções e maior complexidade aumentam o esforço de decisão.

Aplicação:

agrupar;
priorizar;
usar divulgação progressiva;
evitar menus gigantes sem estrutura.

Gestalt

Princípios perceptivos:

proximidade;
similaridade;
continuidade;
fechamento;
figura e fundo;
região comum.

Carga cognitiva

Reduza esforço desnecessário:

reconhecibilidade;
padrões consistentes;
linguagem clara;
etapas visíveis;
valores padrão seguros;
memória externa.

Efeito de posição serial

Itens no início e no fim tendem a receber mais atenção, mas isso não garante compreensão.

8.3 Feedback

Toda ação relevante deve indicar:

recebimento;
processamento;
sucesso;
falha;
consequência;
próximo passo.

8.4 Confirmações

Use confirmação antes de:

exclusão irreversível;
publicação;
pagamento;
alteração crítica;
operação de alto impacto.

Evite confirmar ações triviais. Prefira “desfazer” quando tecnicamente seguro.

8.5 Atalhos

Para usuários frequentes:

teclado;
ações em lote;
favoritos;
preenchimento automático;
filtros salvos;
templates;
comandos rápidos.

9. Fundamentos visuais de UI

9.1 Hierarquia

A interface deve responder visualmente:

onde estou;
o que é mais importante;
o que posso fazer;
o que aconteceu;
qual é o próximo passo.

Ferramentas de hierarquia:

tamanho;
peso;
contraste;
posição;
espaçamento;
agrupamento;
cor;
densidade.

9.2 Layout

Prefira:

alinhamentos claros;
largura de leitura controlada;
grid coerente;
espaçamento sistemático;
áreas respirando conforme função;
agrupamento por significado.

Não distribua elementos apenas porque há espaço.

9.3 Espaçamento

Use escala limitada.

Exemplo:

4, 8, 12, 16, 24, 32, 48, 64

Não é obrigatório usar base 8. O importante é coerência e adequação.

9.4 Tipografia

Avalie:

legibilidade;
família;
peso;
tamanho;
altura de linha;
comprimento de linha;
contraste;
idioma;
números;
tabularidade;
renderização.

Para interfaces densas, diferenciação entre títulos, rótulos, valores e metadados precisa ser clara sem depender de dez tamanhos distintos.

9.5 Cor

Cor deve:

apoiar hierarquia;
representar estado;
comunicar marca;
manter contraste;
funcionar em diferentes temas;
não ser o único canal de informação.

Estados típicos:

informativo;
sucesso;
atenção;
erro;
neutro.

9.6 Ícones

Use ícones quando:

forem reconhecíveis;
houver espaço limitado;
acelerarem varredura;
vierem acompanhados de rótulo ou tooltip quando necessário.

Não invente ícones para conceitos abstratos quando texto é mais claro.

9.7 Movimento

Animação útil:

explica continuidade;
indica origem e destino;
orienta foco;
mostra mudança de estado;
reduz sensação de espera.

Animação ruim:

atrasa;
distrai;
causa náusea;
impede interação;
existe apenas para impressionar;
ignora prefers-reduced-motion.

9.8 Elevação e sombras

Use para indicar:

sobreposição;
camada;
relação espacial;
foco.

Não use sombra como decoração em todos os blocos.

9.9 Dark mode

Não é inversão automática de cores.

Exige:

tokens próprios;
contraste;
elevação adaptada;
imagens compatíveis;
estados;
gráficos;
testes em ambientes reais.

10. Responsividade e múltiplos dispositivos

10.1 Princípio

Responsividade é adaptação ao espaço e ao contexto, não apenas redução para celular.

Inclui:

largura;
altura;
orientação;
ponteiro;
densidade;
teclado;
toque;
zoom;
conteúdo;
conexão;
dispositivo.

10.2 Abordagem

comece pelo conteúdo e pela tarefa;
use layout fluido;
crie breakpoints quando o conteúdo pedir;
evite depender de modelos fixos de aparelho;
use media queries e container queries conforme necessidade;
teste com texto ampliado;
teste em largura estreita e extremamente larga.

10.3 Mobile first

É útil quando força prioridade e progressão.

Não significa desenhar somente para celular nem esticar depois.

10.4 Toque

alvos adequados;
espaçamento;
não depender de hover;
teclado correto para campos;
evitar gestos ocultos como única opção;
considerar uso com uma mão.

10.5 Desktop

Desktop permite mais espaço, mas isso não autoriza:

preencher tudo;
usar tabelas infinitas;
multiplicar painéis;
reduzir fonte;
esconder hierarquia.

Referências:

11. Acessibilidade digital

11.1 Princípio

Acessibilidade não é recurso extra. É requisito de qualidade e acesso.

Ela beneficia pessoas com:

deficiência visual;
baixa visão;
daltonismo;
deficiência auditiva;
deficiência motora;
deficiência cognitiva;
condições temporárias;
limitações situacionais;
envelhecimento;
dispositivos ou conexões restritas.

11.2 Referência principal

A referência internacional mais usada é a WCAG 2.2.

Princípios POUR:

Perceptível
Operável
Compreensível
Robusto

Referências:

11.3 HTML semântico primeiro

Antes de usar ARIA:

use button;
use input;
use label;
use fieldset e legend;
use títulos;
use tabelas corretamente;
use regiões semânticas.

Primeira regra prática de ARIA: não use ARIA para substituir um elemento nativo que já resolve.

Referência:

WAI-ARIA Authoring Practices

11.4 Teclado

Verifique:

ordem de foco;
foco visível;
acesso a tudo;
escape de diálogos;
ausência de armadilhas;
acionamento por teclado;
retorno de foco;
skip links;
atalhos não conflitantes.

11.5 Leitores de tela

Teste ao menos fluxos críticos com:

NVDA no Windows;
VoiceOver em macOS e iOS;
TalkBack no Android.

Ferramenta automática não verifica se a experiência “faz sentido”.

11.6 Contraste e cor

contraste suficiente;
não depender só de cor;
estados identificáveis;
gráficos com rótulos, padrões ou símbolos;
foco visível;
modo de alto contraste quando aplicável.

11.7 Zoom e reflow

Teste:

zoom de navegador;
aumento de texto;
largura estreita;
orientação;
conteúdo sem sobreposição;
controles sem corte.

11.8 Formulários acessíveis

rótulos persistentes;
instrução antes do erro;
erro associado ao campo;
resumo de erros quando necessário;
foco no erro;
identificação do formato;
não apagar conteúdo;
autocomplete semântico;
confirmação em operações críticas.

11.9 Ferramentas

Automatizadas:

axe;
Lighthouse;
Accessibility Insights;
WAVE;
lint de acessibilidade.

Manuais:

teclado;
leitor de tela;
zoom;
alto contraste;
redução de movimento;
usuários reais.

11.10 Critério mínimo recomendado

Para produtos profissionais, trate WCAG 2.2 nível AA como referência mínima, salvo exigência legal ou contratual mais rigorosa.

12. Conteúdo, microcopy e comunicação

12.1 Clareza antes de personalidade

Texto deve informar:

o que é;
o que aconteceu;
o que o usuário precisa fazer;
consequências;
alternativas;
como recuperar.

12.2 Botões

Ruim:

OK
Confirmar
Prosseguir

Melhor:

Salvar ordem
Enviar para aprovação
Excluir medidor
Gerar relatório

O rótulo deve refletir a ação.

12.3 Mensagens de erro

Estrutura útil:

o que ocorreu;
por que, se conhecido;
como corrigir;
como obter ajuda;
se dados foram preservados.

Exemplo:

Não foi possível salvar a ordem porque o ativo foi desativado. Selecione outro ativo ou reative-o antes de continuar. Os demais campos foram preservados.

12.4 Linguagem

use termos do usuário;
evite jargão interno;
mantenha consistência;
não culpe;
não infantilize;
seja específico;
revise números, unidades e datas;
defina abreviações.

12.5 Datas e números

Considere:

localidade;
fuso;
separador decimal;
moeda;
unidade;
precisão;
data absoluta e relativa;
ambiguidade.

Em contexto operacional, prefira:

1º de agosto de 2026, 14h32

em vez de apenas:

ontem às 14h32

quando a data for crítica.

13. Estados de interface

Cada componente ou fluxo deve considerar:

inicial;
vazio;
carregando;
carregamento parcial;
sucesso;
erro recuperável;
erro irrecuperável;
offline;
sem permissão;
expirado;
somente leitura;
desabilitado;
dados desatualizados;
conflito;
manutenção;
sem resultados.

13.1 Loading

evite spinner sem contexto;
informe o que está carregando;
preserve layout;
use skeleton com moderação;
ofereça cancelamento em operações longas;
não simule progresso falso;
permita continuar tarefas independentes.

13.2 Empty state

Diferencie:

ainda não há dados;
filtro não encontrou;
erro impediu carregar;
usuário não tem acesso;
recurso não configurado.

13.3 Erro

mensagem próxima do problema;
ação de recuperação;
identificador para suporte quando útil;
detalhes técnicos em área separada;
logging no sistema;
não expor stack trace ao usuário.

13.4 Conflito

Em edição concorrente:

informe que houve alteração;
compare versões quando possível;
evite sobrescrever silenciosamente;
permita recarregar, mesclar ou salvar cópia.

14. Formulários, tabelas e dashboards

14.1 Formulários

Princípios:

solicite somente o necessário;
agrupe por significado;
ordem natural;
valores padrão seguros;
formato indicado;
validação no momento adequado;
mensagens específicas;
preservação de dados;
etapas quando houver carga real;
revisão antes de ação crítica.

14.2 Validação

Imediata

Boa para:

formato;
disponibilidade;
força de senha;
limite;
correspondência.

No envio

Boa quando validação imediata interromperia ou geraria ruído.

No backend

Obrigatória para regras e segurança.

14.3 Tabelas

Use tabela para comparação precisa de dados.

Inclua quando necessário:

cabeçalhos;
ordenação;
filtros;
paginação;
densidade;
seleção;
ações;
estado;
exportação;
colunas configuráveis;
cabeçalho fixo;
resumo.

Evite transformar tabela em mosaico sem necessidade.

14.4 Dashboards

Um dashboard deve apoiar decisão, não provar que a equipe conhece gráficos.

Antes de criar um gráfico, responda:

quem decide;
qual decisão;
com que frequência;
qual comparação;
qual limiar;
qual ação;
qual confiabilidade do dado;
qual período;
qual origem;
qual atualização.

14.5 Escolha de visualização

Objetivo	Visualização inicial
comparar categorias	barras
evolução temporal	linha
composição	barras empilhadas ou tabela
distribuição	histograma ou box plot
correlação	dispersão
detalhe exato	tabela
progresso contra meta	barra, bullet chart
localização	mapa, apenas quando geografia importar

Evite:

pizza com muitas categorias;
3D;
dois eixos sem justificativa;
escalas truncadas sem sinalização;
excesso de cores;
animação que dificulta comparação;
ranking sem contexto;
KPI sem meta ou referência.

14.6 Dashboards industriais e de manutenção

Devem destacar:

condição atual;
risco;
tendência;
impacto;
prioridade;
responsável;
prazo;
ação;
confiabilidade da medição.

Não misture:

dado medido;
estimado;
calculado;
imputado;
indisponível.

Identifique cada natureza.

15. Arquitetura de frontend

15.1 Objetivo

Arquitetura deve tornar mudança segura, previsível e econômica.

Critérios:

clareza;
coesão;
baixo acoplamento;
testabilidade;
observabilidade;
segurança;
desempenho;
evolução incremental.

15.2 Organização por tipo técnico

components/
hooks/
services/
utils/
pages/

Simples, mas pode espalhar uma funcionalidade em muitas pastas.

15.3 Organização por funcionalidade

features/
  work-orders/
    components/
    api/
    model/
    tests/
  assets/
  inventory/
shared/

Costuma escalar melhor quando cada domínio tem regras próprias.

15.4 Arquitetura em camadas

Exemplo:

UI
↓
Aplicação
↓
Domínio
↓
Infraestrutura

Útil quando há regras complexas. Pode ser exagero em CRUD simples.

15.5 Monorepo

Benefícios:

compartilhamento;
mudanças atômicas;
padronização;
tooling unificado.

Riscos:

builds lentos;
dependência excessiva;
permissões;
governança;
complexidade de ferramentas.

15.6 Microfrontends

Use somente quando houver:

equipes independentes;
domínios claros;
implantação autônoma;
necessidade organizacional real.

Riscos:

duplicação;
inconsistência;
desempenho;
integração;
acessibilidade fragmentada;
debugging;
experiência incoerente.

Para equipes pequenas, frequentemente é um antipadrão.

16. Renderização: CSR, SSR, SSG, streaming e ilhas

16.1 CSR — Client-Side Rendering

O navegador recebe estrutura inicial e executa JavaScript para montar a aplicação.

Bom para:

aplicações internas;
interfaces altamente interativas;
áreas autenticadas.

Riscos:

carregamento inicial;
dependência de JS;
SEO;
erros no cliente;
complexidade de estado.

16.2 SSR — Server-Side Rendering

Servidor gera HTML por requisição.

Bom para:

conteúdo dinâmico;
SEO;
primeira renderização;
personalização controlada.

Riscos:

custo no servidor;
cache;
hidratação;
complexidade de dados.

16.3 SSG — Static Site Generation

HTML gerado no build.

Bom para:

documentação;
marketing;
conteúdo estável;
blogs;
páginas institucionais.

Riscos:

tempo de build;
atualização;
conteúdo muito dinâmico.

16.4 ISR ou regeneração incremental

Atualiza páginas estáticas sem rebuild total, conforme suporte do framework.

16.5 Streaming

Servidor entrega partes progressivamente.

Pode melhorar percepção, mas exige:

estados;
limites;
tratamento de erro;
arquitetura compatível.

16.6 Islands Architecture

A maior parte é HTML estático; regiões específicas tornam-se interativas.

Bom para:

sites de conteúdo;
baixa necessidade de JavaScript global;
desempenho.

16.7 Regra de decisão

Escolha pela natureza da página, não pela moda.

Um mesmo produto pode combinar estratégias.

17. Componentes, composição e organização do código

17.1 Bom componente

responsabilidade clara;
API pequena;
estados documentados;
acessível;
testável;
composável;
sem conhecimento desnecessário do restante do sistema.

17.2 Tamanho

Não existe número mágico de linhas.

Separe quando houver:

responsabilidades diferentes;
repetição;
comportamento independente;
teste isolável;
mudança frequente por motivos distintos.

17.3 Props

Evite:

dezenas de flags;
combinações impossíveis;
nomes vagos;
passagem excessiva;
objetos sem contrato.

Prefira composição e tipos discriminados quando necessário.

17.4 Componentes controlados e não controlados

Entenda quem possui o estado.

controlado: estado externo;
não controlado: estado interno ou DOM;
híbrido: requer contrato rigoroso.

17.5 Atomic Design

Brad Frost propôs:

atoms;
molecules;
organisms;
templates;
pages.

É um modelo mental útil para composição visual, mas não deve determinar sozinho a arquitetura do código ou do domínio.

Referência:

Atomic Design

18. Estado, dados e comunicação com APIs

18.1 Tipos de estado

Diferencie:

estado local de UI;
estado de formulário;
estado de URL;
estado de servidor;
estado global do cliente;
cache;
estado persistido;
estado da sessão.

Misturar tudo em um store global é antipadrão.

18.2 Estado de URL

Use para:

filtros compartilháveis;
paginação;
ordenação;
abas;
busca;
contexto navegável.

Benefícios:

refresh;
histórico;
links;
compartilhamento.

18.3 Estado de servidor

Inclui:

cache;
invalidação;
sincronização;
revalidação;
retry;
paginação;
mutações.

Ferramentas:

TanStack Query;
SWR;
Apollo Client, em GraphQL;
recursos do framework.

18.4 Estado global do cliente

Use quando o estado é realmente compartilhado e não pertence ao servidor ou à URL.

Ferramentas:

Redux Toolkit;
Zustand;
XState;
Pinia;
NgRx;
stores nativas dos frameworks.

18.5 Máquinas de estado

Úteis para fluxos com:

estados explícitos;
transições;
concorrência;
cancelamento;
aprovação;
etapas críticas;
dispositivos.

XState é referência conhecida, mas uma enumeração simples pode bastar.

18.6 Formulários

Ferramentas conhecidas:

React Hook Form;
Formik;
Angular Forms;
VeeValidate;
FormKit.

Validação:

Zod;
Valibot;
Yup;
ArkType;
JSON Schema.

18.7 Erros de API

Frontend deve diferenciar:

indisponibilidade;
timeout;
autorização;
validação;
conflito;
rate limit;
falha parcial;
resposta incompatível;
offline.

Não exiba “Erro 500” como única mensagem.

19. Frameworks e bibliotecas mais conhecidos

19.1 Comparativo resumido

Tecnologia	Natureza	Pontos fortes	Riscos	Bom uso
HTML/CSS/JS	plataforma	simplicidade, controle	disciplina manual	sites simples, widgets
React	biblioteca de UI	ecossistema, composição	decisões externas, complexidade	apps interativos
Next.js	framework React	full-stack, rotas, renderização	acoplamento e complexidade	produtos React web
Vue	framework progressivo	curva equilibrada	ecossistema menor que React	apps e sistemas
Nuxt	framework Vue	full-stack e renderização	abstrações	produtos Vue
Angular	framework completo	padrões, DI, tooling	curva e peso conceitual	grandes equipes corporativas
Svelte	compilador/framework UI	código conciso, reatividade	ecossistema menor	apps modernos
SvelteKit	framework Svelte	full-stack	maturidade relativa	produtos Svelte
Astro	framework de conteúdo	pouco JS, ilhas	não ideal para toda SPA	conteúdo e marketing
Web Components	padrão web	interoperabilidade	ergonomia e SSR variam	bibliotecas multiplataforma
Lit	biblioteca para Web Components	abstração leve	menor ecossistema	componentes reutilizáveis

19.2 React

React é biblioteca para construção de interfaces por componentes.

Use quando:

equipe domina;
ecossistema importa;
produto exige interação;
há necessidade de composição;
arquitetura será governada.

Não adote apenas por popularidade.

Referências:

19.3 Next.js

Framework React com:

roteamento;
renderização;
servidor;
otimizações;
integração full-stack.

Avalie:

modelo de hospedagem;
cache;
fronteira cliente-servidor;
dependência de convenções;
complexidade de atualização.

Referência:

Next.js Documentation

19.4 Vue

Framework progressivo baseado em HTML, CSS e JavaScript.

Pontos fortes:

templates familiares;
documentação;
composição;
adoção incremental.

Referências:

19.5 Angular

Framework completo com:

injeção de dependência;
roteamento;
forms;
HTTP;
tooling;
padrões organizacionais.

Pode ser vantajoso em organizações que precisam de convenções fortes. Pode ser excessivo para pequenos projetos.

Referência:

Angular

19.6 Svelte e SvelteKit

Svelte move trabalho para compilação e oferece sintaxe concisa.

Referências:

19.7 Astro

Focado em sites orientados a conteúdo e arquitetura de ilhas.

Referência:

Astro

19.8 Vite

Ferramenta de desenvolvimento e build amplamente usada.

Referência:

Vite

19.9 Critério real de escolha

Avalie:

competência da equipe;
longevidade;
manutenção;
contratação;
renderização;
acessibilidade;
ecossistema;
implantação;
desempenho;
licenciamento;
integração com backend;
custo de migração.

20. CSS, estilização e bibliotecas de interface

20.1 CSS nativo

Hoje oferece:

grid;
flexbox;
custom properties;
layers;
container queries;
nesting;
logical properties;
color functions;
media queries.

Aprender CSS é obrigatório mesmo usando biblioteca.

20.2 CSS Modules

Escopo local por arquivo.

Vantagens:

simples;
pouca abstração;
integração com componentes.

20.3 Sass

Ainda útil para:

funções;
mixins;
organização;
compatibilidade de bases antigas.

Muitos recursos históricos já existem no CSS nativo.

20.4 Tailwind CSS

Abordagem utility-first.

Vantagens:

velocidade;
consistência;
co-localização;
geração sob demanda;
ecossistema.

Riscos:

classes extensas;
dependência de convenções;
repetição sem abstração;
design genérico se usado sem sistema;
dificuldade para quem não domina CSS.

Referência:

Tailwind CSS

20.5 Bootstrap

Bom para:

protótipos;
sistemas internos;
equipes com baixa capacidade de design;
consistência rápida.

Riscos:

aparência genérica;
customização;
CSS legado;
componentes usados fora de contexto.

Referência:

Bootstrap

20.6 Bibliotecas de componentes completas

Material UI

ecossistema React;
muitos componentes;
tema;
acessibilidade variável por componente e uso.

Material UI

Ant Design

forte em sistemas corporativos;
componentes densos;
padrões de tabelas e formulários.

Ant Design

Chakra UI

componentes React;
ergonomia;
estilização por props.

Chakra UI

Mantine

conjunto amplo;
hooks;
componentes React.

Mantine

Fluent UI

ecossistema Microsoft;
integração com linguagem Fluent.

Fluent UI

20.7 Headless e primitives

Fornecem comportamento e acessibilidade com menor imposição visual.

Exemplos:

Radix UI;
React Aria;
Headless UI;
Ariakit;
Zag.js.

Vantagens:

controle visual;
base comportamental;
design system próprio.

Riscos:

exige competência de UI;
exige composição;
não elimina testes de acessibilidade.

Links:

20.8 shadcn/ui

Distribui componentes cujo código passa a fazer parte do projeto.

Vantagens:

propriedade do código;
customização;
boa base para IA e geração assistida;
integração com Tailwind e primitives.

Riscos:

você passa a manter o código;
atualizações não são automáticas;
cópia indiscriminada gera inconsistência;
aparência semelhante entre produtos sem direção visual.

Referência:

shadcn/ui

20.9 Critério para escolher biblioteca

Verifique:

acessibilidade;
componentes necessários;
manutenção;
documentação;
atualização;
bundle;
tema;
TypeScript;
SSR;
licenciamento;
testes;
comunidade;
internacionalização;
compatibilidade;
autonomia futura.

21. Design systems

21.1 Componentes de um design system

Fundamentos

princípios;
marca;
cor;
tipografia;
espaçamento;
grid;
iconografia;
movimento;
acessibilidade.

Tokens

Representam decisões:

{
  "color.status.critical.background": "#...",
  "space.300": "12px",
  "radius.control": "6px"
}

Tokens não devem ser apenas nomes como blue500 quando a intenção semântica importa.

Componentes

botão;
campo;
modal;
tabela;
alerta;
navegação;
tooltip;
tabs;
select;
date picker.

Padrões

confirmação;
busca;
filtros;
formulários;
empty states;
erros;
aprovação;
onboarding;
notificações.

Governança

responsável;
contribuição;
revisão;
versionamento;
depreciação;
suporte;
roadmap;
métricas.

21.2 Maturidade

estilos dispersos;
inventário;
tokens;
biblioteca;
documentação;
governança;
adoção;
métricas;
evolução multiplataforma.

21.3 Quando criar

Crie quando houver:

repetição;
múltiplas equipes;
inconsistência;
necessidade de velocidade;
produto duradouro;
governança possível.

Não crie uma plataforma inteira para um site temporário de cinco páginas.

21.4 Exemplos oficiais

21.5 Ferramentas

Figma Libraries;
Tokens Studio;
Style Dictionary;
Storybook;
Chromatic;
Zeroheight;
Backlight;
documentação própria;
linters internos.

21.6 Métricas

taxa de adoção;
duplicação;
tempo para entregar;
defeitos;
acessibilidade;
inconsistências;
satisfação da equipe;
quantidade de exceções;
tempo para atualização.

22. Ferramentas de design e desenvolvimento

22.1 Design

Figma

interface;
componentes;
protótipos;
bibliotecas;
colaboração;
handoff.

Figma

Penpot

Alternativa open source orientada à web.

Penpot

FigJam e Miro

workshops;
mapas;
fluxos;
colaboração.

22.2 Pesquisa

Dovetail;
Condens;
EnjoyHQ;
UserTesting;
Lookback;
Maze;
Optimal Workshop;
Lyssna.

Avalie privacidade, localização dos dados, consentimento e custo.

22.3 Analytics

Google Analytics;
Matomo;
Plausible;
Amplitude;
Mixpanel;
PostHog;
Microsoft Clarity;
Hotjar.

Não instale tudo. Cada script acrescenta custo, risco e governança.

22.4 Desenvolvimento

VS Code;
WebStorm;
Chrome DevTools;
Firefox Developer Tools;
Git;
GitHub;
GitLab;
Bitbucket;
Node.js;
npm;
pnpm;
Yarn;
Bun;
Vite;
ESLint;
Prettier;
Stylelint.

22.5 Documentação de componentes

Storybook;
Ladle;
Histoire;
documentação do framework.

22.6 Prototipação em código

CodePen;
StackBlitz;
CodeSandbox;
GitHub Codespaces;
protótipo local.

22.7 Design-to-code

Ferramentas podem acelerar estrutura, mas não compreendem automaticamente:

regras;
estados;
acessibilidade real;
arquitetura;
dados;
segurança;
manutenção.

Trate saída como rascunho revisável.

23. Testes de frontend

23.1 Estratégia por risco

Teste mais onde há:

impacto financeiro;
segurança;
continuidade;
frequência;
complexidade;
histórico de falha;
regras críticas.

23.2 Tipos

Teste unitário

Funções e regras isoladas.

Teste de componente

Componente renderizado com interação.

Teste de integração

Partes colaborando.

End-to-end

Fluxo completo em ambiente semelhante ao real.

Visual regression

Comparação de renderização.

Acessibilidade

Automatizada e manual.

Performance

Métricas de laboratório e reais.

Contrato

Compatibilidade entre frontend e API.

23.3 Ferramentas

Vitest;
Jest;
Testing Library;
Playwright;
Cypress;
Storybook Test;
axe-core;
Chromatic;
Percy;
Pact;
Mock Service Worker.

23.4 Testing Library

Princípio central: testar como o usuário interage.

Prefira seletores por:

role;
nome acessível;
label;
texto.

Evite selecionar pela estrutura interna quando não necessário.

Referência:

Testing Library

23.5 Playwright

Bom para:

múltiplos navegadores;
E2E;
screenshots;
componentes;
acessibilidade integrada com axe;
isolamento.

Referência:

Playwright

23.6 Storybook

Bom para:

estados;
documentação;
desenvolvimento isolado;
teste visual;
interação;
acessibilidade.

Referência:

Storybook

23.7 O que testar primeiro

login e autorização;
criação e edição;
operações críticas;
erros;
permissões;
dados inválidos;
navegação;
acessibilidade;
desempenho;
compatibilidade.

23.8 Antipadrões

cobertura percentual como objetivo isolado;
snapshots gigantes;
mocks que não representam a API;
E2E para tudo;
teste acoplado à implementação;
ignorar falhas intermitentes;
testes sem valor de negócio.

24. Desempenho e Core Web Vitals

24.1 Desempenho é UX

Uma interface lenta altera:

compreensão;
confiança;
taxa de conclusão;
percepção de qualidade;
acessibilidade;
custo operacional.

24.2 Core Web Vitals

Métricas centrais:

LCP: carregamento do maior conteúdo principal;
INP: responsividade às interações;
CLS: estabilidade visual.

Referência:

web.dev — Web Vitals

24.3 Laboratório e campo

Laboratório

Ambiente controlado:

Lighthouse;
WebPageTest;
DevTools;
testes em CI.

Campo

Usuários reais:

CrUX;
RUM próprio;
observabilidade.

Você precisa dos dois.

24.4 Orçamento de performance

Defina limites para:

JavaScript;
CSS;
imagens;
fontes;
requisições;
tempo de interação;
memória;
tarefas longas.

24.5 Imagens

dimensões corretas;
formatos modernos;
compressão;
srcset;
lazy loading quando apropriado;
prioridade no conteúdo principal;
largura e altura para evitar layout shift;
alt text.

24.6 Fontes

reduzir variantes;
subset;
preload apenas quando necessário;
font-display;
fallback compatível;
evitar bloquear renderização.

24.7 JavaScript

remover dependências;
code splitting;
lazy loading;
tree shaking;
evitar hidratação desnecessária;
web workers para CPU pesada;
reduzir tarefas longas;
monitorar bundle.

24.8 Ferramentas

Lighthouse;
PageSpeed Insights;
WebPageTest;
Chrome Performance;
Coverage;
Bundle Analyzer;
Source Map Explorer;
React Profiler;
framework devtools.

25. Segurança e privacidade

25.1 Regra principal

Frontend é ambiente não confiável.

Tudo enviado ao navegador pode ser:

visto;
alterado;
copiado;
automatizado;
interceptado em dispositivo comprometido.

25.2 XSS

Mitigações:

escape;
evitar HTML não confiável;
sanitização;
CSP;
templates seguros;
revisão de URLs;
não usar eval;
dependências atualizadas.

25.3 CSP

Content Security Policy reduz impacto de injeções, mas é defesa em profundidade, não substituto de correção.

Referência:

OWASP Content Security Policy Cheat Sheet

25.4 CSRF

Risco quando navegador envia credenciais automaticamente.

Mitigações:

SameSite;
tokens;
validação de origem;
métodos corretos;
frameworks;
arquitetura de autenticação.

25.5 CORS

CORS controla quais origens podem ler respostas no navegador.

Não é mecanismo de autenticação nem proteção geral da API.

25.6 Tokens e cookies

Cookies HttpOnly

Benefícios:

JavaScript não lê;
integração com sessão.

Exigem atenção a CSRF, SameSite e domínio.

Tokens em storage

Risco maior em caso de XSS.

Não existe solução universal. Avalie modelo de ameaça.

25.7 Segredos

Nunca coloque no frontend:

chave privada;
senha;
segredo OAuth;
chave de provedor de IA;
credencial de banco;
token administrativo.

Variáveis de ambiente incorporadas no bundle continuam públicas.

25.8 Dependências

minimize;
trave versões;
audite;
revise mantenedores;
monitore advisories;
gere SBOM quando necessário;
evite pacotes triviais;
verifique licenças;
proteja pipeline.

25.9 Privacidade

minimização;
finalidade;
consentimento;
retenção;
anonimização;
acesso;
transferência;
exclusão;
LGPD;
segurança por padrão.

25.10 Referências

26. SEO, internacionalização, PWA e offline

26.1 SEO técnico

HTML semântico;
títulos;
metadados;
links;
canonical;
sitemap;
robots;
dados estruturados;
desempenho;
renderização;
status HTTP;
conteúdo útil.

Referência:

Google Search Central

26.2 Internacionalização

I18n envolve:

textos externalizados;
pluralização;
datas;
moeda;
números;
direção;
fuso;
layout;
idioma;
ordenação;
collation.

Não concatene frases traduzidas.

Referência:

W3C Internationalization

26.3 PWA

Pode oferecer:

instalação;
cache;
offline;
notificações;
integração com dispositivo.

Não transforme todo site em PWA sem necessidade.

Referência:

web.dev Progressive Web Apps

26.4 Offline

Defina:

o que funciona;
o que é somente leitura;
fila de sincronização;
conflitos;
indicação de estado;
retries;
armazenamento;
segurança;
expiração.

Offline “parcial e honesto” é melhor que falsa disponibilidade.

27. Observabilidade, analytics e experimentação

27.1 Observabilidade do frontend

Colete:

erros;
stack traces;
versão;
navegador;
rota;
correlação com backend;
performance;
falhas de API;
sessões afetadas;
breadcrumbs com privacidade.

Ferramentas:

Sentry;
Datadog RUM;
New Relic Browser;
OpenTelemetry;
Elastic;
Grafana Faro.

27.2 Analytics de produto

Eventos devem representar comportamento relevante.

Exemplo:

work_order_created
work_order_submission_failed
asset_filter_applied
energy_anomaly_reviewed

Inclua:

nome;
definição;
propriedades;
responsável;
finalidade;
retenção;
versão.

27.3 Métricas

Métricas de resultado

redução de tempo;
redução de erro;
menor indisponibilidade;
maior conclusão;
economia;
segurança.

Métricas de produto

ativação;
retenção;
uso de recurso;
funil;
satisfação;
qualidade.

Métricas de saúde técnica

erros;
latência;
vitals;
disponibilidade;
falhas de deploy.

27.4 Teste A/B

Use quando:

hipótese é mensurável;
volume é suficiente;
risco é aceitável;
grupos são comparáveis;
métrica não incentiva dano.

Não teste eticamente o que já se sabe ser prejudicial.

28. IA aplicada a frontend, UI e UX

28.1 Usos legítimos

gerar rascunhos;
explorar alternativas;
criar dados sintéticos;
revisar código;
produzir testes;
resumir pesquisa;
classificar feedback;
explicar erros;
acelerar documentação;
prototipar;
apoiar acessibilidade;
gerar conteúdo inicial.

28.2 O que IA não garante

correção;
segurança;
acessibilidade;
aderência ao negócio;
licença;
originalidade;
desempenho;
manutenção;
ausência de viés;
conformidade.

28.3 Fluxo recomendado

Objetivo e restrições
→ contexto
→ geração
→ revisão humana
→ testes
→ validação com usuários
→ métricas
→ correção

28.4 Prompt para geração de interface

Inclua:

usuário;
tarefa;
dispositivo;
dados;
estados;
acessibilidade;
design system;
limitações;
critérios de aceite;
comportamento;
erros;
performance;
segurança.

28.5 UX de produtos com IA

A interface deve comunicar:

que é IA;
o que pode fazer;
limites;
origem dos dados;
quando está processando;
possibilidade de cancelar;
como corrigir;
incerteza;
fontes, quando aplicável;
impacto da ação;
uso dos dados.

28.6 Streaming

Ao transmitir resposta:

preserve estabilidade;
permita interromper;
indique geração;
trate falha parcial;
não esconda que conteúdo está incompleto;
permita copiar;
não reposicione a página agressivamente.

28.7 Confiança

Evite:

antropomorfismo enganoso;
certeza visual sem fundamento;
citações inexistentes;
ações irreversíveis automáticas;
ocultação do modelo;
termos vagos como “verificado” sem processo real.

28.8 Avaliação

Avalie:

qualidade;
precisão;
completude;
segurança;
latência;
custo;
recusa;
consistência;
impacto no usuário;
regressões.

Crie conjuntos de casos reais e extremos.

28.9 Segurança de IA

Riscos:

prompt injection;
vazamento;
ferramentas indevidas;
exfiltração;
conteúdo inseguro;
ações não autorizadas;
dependência excessiva;
dados sensíveis;
supply chain de modelos.

28.10 Arquitetura segura

Frontend
↓
Seu backend
↓
Políticas, autenticação, rate limit, logs
↓
API do provedor de IA

Não coloque a chave secreta do provedor no navegador.

O backend deve:

guardar credenciais;
limitar uso;
autorizar;
validar entrada e saída;
aplicar políticas;
registrar eventos;
controlar ferramentas;
ocultar dados desnecessários.

28.11 Ferramentas para desenvolvimento com IA

OpenAI Codex;
GitHub Copilot;
Claude Code;
Gemini Code Assist;
Cursor;
Windsurf;
JetBrains AI;
Vercel v0;
Figma AI;
Storybook e geradores;
agentes internos.

Use como aceleradores, não como autoridade.

29. Sites oficiais de desenvolvedores de IA

29.1 Provedores e plataformas

Plataforma	Documentação oficial	Uso típico
OpenAI	https://developers.openai.com/api/docs	modelos, ferramentas, agentes, multimodal
OpenAI Codex	https://developers.openai.com/codex	desenvolvimento assistido e agentes de código
Anthropic	https://docs.anthropic.com/	Claude API e ferramentas
Google Gemini	https://ai.google.dev/	Gemini API
Google AI Studio	https://aistudio.google.com/	prototipação e chaves Gemini
Microsoft Foundry	https://learn.microsoft.com/azure/ai-foundry/	plataforma corporativa de IA
AWS Bedrock	https://docs.aws.amazon.com/bedrock/	modelos gerenciados na AWS
Mistral AI	https://docs.mistral.ai/	modelos e API
Cohere	https://docs.cohere.com/	geração, embeddings e rerank
Hugging Face	https://huggingface.co/docs	modelos, datasets e inferência
xAI	https://docs.x.ai/	Grok API
NVIDIA NIM	https://docs.nvidia.com/nim/	microsserviços de inferência
Meta Llama	https://www.llama.com/docs/	modelos Llama
Groq	https://console.groq.com/docs/	inferência de baixa latência
Together AI	https://docs.together.ai/	inferência e fine-tuning
Replicate	https://replicate.com/docs	execução de modelos
Stability AI	https://platform.stability.ai/docs	geração de imagem
ElevenLabs	https://elevenlabs.io/docs	voz
Deepgram	https://developers.deepgram.com/	fala e áudio

29.2 SDKs e frameworks

Projeto	Documentação
Vercel AI SDK	https://ai-sdk.dev/
LangChain	https://docs.langchain.com/
LangGraph	https://langchain-ai.github.io/langgraph/
LlamaIndex	https://docs.llamaindex.ai/
Semantic Kernel	https://learn.microsoft.com/semantic-kernel/
Haystack	https://docs.haystack.deepset.ai/
Model Context Protocol	https://modelcontextprotocol.io/
OpenTelemetry	https://opentelemetry.io/docs/

29.3 Regras ao consultar documentação de IA

Verifique:

data;
versão do modelo;
endpoint;
depreciação;
preço;
limites;
região;
retenção;
privacidade;
segurança;
compatibilidade do SDK.

Tutoriais de seis meses atrás podem estar tecnicamente desatualizados.

30. Personalidades e autores influentes

30.1 UX, HCI e design

Don Norman

Contribuições:

design centrado no humano;
affordances;
signifiers;
modelos conceituais;
erros humanos como problema de sistema.

Obra:

The Design of Everyday Things

Jakob Nielsen

Contribuições:

heurísticas;
usabilidade;
pesquisa aplicada;
leitura na web.

Rolf Molich

Coautor do trabalho inicial das heurísticas de usabilidade.

Alan Cooper

Contribuições:

interaction design;
personas;
goal-directed design.

Steve Krug

Obra prática sobre usabilidade:

Don't Make Me Think

Jesse James Garrett

Estruturou os elementos da experiência do usuário.

Peter Morville e Louis Rosenfeld

Influentes em arquitetura da informação.

Indi Young

Pesquisa sobre modelos mentais e compreensão profunda.

Erika Hall

Pesquisa enxuta e crítica a processos superficiais.

Jared Spool

Usabilidade, estratégia e experiência.

Luke Wroblewski

Mobile first, formulários e produto.

Brenda Laurel

Interação humano-computador e design de experiência.

Ben Shneiderman

Princípios de interação e HCI.

30.2 Web, CSS e acessibilidade

Tim Berners-Lee

Criador da Web.

Håkon Wium Lie

Cocriador do CSS.

Jeffrey Zeldman

Web standards e A List Apart.

Ethan Marcotte

Popularizou responsive web design.

Rachel Andrew

CSS Grid, layout e padrões web.

Jen Simmons

CSS, layout e padrões.

Lea Verou

CSS, APIs web e educação técnica.

Sara Soueidan

Acessibilidade, SVG e frontend.

Heydon Pickering

Acessibilidade e inclusive design.

Eric Meyer

CSS e padrões web.

Jeremy Keith

Progressive enhancement e web resiliente.

30.3 Arquitetura, performance e testes

Martin Fowler

Arquitetura, refatoração e padrões.

Addy Osmani

Performance web e engenharia frontend.

Kent C. Dodds

Testes e ecossistema React.

Brad Frost

Atomic Design e design systems.

Nicole Sullivan

Object-Oriented CSS e escalabilidade.

Harry Roberts

Arquitetura CSS e performance.

30.4 Frameworks

Dan Abramov

Contribuições no ecossistema React e educação.

Evan You

Criador do Vue e Vite.

Rich Harris

Criador do Svelte.

Misko Hevery

Criador do AngularJS e Qwik.

Ryan Dahl

Criador do Node.js e Deno.

30.5 Observação crítica

Não trate influenciadores como fonte normativa.

Prioridade:

padrão oficial;
documentação;
evidência;
experiência replicável;
opinião.

31. Livros, artigos, padrões e estudos

31.1 UX e interação

Don Norman — The Design of Everyday Things
Steve Krug — Don't Make Me Think
Alan Cooper et al. — About Face
Jesse James Garrett — The Elements of User Experience
Rosenfeld, Morville e Arango — Information Architecture
Erika Hall — Just Enough Research
Indi Young — Mental Models
Kim Goodwin — Designing for the Digital Age
Jeff Johnson — Designing with the Mind in Mind
Luke Wroblewski — Web Form Design
Steve Portigal — Interviewing Users

31.2 UI e sistemas

Jenifer Tidwell et al. — Designing Interfaces
Alla Kholmatova — Design Systems
Brad Frost — Atomic Design
Nathan Curtis — artigos sobre design systems
Adam Wathan e Steve Schoger — Refactoring UI

Nota: Refactoring UI é prático e influente, mas é uma abordagem visual opinativa, não norma científica.

31.3 Frontend e web

Jeremy Keith — Resilient Web Design
Marijn Haverbeke — Eloquent JavaScript
Kyle Simpson — You Don't Know JS Yet
Eric Elliott — textos sobre JavaScript, com leitura crítica
MDN Learn Web Development
web.dev Learn

31.4 Acessibilidade

WCAG 2.2
WAI-ARIA Authoring Practices
Inclusive Components — Heydon Pickering
A Web for Everyone — Sarah Horton e Whitney Quesenbery
Accessibility for Everyone — Laura Kalbag

31.5 Arquitetura e qualidade

Martin Fowler — Refactoring
Robert C. Martin — Clean Code, com leitura crítica e contextual
Michael Feathers — Working Effectively with Legacy Code
Sam Newman — Building Microservices, apenas quando o problema justificar
Eric Evans — Domain-Driven Design
John Ousterhout — A Philosophy of Software Design

31.6 Padrões oficiais

31.7 Estudos e bases

ACM Digital Library
IEEE Xplore
Google Scholar
arXiv, com revisão crítica
Nielsen Norman Group
Baymard Institute
MeasuringU
CHI Conference
UXPA
Human Factors and Ergonomics Society

32. Fóruns, comunidades e fontes de atualização

32.1 Fontes técnicas

32.2 Perguntas e problemas

Stack Overflow
GitHub Issues
GitHub Discussions
repositórios oficiais
fóruns dos frameworks
Discord oficial dos projetos.

32.3 Prática

32.4 Notícias e discussão

Hacker News;
DEV Community;
Reddit;
newsletters;
Mastodon;
Bluesky;
LinkedIn.

Use como radar, não como prova.

32.5 UX

Nielsen Norman Group;
UX Collective;
UXPA;
IxDA;
Interaction Design Foundation;
Baymard;
MeasuringU;
Rosenfeld Media;
GOV.UK Service Manual.

32.6 Segurança

OWASP;
PortSwigger Web Security Academy;
Snyk;
GitHub Security Advisories;
NIST;
CISA.

33. Como avaliar a confiabilidade de uma fonte

33.1 Hierarquia recomendada

especificação ou norma;
documentação oficial;
artigo científico revisado;
guia institucional;
documentação de biblioteca;
livro técnico reconhecido;
estudo de caso;
artigo de especialista;
fórum;
vídeo curto ou postagem.

33.2 Perguntas

quem publicou?
há conflito de interesse?
qual data?
qual versão?
há método?
há amostra?
há limitações?
é reproduzível?
é aplicável ao seu contexto?
outras fontes confirmam?
o autor diferencia opinião e evidência?

33.3 Red flags

“a única stack correta”;
“esta regra aumenta conversão em X%” sem fonte;
“usuários sempre fazem”;
benchmark sem cenário;
pesquisa sem amostra;
comparação patrocinada ocultamente;
tutorial que pede segredo no frontend;
biblioteca recomendada sem verificar manutenção;
mockup tratado como produto.

34. Matrizes para escolha de tecnologias

34.1 Framework

Pontue de 1 a 5:

Critério	Peso sugerido
domínio da equipe	5
manutenção	5
acessibilidade	5
aderência ao produto	5
ecossistema	4
desempenho	4
contratação	3
SSR/SEO	conforme projeto
integração com backend	4
estabilidade	4
migração	3
custo de infraestrutura	3

Não some mecanicamente sem discutir riscos eliminatórios.

34.2 Biblioteca de componentes

Pergunta	Evidência
teclado funciona?	teste manual
leitor de tela funciona?	teste
componentes necessários existem?	inventário
tema é flexível?	protótipo
bundle é aceitável?	medição
SSR funciona?	prova
manutenção está ativa?	releases
licença permite?	licença
equipe consegue modificar?	spike
estados são completos?	storybook

34.3 Build versus buy

Construir

Quando:

experiência é diferencial;
requisitos específicos;
equipe competente;
governança disponível.

Comprar ou adotar

Quando:

problema comum;
velocidade;
menor equipe;
acessibilidade já trabalhada;
custo de manutenção interno alto.

34.4 React versus páginas no servidor

Use páginas no servidor quando:

CRUD;
fluxo simples;
pouca interação;
equipe Java;
menor complexidade;
implantação central.

Use SPA quando:

interações ricas;
estado complexo;
colaboração;
edição intensa;
experiência semelhante a aplicativo.

35. Arquiteturas recomendadas por tipo de projeto

35.1 Site institucional

Astro ou framework com SSG
HTML semântico
CSS
JavaScript mínimo
CMS opcional

35.2 Sistema interno simples

Spring Boot
Thymeleaf
HTML
CSS
JavaScript progressivo
PostgreSQL

35.3 Sistema corporativo interativo

React ou Vue + TypeScript
Backend Java/Spring Boot
API REST
PostgreSQL
OIDC/SSO
Observabilidade

35.4 Dashboard analítico

Frontend tipado
API/BFF
Camada semântica de dados
Cache
Biblioteca de visualização
Exportação
Rastreabilidade

35.5 Produto público de conteúdo

SSR/SSG
CMS
SEO
Core Web Vitals
Acessibilidade
Analytics mínimo

35.6 Aplicação industrial local

Possibilidades:

aplicação web local;
PWA;
desktop;
painel dedicado.

Critérios:

offline;
rede;
hardware;
latência;
segurança;
atualização;
continuidade;
integração com dispositivos.

36. Recomendação para sistemas corporativos com Java

36.1 Opção A — Simples e robusta

Spring Boot
Spring MVC
Thymeleaf
HTML semântico
CSS
JavaScript modular
PostgreSQL

Use para:

cadastro;
aprovação;
ordens;
relatórios;
gestão;
formulários;
portais internos.

Benefícios:

uma implantação principal;
menor complexidade;
equipe Java;
segurança central;
HTML inicial;
evolução progressiva.

36.2 Opção B — Interface rica

React ou Vue
TypeScript
Vite ou framework full-stack adequado
API Java Spring Boot
PostgreSQL

Use para:

dashboards interativos;
drag-and-drop;
colaboração;
atualização em tempo real;
muitos estados;
mobile web sofisticado.

36.3 Opção C — Híbrida

Páginas do servidor com componentes interativos isolados.

Pode usar:

Web Components;
React em ilhas;
Vue em ilhas;
HTMX;
Alpine.js.

Boa opção quando 80% é CRUD e 20% exige interação.

36.4 O que não recomendo inicialmente

microsserviços;
microfrontends;
Kubernetes;
GraphQL sem necessidade;
event sourcing;
design system corporativo completo;
cinco stores;
abstração genérica para tudo.

37. Projeto prático: sistema de manutenção

37.1 Usuários

eletricista;
técnico;
supervisor;
planejador;
gestor;
almoxarife;
auditor.

37.2 Módulos

ativos;
ordens de serviço;
inspeções;
planos preventivos;
estoque;
falhas;
indicadores;
anexos;
aprovações;
auditoria.

37.3 Fluxo de ordem

Solicitada
→ Triada
→ Planejada
→ Programada
→ Em execução
→ Aguardando material
→ Aguardando liberação
→ Concluída
→ Validada
→ Encerrada

Estados precisam de regras de transição.

37.4 Tela de lista

busca;
filtros;
status;
criticidade;
ativo;
responsável;
prazo;
atraso;
ações em lote;
exportação;
filtros salvos.

37.5 Tela de detalhe

identificação;
condição;
risco;
descrição;
fotos;
medidas;
causa;
ação;
peças;
horas;
responsável;
timeline;
auditoria.

37.6 Dashboard

Perguntas:

quais ativos concentram falhas?
quais ordens críticas estão atrasadas?
qual backlog por especialidade?
qual reincidência?
qual MTTR?
qual indisponibilidade?
qual custo?
quais dados estão incompletos?

37.7 Critérios de aceite

tarefa principal concluída;
teclado;
leitor de tela;
mobile;
erro preserva dados;
regras no backend;
auditoria;
testes;
performance;
segurança;
logs;
rollback.

37.8 Arquitetura sugerida

Frontend React ou Vue
  ├─ UI
  ├─ features
  ├─ API client
  ├─ estado de servidor
  └─ testes

Backend Spring Boot
  ├─ autenticação
  ├─ autorização
  ├─ domínio
  ├─ aplicação
  ├─ persistência
  └─ integrações

PostgreSQL
Object storage
Observabilidade

Para primeira versão, Thymeleaf pode ser mais econômico.

38. Trilha de estudo progressiva

Fase 1 — Fundamentos web

Estude:

HTML semântico;
CSS;
JavaScript;
DevTools;
Git;
HTTP.

Projeto:

página de ativo com formulário e tabela.

Critério:

implementar sem framework;
explicar cada camada;
operar por teclado.

Fase 2 — UI e UX

Estude:

hierarquia;
tipografia;
cor;
espaçamento;
heurísticas;
pesquisa;
fluxo;
conteúdo;
acessibilidade.

Projeto:

redesenhar abertura de OS;
testar com 3 a 5 usuários por ciclo, conforme viabilidade;
registrar problemas.

Fase 3 — TypeScript e APIs

Estude:

tipos;
fetch;
JSON;
erros;
async;
validação.

Projeto:

consumir API simulada;
tratar loading, vazio e erro.

Fase 4 — Framework

Escolha um:

React;
Vue.

Estude:

componentes;
props;
estado;
eventos;
efeitos;
roteamento;
forms.

Projeto:

CRUD de ativos.

Fase 5 — Dados e formulários

TanStack Query ou equivalente;
React Hook Form ou equivalente;
Zod;
paginação;
filtros;
cache.

Fase 6 — Testes

unitários;
componentes;
E2E;
acessibilidade;
visual.

Fase 7 — Performance e segurança

Core Web Vitals;
bundle;
XSS;
CSRF;
CSP;
autenticação;
segredos.

Fase 8 — Design system

tokens;
Storybook;
componentes;
documentação;
versionamento.

Fase 9 — Backend Java

Spring Boot;
API;
validação;
segurança;
JPA;
PostgreSQL;
testes.

Fase 10 — IA

API segura;
streaming;
avaliação;
ferramentas;
guardrails;
observabilidade.

Indicadores de aprendizado

horas líquidas;
exercícios;
bugs resolvidos;
testes;
projetos;
capacidade de explicar;
alteração sem IA;
revisão de código gerado;
documentação;
acessibilidade.

39. Checklists operacionais

39.1 Descoberta

problema descrito
usuário identificado
tarefa observada
risco mapeado
regra de negócio registrada
dados disponíveis
restrições conhecidas
métrica definida
fora de escopo

39.2 UX

fluxo principal
fluxos alternativos
erros
permissões
estados vazios
loading
conteúdo
teste com usuários
achados priorizados

39.3 UI

hierarquia
grid
espaçamento
tipografia
contraste
ícones
estados
responsividade
tema
densidade

39.4 Acessibilidade

HTML semântico
teclado
foco
labels
nomes acessíveis
contraste
zoom
leitor de tela
redução de movimento
erros
teste automático
teste manual

39.5 Desenvolvimento

tipos
arquitetura
regras no backend
erros tratados
logs
testes
lint
build
dependências
documentação

39.6 Performance

LCP
INP
CLS
imagens
fontes
bundle
cache
requisições
dispositivo lento
dados de campo

39.7 Segurança

segredo fora do cliente
autorização no backend
XSS
CSRF
CORS
CSP
cookies/tokens
rate limit
dependências
privacidade
auditoria

39.8 Pré-lançamento

critérios aceitos
fluxos críticos
rollback
observabilidade
suporte
treinamento
migração
acessibilidade
segurança
desempenho
compatibilidade
documentação

39.9 IA

chave no backend
dados minimizados
prompt injection
ferramentas autorizadas
timeout
cancelamento
limite de custo
avaliação
conteúdo inseguro
auditoria
revisão humana
fallback

40. Antipadrões frequentes

40.1 “Página moderna”

Pedido sem:

objetivo;
usuário;
conteúdo;
tarefa;
métrica.

40.2 Copiar Dribbble

Dribbble é inspiração visual. Não comprova:

usabilidade;
responsividade;
acessibilidade;
dados;
estados;
implementação.

40.3 Dashboard decorativo

muitos cards;
donuts;
gradientes;
sem meta;
sem ação;
sem fonte;
sem período;
sem confiabilidade.

40.4 Framework por currículo

Escolher tecnologia para parecer moderno.

40.5 Tudo global

Store global para campos locais.

40.6 Design system prematuro

Construir plataforma antes de validar produto.

40.7 Acessibilidade por plugin

Overlay não corrige arquitetura, conteúdo e semântica.

40.8 IA sem validação

Código gerado indo direto à produção.

40.9 Segredo no frontend

Grave e explorável.

40.10 Mobile como versão menor

Comprimir desktop em celular.

40.11 Ícone sem rótulo

Usuário precisa adivinhar.

40.12 Dark pattern

confirmação enganosa;
cancelamento escondido;
culpa;
urgência falsa;
opt-in pré-selecionado;
custo oculto.

40.13 Erro genérico

“Algo deu errado” sem recuperação.

40.14 Carregamento infinito

Sem timeout, cancelamento ou diagnóstico.

40.15 Microfrontend sem organização

Complexidade técnica tentando resolver conflito de gestão.

41. Glossário

API: contrato para comunicação entre sistemas.
ARIA: atributos para acessibilidade de interfaces web.
BFF: backend específico para necessidades de uma interface.
Bundle: arquivos processados distribuídos ao navegador.
Cache: armazenamento temporário para evitar trabalho repetido.
CLS: métrica de estabilidade visual.
Component: unidade reutilizável de interface.
CORS: política do navegador para leitura entre origens.
CSP: política de restrição de conteúdo.
CSR: renderização no cliente.
Design token: valor nomeado que representa decisão de design.
DOM: representação do documento no navegador.
E2E: teste de ponta a ponta.
Hydration: associação de JavaScript a HTML renderizado.
INP: métrica de responsividade à interação.
LCP: métrica de carregamento principal.
Microcopy: pequenos textos operacionais da interface.
PWA: aplicação web com capacidades adicionais.
RUM: medição com usuários reais.
SEO: otimização para mecanismos de busca.
SPA: aplicação de página única.
SSG: geração estática.
SSR: renderização no servidor.
Tree shaking: remoção de código não utilizado no build.
UI: interface do usuário.
UX: experiência do usuário.
WCAG: diretrizes de acessibilidade de conteúdo web.
Web Component: padrão de componente reutilizável do navegador.
XSS: injeção de script em conteúdo confiável.

42. Diretório de referências oficiais

Plataforma web

MDN: https://developer.mozilla.org/
WHATWG HTML: https://html.spec.whatwg.org/
W3C: https://www.w3.org/
TC39: https://tc39.es/
HTTP RFCs: https://www.rfc-editor.org/
web.dev: https://web.dev/

Acessibilidade

WAI: https://www.w3.org/WAI/
WCAG 2.2: https://www.w3.org/TR/WCAG22/
WCAG 2.2 pt-BR: https://www.w3.org/Translations/WCAG22-pt-BR/
ARIA APG: https://www.w3.org/WAI/ARIA/apg/

UX e serviços

ISO 9241-210: https://www.iso.org/standard/77520.html
Nielsen Norman Group: https://www.nngroup.com/
GOV.UK Service Manual: https://www.gov.uk/service-manual
GOV.UK Design System: https://design-system.service.gov.uk/
Baymard: https://baymard.com/

Frameworks

React: https://react.dev/
Next.js: https://nextjs.org/docs
Vue: https://vuejs.org/
Nuxt: https://nuxt.com/docs
Angular: https://angular.dev/
Svelte: https://svelte.dev/
Astro: https://docs.astro.build/
Vite: https://vite.dev/
TypeScript: https://www.typescriptlang.org/docs/

Bibliotecas

Tailwind: https://tailwindcss.com/
Bootstrap: https://getbootstrap.com/
MUI: https://mui.com/
Ant Design: https://ant.design/
Chakra: https://chakra-ui.com/
Mantine: https://mantine.dev/
Radix: https://www.radix-ui.com/
React Aria: https://react-spectrum.adobe.com/react-aria/
shadcn/ui: https://ui.shadcn.com/
TanStack Query: https://tanstack.com/query/latest
Redux Toolkit: https://redux-toolkit.js.org/
Zustand: https://zustand.docs.pmnd.rs/
XState: https://stately.ai/docs
React Hook Form: https://react-hook-form.com/
Zod: https://zod.dev/

Testes

Testing Library: https://testing-library.com/
Playwright: https://playwright.dev/
Cypress: https://www.cypress.io/
Vitest: https://vitest.dev/
Jest: https://jestjs.io/
Storybook: https://storybook.js.org/
axe-core: https://github.com/dequelabs/axe-core

Segurança

OWASP: https://owasp.org/
Cheat Sheets: https://cheatsheetseries.owasp.org/
PortSwigger Academy: https://portswigger.net/web-security
MDN Security: https://developer.mozilla.org/docs/Web/Security

Design systems

Material: https://m3.material.io/
Apple HIG: https://developer.apple.com/design/human-interface-guidelines/
Fluent: https://fluent2.microsoft.design/
Carbon: https://carbondesignsystem.com/
Spectrum: https://spectrum.adobe.com/
Atlassian: https://atlassian.design/
Polaris: https://polaris.shopify.com/
USWDS: https://designsystem.digital.gov/

IA

OpenAI: https://developers.openai.com/api/docs
Anthropic: https://docs.anthropic.com/
Google: https://ai.google.dev/
Microsoft Foundry: https://learn.microsoft.com/azure/ai-foundry/
AWS Bedrock: https://docs.aws.amazon.com/bedrock/
Mistral: https://docs.mistral.ai/
Cohere: https://docs.cohere.com/
Hugging Face: https://huggingface.co/docs
xAI: https://docs.x.ai/
NVIDIA NIM: https://docs.nvidia.com/nim/
Vercel AI SDK: https://ai-sdk.dev/
MCP: https://modelcontextprotocol.io/

43. Recomendação final

Recomendação principal

Aprenda e projete na seguinte ordem:

HTML, CSS, JavaScript, HTTP e Git;
usabilidade, arquitetura da informação e acessibilidade;
TypeScript;
um framework;
APIs, estado e formulários;
testes;
desempenho e segurança;
design system;
integração com backend;
IA.

Stack inicial recomendada para seu contexto

Para aprender e produzir sistemas corporativos:

Frontend:
HTML + CSS + TypeScript
React ou Vue
Vite
TanStack Query
React Hook Form ou equivalente
Zod
Storybook
Playwright

Backend:
Java
Spring Boot
PostgreSQL

Qualidade:
ESLint
Prettier
testes
Lighthouse
axe
OWASP
CI/CD

Para um primeiro sistema interno simples, reduza:

Spring Boot + Thymeleaf + HTML + CSS + JavaScript + PostgreSQL

Próximo passo concreto

Construa uma única funcionalidade completa:

abertura, edição, validação e acompanhamento de uma ordem de serviço.

Inclua:

pesquisa;
fluxo;
wireframe;
UI;
acessibilidade;
API;
banco;
testes;
logs;
desempenho;
revisão.

Não avance para uma nova biblioteca até conseguir explicar:

qual problema ela resolve;
qual custo adiciona;
como será testada;
como será removida;
quem a manterá.

Nota de atualização

Tecnologias, APIs, modelos de IA, preços e recomendações de frameworks mudam rapidamente. Verifique sempre a documentação oficial e a data da informação antes de tomar decisão de arquitetura ou contratação.

Atualização 2026: frontend com IA sem cair na interface genérica

Ferramentas generativas aceleram a produção de componentes, mas tendem a repetir padrões fáceis de combinar: título enorme, gradiente roxo, cartões idênticos, glassmorphism, brilho decorativo e animações que deslocam o layout. O problema não é “parecer feito por IA”; é o design deixar de comunicar hierarquia, ação e estado. Uma interface profissional começa pela tarefa, pelo conteúdo e pelas restrições, não pelo efeito visual disponível.

Antes de pedir uma tela a um agente, defina cinco contratos:

Arquitetura da informação: o que pertence à navegação global, à página e ao contexto local.
Hierarquia editorial: qual pergunta o título responde, qual ação é primária e que informação pode esperar.
Sistema visual: famílias tipográficas, escala, espaçamento, cores semânticas, bordas, sombras e ícones.
Estados: vazio, carregando, sucesso, erro, indisponível, sem permissão, offline e conteúdo longo.
Aceite acessível: teclado, foco não encoberto, contraste, zoom de 200%, movimento reduzido e alvos de toque.

Do conceito ao navegador real

Ler o fluxo em texto

1. Tarefa do usuário
2. Arquitetura da informação
3. Contrato do componente
4. Estados e conteúdo real
5. Implementação visual
6. Navegador e dispositivos
7. Acessibilidade, desempenho e evidência

O agente pode propor alternativas em cada etapa, mas não deve saltar diretamente de “crie um portal” para JSX. Use conteúdo real cedo: nomes longos, ausência de imagem, erros, tabelas, tradução e dispositivos estreitos revelam decisões que um mockup perfeito esconde. Em revisão, compare a posição e o tamanho das caixas antes e depois do hover; destaque clicável pode mudar cor, borda ou sombra sem mover o elemento.

Como usar avaliação independente em design

Qualidade visual contém aspectos objetivos e subjetivos. Overflow, contraste, foco, console e tempo de resposta têm verificações determinísticas. Hierarquia, coerência e sensação de acabamento precisam de uma rubrica e, em trabalhos de maior risco, de um revisor com contexto separado. A pesquisa da Anthropic sobre aplicações longas mostra que um avaliador separado pode ajudar perto do limite do gerador, mas também pode virar custo desnecessário. Por isso, comece por critérios e screenshots comparáveis; acrescente outro agente somente quando a revisão independente detectar falhas que os testes não capturam.

Checklist de uma interface contemporânea

Cada página informa onde o usuário está, o que pode fazer e como voltar.
Componentes clicáveis têm aparência e foco reconhecíveis sem deslocamento.
Títulos cabem no celular e não competem com o conteúdo.
Prosa longa usa largura confortável; tabelas e diagramas podem expandir.
O sistema mantém contraste em todos os estados, inclusive desabilitado e selecionado.
O layout é testado em conteúdo real, teclado, toque, zoom e movimento reduzido.
A animação explica ordem ou mudança; decoração não interrompe leitura nem interação.
O design system codifica decisões recorrentes, mas permite composições diferentes conforme a tarefa.

A referência normativa atual é a WCAG 2.2 da W3C. Para o uso de agentes em design e execução longa, consulte também Harness design for long-running application development. Essas fontes sustentam critérios e método; não autorizam copiar a identidade visual de outro produto.