Como o design de produto reduz custo de desenvolvimento

Existe um gráfico que aparece há décadas em apresentações sobre desenvolvimento de software. Ele mostra algo parecido com isto:

corrigir durante requisitos: 1x
corrigir durante desenvolvimento: 10x
corrigir depois de entregue: 100x

A mensagem é tentadora. Descubra cedo e economize cem vezes. O problema é que a evidência por trás dessa versão exata é muito menos sólida do que o gráfico faz parecer. E isso importa porque Design de Produto não precisa de um número folclórico para justificar seu valor. Existe um argumento muito mais defensável:

quanto mais decisões importantes chegam à engenharia ainda mal definidas, mais capacidade do time é consumida construindo, refazendo e mantendo coisas que poderiam ter sido questionadas antes.

O ganho do design não está em impedir toda mudança. Está em reduzir o retrabalho que já era evitável.

O gráfico de 1:10:100 tem uma história ruim

Uma versão muito difundida do gráfico costuma ser atribuída ao “IBM Systems Sciences Institute”. O problema é localizar a pesquisa original. Laurent Bossavit investigou a cadeia de referências ao escrever The Leprechauns of Software Engineering. Hillel Wayne retomou a investigação anos depois. A trilha chega a livros de engenharia de software que citavam dados atribuídos a notas de curso do IBM Systems Sciences Institute. Não aparece um estudo empírico publicado que permita examinar amostra, metodologia, projetos, definição de defeito ou forma de cálculo.

Isso não prova que a ideia geral seja falsa. Prova que o gráfico específico não deveria ser apresentado como uma lei científica bem estabelecida. Se alguém numa reunião perguntar:

de onde vieram exatamente esses números?

a resposta fica desconfortável. E existe evidência melhor para discutir o problema.

O que Boehm e Basili realmente escreveram

Em 2001, Barry Boehm e Victor Basili publicaram na IEEE Computer a Software Defect Reduction Top 10 List. O primeiro item diz que encontrar e corrigir um problema depois da entrega pode ser frequentemente até cem vezes mais caro do que encontrá-lo nas fases de requisitos e design. Mas existe uma frase seguinte muito importante: os próprios autores observam que, para sistemas pequenos e não críticos, o fator de escalada pode estar mais próximo de 5:1 do que de 100:1.

Isso muda bastante a leitura. Não existe uma constante universal dizendo que produção é 100 vezes mais caro. O custo depende do tipo de sistema, da arquitetura, da criticidade, do processo, da forma de implantação, da natureza do erro e do momento da descoberta. Um bug numa label não tem a mesma curva de custo que uma decisão errada no modelo de autorização de uma fintech.

O ponto defensável é mais simples: algumas decisões ficam significativamente mais caras de mudar depois que outras partes do sistema começam a depender delas. É aí que Product Design pode alterar a conta.

Retrabalho evitável é uma métrica mais interessante que “custo do bug”

O segundo item do mesmo trabalho é particularmente relevante. Boehm e Basili apontavam que projetos de software gastavam cerca de 40% a 50% do esforço em retrabalho evitável dentro das evidências analisadas. Retrabalho evitável significa trabalho gasto corrigindo dificuldades que poderiam ter sido descobertas antes ou evitadas.

Mas os autores fazem uma ressalva importante. Nem toda mudança é ruim. Software também evolui porque o time aprende: uma pesquisa muda uma hipótese, um protótipo mostra um comportamento inesperado, uma implementação revela uma restrição que ninguém conhecia, o mercado muda. Isso produz o que podemos chamar de retrabalho inevitável ou, em alguns casos, simplesmente aprendizado.

O objetivo não deveria ser “nunca refazer nada”. Se isso acontecer, existe uma boa chance de o produto também não estar aprendendo nada. A pergunta melhor é: quanto do que estamos refazendo poderia ter sido descoberto antes com um custo muito menor?

Nem todo retrabalho nasce no código

Imagine uma feature que levou três semanas para ser implementada. A engenharia executou exatamente o que estava especificado. Quando entra em produção, um cliente diz:

isso não funciona quando uma empresa tem dois aprovadores.

O problema não começou na implementação. A regra nunca foi definida.

Outro exemplo. O fluxo funciona perfeitamente quando um pagamento é aprovado. Só durante QA alguém pergunta:

o que acontece quando ele expira?

Agora surge novo estado, nova mensagem, nova regra, nova ação, nova lógica no backend.

