Design review checklist para handoff de alta fidelidade entre design e desenvolvimento

Crie um checklist completo de design review para handoff entre design e desenvolvimento na equipe de [NOME DA EMPRESA], que usa [Figma] para design e [STACK: React/Vue/Next.js] para desenvolvimento.

**Contexto:**
- Processo atual: designer cria no Figma → dev implementa → QA → muitos revisos
- Problema principal: [DESCREVA O PRINCIPAL GAP]
- Design system: [NOME / EM DESENVOLVIMENTO / SEM DESIGN SYSTEM]
- Ferramenta de handoff: [Figma Dev Mode / Zeplin / Storybook]

---

## CHECKLIST COMPLETO DE DESIGN REVIEW

**Como usar:** O designer preenche antes de marcar uma spec como pronta para dev.
O desenvolvedor valida os itens criticos antes de comecar a implementar.

---

### BLOCO 1 — COMPLETUDE DE ESTADOS

Para cada componente interativo, verificar se todos os estados estao desenhados:

**Estados basicos:**
- [ ] Default / Rest
- [ ] Hover (desktop)
- [ ] Active / Pressed
- [ ] Focus (ring visivel + cor de contraste 3:1)
- [ ] Disabled (nao apenas cinza — opacity ou variacao de cor)
- [ ] Loading (skeleton, spinner, ou indicador)

**Estados de dados:**
- [ ] Lista vazia (zero state) — nao deixar em branco, ter mensagem e CTA
- [ ] Lista com 1 item
- [ ] Lista com poucos itens (2-5)
- [ ] Lista com muitos itens (overflow, paginacao, scroll)
- [ ] Estado de erro de carregamento

**Estados de formulario:**
- [ ] Campo vazio
- [ ] Campo com foco
- [ ] Campo preenchido
- [ ] Campo com erro (mensagem + cor + icone)
- [ ] Campo com sucesso / validacao positiva
- [ ] Campo desabilitado
- [ ] Campo somente leitura (diferente de desabilitado)

**Estados de feedback:**
- [ ] Loading de submissao (botao disabled + spinner)
- [ ] Sucesso (mensagem + comportamento pos-sucesso: redirect? toast? modal?)
- [ ] Erro do servidor (mensagem + opcao de tentar novamente)

---

### BLOCO 2 — RESPONSIVIDADE

Breakpoints obrigatorios (ajuste para o produto):
- [ ] Mobile: 375px (iPhone SE) — viewport mais restritivo comum
- [ ] Mobile largo: 390px (iPhone 14)
- [ ] Tablet: 768px
- [ ] Tablet largo: 1024px
- [ ] Desktop: 1280px
- [ ] Desktop wide: 1440px
- [ ] Ultra-wide: 1920px (se aplicavel)

Comportamentos a especificar:
- [ ] Layout shift: o que muda de layout entre breakpoints (nao so escala)
- [ ] Componentes que colapsam ou mudam de forma (menu → hamburguer, tabela → cards)
- [ ] Ordem de elementos em mobile (especificar quando muda a ordem visual)
- [ ] Tipografia em cada breakpoint (nao assumir que dev vai escalar proporcionalmente)
- [ ] Imagens: proporcao em cada breakpoint, object-fit declarado

---

### BLOCO 3 — ESPECIFICACOES TECNICAS

Valores numericos (nao usar "aproximadamente" ou "mais ou menos"):
- [ ] Todos os espacamentos em multiplos de 4px (ou escala do design system)
- [ ] Border-radius: valor exato para cada componente
- [ ] Opacidade: valor exato (0.5, nao "meio transparente")
- [ ] Z-index: declarar camadas (modal acima de header acima de conteudo)
- [ ] Sombras: declarar offset, blur, spread, cor, opacidade exatos
- [ ] Duracao de animacoes: em milissegundos, com easing especificado

Cores e tokens:
- [ ] Todas as cores referenciadas a tokens do design system (nao hex solto)
- [ ] Texto: token de tipografia declarado (nao apenas tamanho de fonte)
- [ ] Cores de modo escuro mapeadas (se suportado)

Comportamento interativo:
- [ ] Animacoes: o que anima, como, velocidade, trigger
- [ ] Transicoes: entrada e saida de componentes (modal, dropdown, toast)
- [ ] Scroll: suave, snap points, comportamento em overflow
- [ ] Gestos no mobile: swipe, long press, pinch (especificar alternativa para acessibilidade)

---

### BLOCO 4 — CONSISTENCIA COM DESIGN SYSTEM

- [ ] Todos os componentes usados sao da biblioteca oficial (nao custom sem motivo)
- [ ] Componentes custom documentados com justificativa de por que nao usar o da biblioteca
- [ ] Espacamentos usando escala definida (nao valores arbitrarios)
- [ ] Tipografia usando estilos definidos (nao overrides locais sem razao)
- [ ] Icones: todos da biblioteca de icones oficial (nao misturar bibliotecas)
- [ ] Sem "magica": qualquer valor nao standard tem nota explicando

---

### BLOCO 5 — ACESSIBILIDADE

- [ ] Contraste de texto verificado (4.5:1 texto normal, 3:1 texto grande)
- [ ] Contraste de UI components (3:1 para bordas e icones funcionais)
- [ ] Informacao nao passada somente por cor
- [ ] Alvos tocaveis >= 44x44px (mobile)
- [ ] Focus ring visivel em todos os elementos interativos
- [ ] Alt text sugerido para todas as imagens
- [ ] Ordem de leitura declarada quando diferente da ordem visual
- [ ] ARIA roles sugeridos para componentes custom complexos

---

### BLOCO 6 — REVISAO EDITORIAL

- [ ] Todos os textos em portugues brasileiro (sem ingles de placeholder)
- [ ] Termos consistentes em toda a feature (nao "usuario" e "cliente" alternando)
- [ ] Mensagens de erro claras: o que deu errado + o que fazer
- [ ] Microcopy revisado (labels, placeholders, CTAs, toasts)
- [ ] Truncamento definido: onde colocar reticencias em textos longos
- [ ] Formato de dados: datas em dd/mm/aaaa, moeda em R$ X.XXX,XX, CPF XX.XXX.XXX-XX

---

### BLOCO 7 — ANOTACOES PARA O DEV

- [ ] Componentes complexos tem nota de comportamento esperado
- [ ] Integracao com API: quais campos vem do backend, formato esperado
- [ ] Logica condicional documentada: o que aparece / some em quais condicoes
- [ ] Comportamento de paginacao ou scroll infinito especificado
- [ ] Permissoes: quais elementos mudam para perfis diferentes de usuario
- [ ] Links: internos (rota) vs. externos (target blank)

---

**Protocolo de handoff:**
1. Designer preenche o checklist no Figma (como comment ou em documento auxiliar)
2. Design lead revisa o checklist (nao o design em si — so a completude)
3. Feature marcada como "Ready for Dev" somente apos checklist 100%
4. Dev valida Blocos 1, 2, 3 antes de comecar
5. Duvidas: comentar no Figma (nao no Slack — manter contexto)
6. Pos-implementacao: designer valida em staging antes de fechar o ticket

**Metrica de sucesso:** Reducao de rounds de revisao de [ATUAL] para < 1.5 em 60 dias.