Recursos irrefletidos nunca somam um produto cuidadoso

O sinal de biscoito de presunto como metáfora de design

Pavel Samsonov usa o conceito de "ham biscuit sign" - popularizado por Eric Bailey - como metáfora central para um problema recorrente em produtos digitais. A ideia é simples: um restaurante coloca um letreiro neon dizendo "biscoito de presunto" na estrada, mas o cliente não sabe se o restaurante está aberto, se o biscoito está disponível, nem o que acontece ao chegar lá. O letreiro resolve um problema superficial (visibilidade) e cria dezenas de outros (incerteza, frustração, abandono). Em software, o padrão se repete: um stakeholder identifica um problema, desenha uma solução apressada, empurra para produção e considera o assunto encerrado. Quando um designer de verdade encontra a feature, já é tarde demais.

A divisão entre ter ideias e executar ideias

O autor argumenta que o problema é estrutural. As responsabilidades foram divididas entre "quem tem ideias" e "quem executa", isolando os primeiros de qualquer consequência. Sem exposição a necessidades reais de usuários, as ideias nascem de outros softwares que a pessoa já usou. O resultado é previsível: copiar o "Wrapped" do Spotify, adicionar FAQ porque outros sites têm, incluir dark mode porque o Discord tem, ou colocar um contador de tarefas porque o Jira tem. A justificativa comum - "uma lista longa de features facilita a venda" - é falsa. Vendas funcionam por narrativa, e cada widget aleatório torna essa narrativa menos coerente. O segredo é minimizar o número de conceitos que você precisa explicar.

IA como ferramenta para não pensar

Samsonov posiciona a IA como aceleradora do problema. Como todo código de repositórios públicos já está nos dados de treinamento, gerar uma feature é trivial - muito mais fácil do que determinar se ela é necessária. As user stories que chegam para desenvolvimento estão cheias de termos vagos como "usuários querem gerenciar XYZ", sem explicar comportamento esperado nem valor de negócio. A "validação" se resume a perguntar ao usuário "você quer essa feature?" - e a resposta é sempre sim, porque features soam legais. O escopo cresce sem controle.

Pensar por workflow, não por feature

A solução proposta é pensar holisticamente: não como touchpoints isolados, mas como etapas de um workflow. O autor cita três ferramentas práticas. Primeiro, Jobs to Be Done (JTBD), que vai muito além da frase cansada "quando X eu quero Y" e oferece um toolkit completo para mapear motivações. Segundo, o método de top tasks de Duncan Stephen, que ajuda a priorizar os fluxos realmente críticos em vez de features do tipo "não seria legal se...". Terceiro, um filtro para casos de falha - os cenários que nunca aparecem em demos de happy path, mas que usuários reais enfrentam diariamente. Nesses casos, nenhuma feature nova resolve; o que resolve é conteúdo bem escrito, como boas mensagens de erro.

O primeiro passo é simplesmente pensar

A conclusão de Samsonov é direta: a causa raiz do sinal de biscoito de presunto é que ninguém pensou. Um stakeholder pediu "um design" (substantivo) sem que houvesse design (verbo) - sem pesquisa, discussão, debate, colaboração ou exploração. A IA é uma ferramenta para não pensar, e o antídoto não é uma metodologia específica, mas o ato deliberado de pensar antes de produzir.