Mais um. O time constrói durante dois meses uma área nova. Depois do lançamento, quase ninguém utiliza. Não existe bug. Tecnicamente, tudo funciona. O desperdício aconteceu antes: construímos uma solução sem evidência suficiente de que aquele era o problema que valia resolver. Engenharia não corrige isso escrevendo código melhor.

Quatro formas comuns de retrabalho começam antes do desenvolvimento

A regra que ninguém tornou explícita

Administrador pode editar usuário.

Parece simples. Até aparecer: e se o usuário for o último administrador? E se pertencer a outra unidade? E se tiver pagamentos aguardando aprovação? E se estiver removendo a si próprio? E se a organização possuir aprovação dupla? Cada resposta pode alterar modelo de permissão, API, interface, estado e auditoria. Perguntar antes custa pouco. Descobrir depois custa todas as camadas que agora precisam mudar.

O estado que só apareceu no caminho feliz

Design mostra:

pagamento aprovado.

Mas não mostra processando, recusado, expirado, cancelado, estornado, parcialmente devolvido, em contestação. A primeira implementação pode parecer pronta até um desses estados aparecer na operação. Produtos complexos não quebram apenas por falta de telas. Quebram porque o modelo de estados estava incompleto.

A solução construída antes do problema estar claro

Pedido:

precisamos de exportação em CSV.

Construir é relativamente fácil. A pergunta anterior é:

o que a pessoa faz depois de exportar?

Talvez a resposta seja:

junta com os dados do ERP porque falta a coluna X.

Agora existem outras possibilidades: adicionar X, integrar com o ERP, criar API, gerar o relatório completo. A exportação pode continuar sendo a melhor solução. A diferença é que agora foi escolhida.

A decisão que precisa ser tomada novamente

Três meses atrás o time discutiu por que determinado fluxo não permitia exclusão. A decisão foi correta. Ninguém registrou. Chega um novo PM. A questão volta. Design revisa, engenharia investiga, todo mundo discute novamente. Documentar decisão também reduz custo de desenvolvimento, embora nenhum pixel tenha mudado.

Product Design reduz custo quando entra antes da solução estar fechada

Esse é um ponto importante. Design não economiza engenharia simplesmente porque alguém criou Figma antes de alguém criar React. Se o designer apenas recebe:

faça estas seis telas.

a maior parte das decisões caras pode já ter acontecido. O efeito aparece quando Product Design consegue questionar: qual problema estamos resolvendo, para quem, qual regra governa isso, que estados existem, o que acontece quando dá errado, qual permissão é necessária, que dependências aparecem, como saberemos se funcionou. Essa conversa muda o que chega ao desenvolvimento.

Um fluxo no Figma também pode estar errado. A diferença é o custo de descobrir.

Imagine que o time está decidindo um onboarding. Existem duas hipóteses.

Opção A

Pedir toda configuração antes de permitir acesso.

Opção B

Permitir entrada e completar configuração progressivamente.

Podemos discutir verbalmente durante horas. Podemos também prototipar as duas direções. Agora dá para mostrar, percorrer, testar, questionar e comparar. Se descobrirmos que a hipótese está errada, apagamos frames. Quando a mesma descoberta acontece depois que existem backend, analytics, eventos, validações, migração, QA, documentação e suporte, mudar de ideia envolve muito mais gente.

O valor do protótipo não está em parecer produto. Está em permitir que algumas decisões falhem antes de ficarem caras.

O melhor protótipo não é necessariamente o mais detalhado

Existe um erro simétrico. Se mudar código é caro, então vamos desenhar absolutamente tudo antes. Também não. Imagine uma hipótese que ainda nem sabemos se alguém quer. O time passa três semanas produzindo design system, motion, responsividade, empty states, microinterações e protótipo de alta fidelidade. Depois conversa com clientes. Ninguém precisa daquilo. O time reduziu retrabalho de engenharia criando retrabalho de design. Não resolveu o problema.

A régua é: qual é a coisa mais barata que consegue responder a pergunta que temos agora? Às vezes é uma conversa. Às vezes é um desenho no papel. Às vezes é protótipo. Às vezes é código em produção para 5% da base. Product Design também precisa saber quando não desenhar demais.

O custo de mudar deveria determinar o quanto investigamos antes

Uma decisão simples:

título desta seção deveria ser “Extrato” ou “Movimentações”?

É barata de reverter. Você não precisa de duas semanas de discovery. Agora:

como modelaremos organizações, workspaces e usuários?

ou:

como funcionará autorização entre múltiplas empresas?

