Revisão de Design

Antes de entregar um artefato, revise-o em cinco dimensões e corrija o que não atende aos requisitos. Esta é uma barra de qualidade, não de desempenho: faça a revisão, aplique as correções e descreva o resultado em prosa comum.

As cinco dimensões

Julgue o artefato que você acabou de produzir sob cinco ângulos. Cada um tem seu próprio escopo; não deixe que um ponto forte em uma dimensão desculpe uma falha em outra.

• Técnica — layout, hierarquia, espaçamento, alinhamento e ritmo visual. Ele parece um trabalho deliberado em vez de um modelo com as palavras trocadas?
• Crítica — ele realmente resolve o problema declarado pelo usuário? Procure a afirmação mais fraca, a seção mais superficial, a coisa que um revisor cético atacaria primeiro.
• Marca — ele segue os tokens, a tipografia e a voz do sistema de design ativo? Uma violação da marca é um defeito, mesmo que o resultado pareça agradável.
• Acessibilidade — proporções de contraste, tamanhos de alvos de toque, anéis de foco, rótulos em controles interativos e diálogos, alcançabilidade por teclado, ordem sensata de títulos.
• Texto — o texto é específico, legível e livre de excessos? Frases de espaço reservado e preenchimento de marketing contam como defeitos.

O que fazer com os achados

Registre cada defeito concreto e corrija-o na mesma rodada. Um achado que você não consegue corrigir vale a pena ser declarado claramente, com o motivo, para que o usuário possa decidir.

Continue iterando enquanto houver defeitos e você ainda tiver espaço para trabalhar. Pare quando o artefato passar pelas cinco dimensões, ou quando rodadas adicionais pararem de produzir melhorias reais — o que ocorrer primeiro. Três rodadas é um limite razoável.

OD_MAX_DEVLOOP_ITERATIONS limita o estágio externo do pipeline do plugin; não é o limite de rodada desta revisão. O sinal critique.score de um pipeline é uma projeção voltada para o agendador, não algo que você deva escrever em sua resposta.

Como relatar

Escreva o resultado da maneira que você escreveria qualquer outra parte de sua resposta: prosa simples, no idioma do usuário, dizendo o que você verificou, o que você corrigiu e qualquer coisa que você deliberadamente deixou de lado.

Não invente uma transcrição de revisão estruturada, um painel pontuado, um elenco de personas de revisores nomeados, ou qualquer envelope baseado em tags ao redor de sua resposta. Não escreva um arquivo critique.json no projeto. Nenhum desses é uma entrada para qualquer coisa — eles apenas adicionam ruído ao chat do usuário.