Reduzir escopo em vez de qualidade garante produto completo

Reduzir escopo antes de reduzir qualidade

Karl Koch, que constrói a prática de design engineering no DuckDuckGo, defende como princípio reduzir o escopo de um recurso antes de reduzir sua qualidade. Ele reconhece que é fácil concordar em cuidar dos detalhes, mas o difícil é decidir qual funcionalidade deixar de fora para que as mantidas fiquem completas. Como a prática ainda está em construção, ele apresenta o texto como uma intenção, não como uma solução já implementada - e afirma não querer que o padrão de trabalho dependa de alguém encontrar tempo livre para tornar o produto coerente.

Colocar a interação inteira na estimativa

Usando um recurso hipotético de exportação de relatórios, Koch mostra que os planos costumam listar capacidades (formatos de arquivo, preferências salvas, histórico de exportações) e estimar cada uma, mas ignoram partes da experiência que aparecem só na implementação: o tempo de geração do relatório precisa ser comunicado, falhas exigem um estado de erro útil e um segundo clique no botão precisa ter comportamento definido.

Se esse trabalho é rotulado como "polimento", fica fácil adiá-lo - o botão funciona, um arquivo eventualmente aparece. Mas quem usa não sabe se algo está acontecendo, se deve tentar de novo ou se quebrou algo. Koch prefere estimar a experiência completa de pedir e receber um relatório, incluindo o que acontece enquanto o sistema processa e como a pessoa se recupera de uma falha. Formatos extras e preferências salvas viram decisões separadas, com custos próprios.

Em uma divisão entre primeira versão e fases futuras, ele mantém no lançamento inicial um formato de exportação, feedback claro de progresso e conclusão, uma falha compreensível com modo de repetição, acesso por teclado e proteção contra cliques duplicados. Formatos adicionais, preferências salvas, histórico navegável e efeitos de transição elaborados ficam para depois. Ele ressalva que não é um plano universal: um público específico pode precisar de dois formatos ou do histórico desde o início. O que importa é tornar essas decisões explícitas, para que as partes inacabadas da interação central não se tornem o corte invisível que faz o cronograma caber.

Ser específico sobre o que exige cuidado

Koch observa que "craft" vira palavra frustrante quando significa o que a pessoa mais exigente da sala quiser. Ele mesmo se importa com movimento e tipografia e pode gastar tempo em detalhes que outros mal notam, mas isso não torna toda melhoria igualmente importante. Citando um texto de Emil sobre quando animações são úteis, ele sugere questionar o efeito em si: é preciso explicar como o trabalho extra ajuda alguém a entender ou fazer algo. Às vezes a resposta é uma experiência mais agradável - válida, mas que precisa competir com as demais prioridades do time.

No exemplo da exportação, um feedback que confirma o pedido importa mais que uma entrada animada elaborada, e um erro legível importa mais que um erro bonito. Isso dá às revisões um ponto de partida concreto: em vez de pedir que algo "pareça melhor", aponta-se a incerteza - "apertei o botão e não soube se o pedido começou" - para que alguém investigue e proponha correção sem adivinhar qual versão de gosto deve satisfazer.

Dar dono ao acabamento

Com passagens pela Moneybox, onde ajudou a construir as bases do design system, e agora no DuckDuckGo, Koch se interessa por como uma decisão de qualidade sobrevive à pessoa que a defendeu primeiro. Componentes compartilhados podem dar a próximos recursos um bom estado de carregamento por padrão, e explicações curtas ajudam outros engenheiros a reconhecer o mesmo problema - sem eliminar a necessidade de revisar cada recurso em contexto.

Ele quer que quem molda uma interação permaneça envolvido até vê-la funcionando com conteúdo real, estados estranhos e entrada comum - tempo que precisa existir no plano. Chamar isso de "passada final" não ajuda se a data de lançamento assume que o trabalho acabou quando o caminho feliz foi mesclado. Processos não eliminam o que será perdido ou revisitado, mas podem evitar depender de alguém que resgate o projeto toda vez. Diante de um plano que mal cabe no prazo, a pergunta que ele propõe é: qual parte da experiência estamos assumindo que alguém terminará depois? A partir daí, ou se abre espaço para esse trabalho, ou se reduz o que o recurso deve fazer.