A decisão começa a atravessar banco, API, autenticação, billing, interface, analytics, suporte e integrações. Aqui faz sentido gastar mais energia antes. Uma boa pergunta de produto é: se estivermos errados, quanto custa voltar? Quanto maior o custo de reversão, maior o valor de reduzir incerteza antes.

Modelo de dados merece atenção cedo

Imagine uma plataforma que começa assumindo:

um usuário pertence a uma empresa.

Meses depois surge uma necessidade enterprise:

um usuário pode administrar dez empresas.

Essa frase simples pode atingir autenticação, queries, permissões, navegação, notificações, auditoria, relatórios e billing. Se a possibilidade já era conhecida e ninguém a discutiu, existe retrabalho evitável. Se surgiu porque o mercado mudou, talvez não exista. Essa distinção é importante. Product Design não precisa adivinhar o futuro. Precisa trazer para a mesa as restrições que já são relevantes para a decisão atual.

Permissão também fica cara rapidamente

Permissão parece uma configuração de interface:

esconder botão para quem não é admin.

Só que autorização real não acontece no botão. Ela atravessa backend, dados e API. Quando a empresa descobre tarde que precisa de papéis customizados, escopos, unidades, aprovação dupla, delegação e auditoria, o custo pode ser alto porque todo o produto assumia um modelo mais simples. É um bom exemplo de decisão em que interface, regra de negócio e arquitetura precisam conversar antes.

Design system reduz outro tipo de retrabalho

Nem todo desperdício vem de definição de feature. Parte vem de resolver o mesmo problema de interface repetidamente. Um formulário usa um padrão, outro usa outro. Uma tabela possui um comportamento, a próxima reimplementa. Cada squad decide novamente loading, erro, modal, filtro, paginação, estado vazio. A engenharia repete trabalho. Design repete trabalho. QA testa comportamentos diferentes. Usuário reaprende.

É justamente o tipo de problema tratado em Design system: escale seu produto com consistência. Nesse caso, reduzir custo significa parar de tomar a mesma decisão várias vezes.

IA tornou código mais barato. Isso não tornou decisão automaticamente melhor.

Esse ponto ficou ainda mais interessante com ferramentas de geração de código. Hoje é possível produzir uma primeira implementação muito mais rápido. Isso é excelente. Também altera onde está o desperdício. Se uma interface que antes levaria três dias agora aparece em meia hora, o custo de experimentar caiu. Ótimo. Mas a ferramenta ainda pode implementar muito rapidamente uma regra errada, um fluxo desnecessário, um modelo de permissão frágil ou uma feature que ninguém pediu porque não precisava.

Código mais barato pode tornar experimentação mais barata. Não torna automaticamente a decisão correta. Na prática, isso torna uma pergunta ainda mais importante:

o que estamos tentando aprender construindo isso?

Se existe resposta, velocidade ajuda. Se não existe, apenas conseguimos produzir desperdício mais rápido.

Design não deveria ser vendido como seguro contra retrabalho

Essa promessa é perigosa.

Se fizermos discovery direito, não precisaremos refazer.

Não é verdade. Produto aprende, implementação ensina, usuário muda, hipótese falha. Um bom processo não elimina isso. O que ele tenta reduzir é algo mais específico: descobrir tarde aquilo que já poderíamos ter descoberto cedo. É uma promessa menos espetacular. Também é muito mais defensável.

Como saber se existe retrabalho evitável na sua empresa

Antes de procurar benchmark, olhe para o histórico. Pegue as funcionalidades entregues nos últimos doze meses e pergunte: quantas precisaram ser substancialmente refeitas logo depois? E por quê? Requisito ausente, regra inesperada, restrição técnica, feedback novo, mudança estratégica? Depois: quantas quase não são utilizadas? E: quantas discussões importantes precisaram acontecer novamente porque a decisão anterior não estava registrada?

Você pode criar uma classificação simples. Aprendizado inevitável: não havia informação razoável para saber antes. Retrabalho potencialmente evitável: a informação existia ou poderia ter sido obtida com esforço proporcionalmente pequeno.

Agora você tem um diagnóstico muito mais relevante que:

estudos dizem que bug custa 100 vezes mais em produção.

É o retrabalho da sua empresa.

Algumas métricas ajudam a colocar dinheiro na conversa

Se quiser transformar isso em custo, acompanhe coisas como:

• horas gastas refazendo feature recém-entregue;

• bugs gerados por regra mal definida;

• features com uso muito abaixo do esperado;

• chamados provocados por estados não tratados;

