Design não tem linha de chegada, continua no desenvolvimento

A premissa falha do design em fases

A maioria dos projetos de software segue o mesmo formato: um bloco inicial de design (descoberta, pesquisa, wireframes, mockups), seguido de um handoff e um longo período de desenvolvimento. Ted Mayer, da Atomic Object, argumenta que essa estrutura é fundamentalmente defeituosa.

As decisões de design mais difíceis não acontecem naquele bloco inicial - elas surgem no meio do build, quando dados reais, edge cases e usuários começam a furar as suposições. Se a capacidade de design já foi gasta no início, essas decisões continuam sendo tomadas, mas por quem está mais perto do teclado, sob prazo, sem ninguém questionando se ainda é a escolha certa.

Onde as perguntas reais moram

O design feito no início opera sobre suposições. Não existe software funcionando para contestar os instintos do designer. Quando o build começa, a realidade aparece: o estado vazio que ninguém previu, a API que retorna um formato não planejado, o fluxo que parece bom no whiteboard mas é miserável no passo quatro, o "edge case" que representa um terço do uso real.

Nenhum desses é um problema de build. Todos são decisões de design disfarçadas de problema técnico.

O custo de estar "confiantemente errado"

O design em fases parece saudável: o design está pronto, o build está rodando, o gráfico está verde. Mas por baixo, o projeto acumula pequenos desvios que ninguém verifica. A alternativa - uma linha contínua de atenção ao design - troca esse progresso limpo por algo melhor: pegar o desvio enquanto ainda dá para corrigir. "Visivelmente incompleto" é desconfortável; "confiantemente errado" é um rewrite.

O que fazer

• Orce design como taxa, não como bloco. Proteja uma fatia constante de capacidade de design ao longo de todo o projeto. Menor que o bloco inicial, mas nunca zero.
• Coloque design dentro do loop de build. Designers em standups, revisando PRs, presentes quando um edge case força uma decisão.
• Pergunte "quem decide isso?" O sinal mais claro de que o design acabou silenciosamente é quando decisões de interface passam a ser tomadas sem ninguém sinalizá-las como decisões.
• Enquadre para o cliente como redução de risco, não como scope creep. Design contínuo não é polimento extra - é como evitar construir a coisa errada de forma eficiente.