lucas.gaspareto_
/
// ──────────────────────taste · princípio 4──────────────────────
← todos os princípios

// princípio 04

Feedback e acessibilidade vão com a v1

Elas são a feature, não extras. Adiar é erro de categoria.

Estados de loading, estados vazios, estados de erro, confirmações de sucesso, navegação por teclado, focus rings, razões de contraste, labels de screen-reader, suporte a reduced-motion — não são coisas pra "voltar depois do MVP". Elas SÃO o MVP. Uma feature sem elas está objetivamente não-enviada, não importa o que a descrição diga.

Feedback e acessibilidade são a diferença entre "uma coisa que um humano pode usar" e "uma coisa que tecnicamente roda". A diferença é tudo.

Sinal de violação

Uma feature com demo de happy-path que quebra quando você tenta usar só por teclado, não tem spinner de loading, parece ok mas é ilegível em light mode, ou tem um botão sem focus ring.

Contra-sinal

Antes de chamar algo de pronto, você testou com teclado, checou contraste contra ambos os temas, tabulou pela coisa toda, acionou o caso de erro de propósito, e olhou pra ela sem dados carregados.

Bom exemplo

Um validador runtime em dev-mode que explicitamente reporta dados faltando/órfãos/mis-typed — feedback É a feature.

Mau exemplo

Um dialog overlay que "funciona no happy path" mas lê mal por contraste fraco sobre a UI por baixo. Falha de feedback no nível do MVP, não um passo de polish.