• tempo de engenharia gasto corrigindo inconsistência entre telas;

• mudanças grandes realizadas nas primeiras semanas depois do lançamento.

Não é necessário criar uma contabilidade perfeita. A intenção é observar padrão. Imagine descobrir:

aproximadamente um quarto da capacidade das últimas seis sprints foi usado alterando coisas lançadas nas duas sprints anteriores.

Agora existe uma conversa concreta. A pergunta deixa de ser “precisamos investir mais em UX?” e vira “por que estamos descobrindo tantas coisas apenas depois de implementar?”. Essa é uma pergunta muito melhor.

Como defender Product Design para quem controla orçamento

Eu evitaria começar por:

experiência do usuário é importante.

Não porque seja falso. Porque é abstrato para quem está olhando capacidade e custo. Comece pelo fluxo de dinheiro.

Construímos esta funcionalidade duas vezes.

Esta outra consumiu seis semanas e 3% dos clientes utilizam.

Esta regra foi refeita em frontend e backend porque um estado não foi mapeado.

Suporte recebe 180 chamados mensais sobre algo que poderia ser prevenido na interface.

Agora Product Design deixa de ser uma discussão estética. É alocação de capacidade.

Não use 1:10:100 como argumento principal

Mesmo quando a ideia intuitiva parece correta, a precisão histórica do gráfico é frágil. Não precisamos dele. Basta mostrar que diferentes decisões têm diferentes custos de reversão. Mudar uma frase hoje custa minutos. Mudar um modelo de autorização utilizado por cinquenta endpoints pode custar semanas.

E, principalmente, sua própria empresa possui evidência melhor. Quantas coisas foram construídas duas vezes? Quantas foram construídas e não usadas? Quantas regras chegaram à engenharia pela metade? Quanto suporte existe por decisões de produto evitáveis? Esse histórico não precisa ser extrapolado de projetos dos anos 1970. Está no seu Jira, GitHub, Figma, analytics e suporte.

O trabalho de Product Design é reduzir o custo de estar errado

Produto sempre vai errar em alguma coisa. Isso é inevitável. O objetivo não é tomar decisões perfeitas antes de construir. É criar mecanismos para errar de forma mais barata. Investigar antes de especificar. Prototipar antes de comprometer arquitetura quando fizer sentido. Mapear estados antes de descobrir exceções em produção. Colocar design e engenharia na mesma conversa cedo. Instrumentar antes de lançar. Registrar decisões. Medir depois. Remover o que não produz valor.

É assim que Design de Produto reduz custo de desenvolvimento. Não porque desenha telas mais baratas. Porque reduz a quantidade de capacidade cara usada para descobrir tarde aquilo que poderia ter sido descoberto cedo.

E existe uma consequência interessante: quanto mais barato fica escrever código, mais visível fica esse desperdício. Se construir deixa de ser o gargalo, decidir bem o que merece ser construído ganha ainda mais importância.

Fontes

Boehm, Barry; Basili, Victor R. Software Defect Reduction Top 10 List. IEEE Computer, volume 34, número 1, páginas 135–137, janeiro de 2001.

Os autores relatam que encontrar e corrigir determinados problemas depois da entrega pode ser frequentemente muito mais caro do que durante requisitos e design, chegando em alguns contextos a fatores da ordem de 100:1. O próprio artigo ressalta que, em sistemas pequenos e não críticos, o fator observado pode estar mais próximo de 5:1. Portanto, esses valores não são tratados neste artigo como constante universal aplicável a SaaS modernos.

O mesmo trabalho relata que aproximadamente 40% a 50% do esforço em projetos analisados era associado a retrabalho evitável. Os autores também distinguem esse conceito de mudanças que surgem legitimamente de processos emergentes e aprendizado durante o desenvolvimento.

Bossavit, Laurent. The Leprechauns of Software Engineering. Investigação crítica sobre diversas afirmações amplamente repetidas em engenharia de software e suas cadeias de citação, incluindo os números atribuídos ao IBM Systems Sciences Institute.

Wayne, Hillel. *I ***ing hate Science, 19 de julho de 2021. Retoma a investigação sobre a origem do gráfico frequentemente atribuído ao IBM Systems Sciences Institute e discute as limitações da evidência empírica disponível sobre o custo de encontrar defeitos em diferentes etapas.

A referência ao IBM Systems Sciences Institute neste artigo não afirma que nunca tenha existido material interno sobre o tema. O ponto é que não há um estudo empírico publicado e verificável sustentando o conhecido gráfico como ele costuma ser apresentado.