Quem escreve
Karl Koch é designer e desenvolvedor anglo-dinamarquês. Está no DuckDuckGo desde 2023, onde monta a prática de design engineering e lidera o design e o frontend das respostas assistidas por IA da busca. Entre 2021 e 2023 liderou Product Design, DesignOps e Design Systems na Moneybox, onde construiu a base do design system da empresa. Mantém o Kernel UI, biblioteca aberta de componentes semânticos para a web que ele criou, desenhou e programou de ponta a ponta, e com a qual o próprio site é feito. Desde 2021 também é design lead da Cosmic.
O plano que esquece a interação
O ensaio saiu na seção de opinião do site dele e parte de um princípio que ele mesmo escreveu para o time em 3 de setembro: quando o tempo aperta, reduzir escopo antes de reduzir qualidade. A parte incômoda, diz, é fazer isso significar alguma coisa diante de um prazo e de mais trabalho do que tempo. Concordar que os detalhes importam é fácil; difícil é decidir qual funcionalidade fica de fora para que as outras fiquem prontas. Koch escreve que não quer que o padrão de trabalho do time dependa de alguém “finding a spare evening to make the product feel coherent”, achar uma noite livre para dar coerência ao produto. Ele avisa que a prática ainda está em construção e que o texto é uma intenção, não um problema resolvido.
O exemplo da exportação
A função imaginária é simples: as pessoas precisam baixar um relatório, e a equipe gostaria de oferecer escolha de formatos, preferências salvas e histórico de exportações. O plano tentador lista essas capacidades e estima o trabalho de construir cada uma. Aí a implementação começa e aparece o resto: gerar o relatório demora e alguém precisa explicar a espera; a exportação pode falhar e precisa de um estado de erro útil; o botão pode ser apertado duas vezes, e é preciso decidir o que o segundo clique faz.
Nada disso surpreende quem pensa em alguém usando a função, escreve Koch. Só não estava visível na lista de capacidades. E chamar esse trabalho de acabamento faz dele algo fácil de adiar, porque a exportação funciona, afinal: aperta-se o botão e em algum momento um arquivo aparece. Quem aperta é que não sabe se algo está acontecendo, se deve tentar de novo ou se quebrou alguma coisa. A proposta dele é estimar a experiência de pedir e receber o relatório, incluindo o que acontece enquanto o sistema trabalha e como a pessoa se recupera de uma falha. Formatos extras e preferências salvas viram decisões separadas, com custo próprio.
O que entra na primeira versão
A tabela do ensaio tem duas colunas. Na primeira versão: um formato útil de exportação; retorno claro de progresso e de conclusão; uma falha compreensível e uma forma de tentar de novo; acesso por teclado e proteção contra pedido duplicado acidental. Para uma versão posterior: formatos adicionais; preferências de exportação salvas; histórico navegável; efeitos de transição mais elaborados.
Koch ressalva que aquilo não é um plano universal de exportação, e que outro público pode precisar de dois formatos desde o início. O ganho, para ele, está em tornar a decisão explícita, para que as partes inacabadas da interação central não virem a economia invisível que faz o cronograma fechar.
Ser específico sobre o que merece cuidado
A segunda parte do texto ataca a palavra craft, que vira frustrante quando significa o que a pessoa mais exigente da sala quiser que signifique. Ele assume o próprio gosto: movimento, tipografia, a relação entre uma superfície e outra, detalhes em que passa tempo e que outra pessoa mal nota. Isso não torna toda melhoria igualmente importante para o produto que está sendo entregue.
É aqui que entra a única referência externa do ensaio: o texto de Emil Kowalski sobre quando animações são úteis, que Koch chama de lembrete para questionar o efeito em si. Kowalski é design engineer no time de Web da Linear, trabalhou antes no time de design da Vercel e é autor das bibliotecas Sonner e Vaul. O texto dele conclui que às vezes a melhor animação é nenhuma animação, e propõe como regra prática manter animações de interface abaixo de 300 ms.
Aplicado à exportação, o critério fica concreto: o retorno que confirma o pedido importa mais que uma entrada elaborada para esse retorno, e um erro legível importa mais que um erro bem animado. E dá à revisão um ponto de partida melhor. Em vez de pedir que a coisa fique melhor, aponta-se a incerteza: apertei o botão e não deu para saber se o pedido tinha começado. Alguém pode investigar isso e propor uma correção, sem precisar adivinhar qual versão de bom gosto deve satisfazer.
Quem termina o trabalho
Koch liga o assunto ao que já fez. Na Moneybox foi a base do design system; no DuckDuckGo, a pergunta é como tornar qualidade repetível numa prática em formação. Os dois casos o interessam pelo mesmo motivo: como uma decisão sobrevive à pessoa que se importou com ela primeiro. Um componente compartilhado entrega, por padrão, um bom estado de carregamento à próxima funcionalidade. Uma explicação curta ajuda outro engenheiro a reconhecer o mesmo problema em outro lugar. Nenhum dos dois dispensa revisar a funcionalidade em contexto, mas reduzem o quanto é preciso redescobrir.
O que ele pede é que quem desenha a interação continue envolvido até vê-la funcionando com conteúdo real, estados estranhos e entrada comum, e que esse tempo exista no plano. Vai continuar havendo coisa que passa e decisão para rever depois do lançamento, escreve, porque nenhum processo elimina isso. O que dá para evitar é montar um processo que precise de resgate toda vez. A pergunta com que ele fecha é a que quer levar à próxima reunião de planejamento: diante de um plano que só cabe no prazo, qual parte da experiência está sendo deixada para alguém terminar depois?
