Todo produto digital nasce duas vezes. Primeiro como estratégia, depois como interface. A maioria fracassa no intervalo entre essas duas etapas, justamente onde quase ninguém está olhando.
O problema que o Figma não resolve
Existe uma convenção silenciosa e perigosa no mercado de produto: a de que a qualidade da experiência do usuário é proporcional à qualidade da interface. Essa crença cria uma indústria inteira de sintomas sendo tratados com antibióticos para outra doença. Investimos em sistemas de design, contratamos motion designers excepcionais, debatemos a hierarquia tipográfica por horas — enquanto o produto apodrece três camadas acima, no nível da estratégia, da pesquisa que nunca foi feita ou do modelo de negócio que nunca foi honesto com o usuário.
Este artigo não é sobre design de interface. É sobre o que mata produtos antes de qualquer tela ser construída, e por que a maioria das equipes jamais consegue ver o assassino.
Quando o diagnóstico é a própria doença
O primeiro erro estrutural de um produto raramente é técnico. É epistemológico. Equipes que não cultivam o hábito da pergunta legítima — “estamos resolvendo o problema certo?” — entram em modo de execução prematura. E execução prematura é o cicatrizante que cobre uma ferida infectada: a superfície parece curada enquanto o tecido abaixo necrotiza.
A manifestação mais comum desse erro é o que a literatura de produto chama de solution-first thinking. A equipe apaixona-se por uma ideia, e retrospectivamente constrói a pesquisa para justificá-la. O problema do usuário passa a ser moldado para caber na solução que já existe — e não o contrário. O resultado é um produto que tecnicamente funciona e humanamente falha, porque foi construído para validar a inteligência interna da equipe, e não para resolver uma dor real e verificável no mundo.
Os três tipos de problema que as equipes confundem
Há uma distinção crítica que separa produtos que crescem de produtos que sobrevivem artificialmente. Ela reside na natureza do problema que está sendo endereçado. Na prática, observamos três categorias frequentemente confundidas:
- Problemas percebidos: o que os stakeholders acreditam que o usuário sofre, geralmente baseado em intuição ou dados superficiais de suporte.
- Problemas declarados: o que o usuário diz que precisa quando perguntado diretamente — que nem sempre corresponde ao comportamento real.
- Problemas latentes: o que o usuário efetivamente experimenta, mas não consegue articular. É neste nível que os produtos transformadores habitam.
A maioria dos produtos é construída para resolver problemas percebidos ou declarados. Produtos como o iPhone, o Notion ou o Duolingo foram construídos para problemas latentes que os próprios usuários não sabiam nomear. A pergunta que diferencia equipes de produto medíocres de excepcionais não é “o que o usuário quer?” mas “o que o usuário experimenta que ainda não tem nome?”
Silos como arquitetura do fracasso
Existe uma ironia cruel na forma como a maioria das empresas está organizada para construir produtos. O time de negócio define o que deve existir. O time de produto decide como deve funcionar. O time de design determina como deve parecer. O time de engenharia decide como vai ser construído. E o usuário, a pessoa cuja vida deveria estar no centro de todas essas decisões, existe apenas como uma abstração — uma persona num slide, um número num dashboard de analytics.
Quando a estrutura organizacional fragmenta a visão sobre o usuário, o produto torna-se um Frankenstein funcional: cada parte faz sentido isoladamente, mas o conjunto é incoerente. Nenhum botão resolve isso. Nenhuma animação de transição conserta um produto que foi projetado por silos que nunca falaram entre si sobre o que o usuário realmente precisa fazer.
A velocidade como anestesia
A cultura de produto contemporânea celebra a velocidade de entrega com uma devoção quase religiosa. “Move fast and break things” tornou-se menos um manifesto de inovação e mais uma licença para negligência intelectual. O ciclo acelerado de sprints cria uma pressão estrutural para que as equipes pulem as etapas de descoberta genuína e partam direto para a solução — porque descoberta leva tempo, e tempo é o recurso mais escasso no vocabulário corporativo moderno.
O paradoxo é que a velocidade de construção de algo errado é o mais caro dos desperdícios. Cada sprint investido num produto que não deveria existir — ou numa funcionalidade que nenhum usuário pediu — é capital humano, técnico e financeiro que jamais retorna. A velocidade só cria valor quando está alinhada à direção correta. Sem isso, ela apenas acelera a chegada ao precipício.
A ilusão dos números que crescem
Há uma categoria específica de produto que é, talvez, a mais perigosa de todas: o produto com métricas saudáveis e usuários insatisfeitos. É o produto que otimizou seus KPIs de negócio ao custo da integridade da experiência. Ele cresce no curto prazo porque encontrou formas engenhosas — e frequentemente desonestas — de inflar os números que o mercado monitora.
Taxa de abertura de e-mail alta porque o assunto é clickbait. Tempo de sessão elevado porque o fluxo de saída é deliberadamente difícil. Taxa de conversão otimizada porque os padrões de cancelamento estão enterrados em menus de terceiro nível. Esses produtos não estão crescendo — estão extraindo. E extração é uma estratégia com data de vencimento.
O que medir antes de medir conversão
A pergunta mais importante que uma equipe de produto pode fazer não é “quantos usuários converteram?” mas “o que os usuários que ficaram vieram buscar, e encontraram?” Existe uma hierarquia de fidelidade que a maioria dos dashboards ignora. Antes de medir retenção, é necessário medir resolução: o usuário conseguiu completar a tarefa que motivou sua visita? Antes de medir tempo de sessão, é necessário medir satisfação da sessão: o tempo despendido produziu valor para quem o investiu?
Produtos que respondem afirmativamente a essas perguntas não precisam de dark patterns para reter usuários. Eles retêm porque são genuinamente necessários — e essa é a única forma sustentável de crescimento que existe.
Quando o designer entra tarde demais
Em muitas organizações, o designer é convocado quando o produto já está definido. A arquitetura foi decidida, os fluxos foram mapeados em planilhas por product managers, os casos de uso foram priorizados pelo negócio — e ao designer cabe apenas “dar uma cara” para o que já existe. Esse modelo de trabalho não produz produtos excepcionais. Produz produtos cosmeticamente adequados que carregam, sob a superfície polida, todas as decisões ruins que foram tomadas antes de qualquer pixel existir.
O design de produto, em sua acepção mais honesta, é uma disciplina de pensamento antes de ser uma disciplina de execução. Designers que participam desde a fase de descoberta — questionando premissas, mapeando modelos mentais, propondo frameworks conceituais — constroem produtos fundamentalmente diferentes daqueles que chegam apenas para prototipar o que outros já decidiram.
A competência invisível: saber o que não construir
O trabalho mais importante que uma equipe de produto pode fazer raramente aparece num portfólio. Não tem screenshot, não tem case de Behance, não tem animação de transição para mostrar. É o trabalho de decidir o que não será construído — e por quê.
Cada funcionalidade que não existe num produto é uma decisão que alguém tomou. As melhores equipes do mundo são extraordinariamente disciplinadas em dizer não: não a funcionalidades que não foram validadas, não a fluxos que adicionam complexidade sem adicionar valor, não a soluções que resolvem o problema de negócio ao custo do problema do usuário. O produto mais elegante que uma equipe pode entregar é, muitas vezes, menor do que o produto que foi solicitado.
A conclusão que precede o início
Existe uma inversão necessária na forma como pensamos sobre qualidade em produto digital. Antes de perguntar “a interface está bem desenhada?”, precisamos perguntar “o produto deveria existir nessa forma?” Antes de iterar sobre o onboarding, precisamos questionar se a complexidade que esse onboarding tenta mitigar é inerente ao domínio ou é uma complexidade acidental que nunca deveria ter sido criada.
O erro invisível não é um problema de execução. É um problema de premissas. E premissas não aparecem em nenhum teste de usabilidade, em nenhuma métrica de funil, em nenhuma revisão de design. Elas estão enterradas nas conversas que a equipe não teve, nas pesquisas que foram substituídas por opiniões, nas decisões que foram tomadas porque havia um prazo — não porque havia clareza.
Produtos excepcionais não nascem de equipes que executam melhor. Nascem de equipes que pensam com mais honestidade sobre o problema antes de escrever a primeira linha de código ou desenhar o primeiro frame. O design começa muito antes do design. E é precisamente aí que a maioria dos produtos já está perdida.
