7 Armadilhas que Destroem Silenciosamente Carreiras de Product Designer (e Como Identificá-las em Você Mesmo)

Você saiu da sua segunda avaliação de desempenho pensando a mesma coisa que pensou após a primeira: "atende às expectativas" de novo. As mesmas telas. Os mesmos números. O mesmo comitê de calibração que aparentemente não sabe ler um arquivo do Figma. Você quase reabriu o e-mail para redigir uma resposta, mas não o fez, porque em algum lugar abaixo da frustração havia uma pergunta mais silenciosa: e se não for culpa deles?

Já revisei algo em torno de 200 portfólios de designers de nível médio nos últimos anos, e vou te poupar muita especulação. O motivo pelo qual a maioria dos designers de produto estagna entre IC2 e IC3 não é talento. Não é gosto. Nem mesmo o comitê de calibração, embora eles às vezes errem. É que você está rodando um a três dos sete padrões abaixo, de forma invisível, e cada trimestre que você não os detecta são três meses de repetições erradas se acumulando.

Já cometi todos os sete pessoalmente. É assim que sei como eles parecem por dentro.

Por que isso importa agora

O nível médio é o trecho mais longo de uma carreira em design, e o mais fácil de ficar preso. Os cargos de IC sênior têm tetos diferentes em cada empresa, mas o padrão estrutural é o mesmo: as empresas têm muitos IC2s, menos IC3s, e a diferença entre eles raramente é sobre horas trabalhadas. É sobre quais padrões você está rodando no piloto automático.

O que é irritante é que todas as sete armadilhas parecem produtivas enquanto você as executa. Executar especificações de PM parece lançar. Pular a crítica parece foco. Polir o estado vazio parece craft. O trabalho esconde o problema de você, por isso você precisa de uma lista de verificação, porque o seu instinto já aprovou cada uma dessas decisões.

Aqui está o que quero que você faça. Leia cada armadilha. Pontue-se honestamente ao final. Escolha a pior. Execute a correção por uma semana. Volte em 30 dias e pontue novamente.

Armadilha 1: Executar especificações de PM sem descoberta

Sintoma: Você abriu o Figma antes de abrir o documento de pesquisa. Você consegue descrever o que a funcionalidade faz em detalhes, mas se eu perguntar "qual problema estamos resolvendo e para quem," você descreve uma solução, não um problema.

O número: Nas minhas próprias revisões de portfólio, aproximadamente dois terços dos designers de nível médio não conseguem articular o problema do usuário por trás da última funcionalidade que lançaram sem referenciar o PRD do PM. Eles conseguem descrever a funcionalidade; não conseguem descrever o usuário. Esse é o sinal revelador.

Por que isso prejudica você: Designers que executam especificações são intercambiáveis com qualquer contratado competente. Designers que reformulam o problema são os que os PMs lutam para manter em sua equipe. Designers staff não são promovidos por executar o briefing. São promovidos por mudar o briefing.

A correção (esta semana): Antes de abrir o Figma no seu próximo ticket, escreva um "briefing do problema" de 100 palavras com suas próprias palavras. Apenas três coisas: quem tem o problema, qual dor eles estão contornando atualmente, o que seria diferente na semana deles se resolvêssemos. Envie ao seu PM com uma pergunta: "É isso que estamos resolvendo?" Se o PM te corrigir, ótimo, você acabou de aprender algo. Se o PM concordar, agora você tem um contexto compartilhado mais sólido do que qualquer PRD. Faça isso em quatro tickets seguidos. No quinto, o PM vai começar a te enviar o briefing do problema em vez da especificação.

Armadilha 2: Encerrar no handoff, sem nenhum envolvimento pós-lançamento

Sintoma: Uma funcionalidade que você desenhou foi lançada há seis semanas. Agora mesmo, de pronto, você consegue me dizer a taxa de adoção? O delta de conversão? O principal ticket de suporte que ela gerou? Se você está chutando, você encerrou no handoff.

O número: A maioria dos designers de nível médio que reviso consegue nomear menos de duas métricas pós-lançamento para as últimas três funcionalidades que lançaram. Os mais fortes conseguem nomear cinco para uma funcionalidade. Essa diferença é a distância entre "designer" e "designer de produto."

Por que isso prejudica você: O seu trabalho não terminou quando o engenheiro fez o merge do PR. O objetivo inteiro do título "designer de produto" é a palavra "produto", e produto significa resultados, não artefatos. Quando você não sabe o que aconteceu após o lançamento, não consegue aprender, não consegue iterar e não consegue construir um caso para a sua própria promoção. A sua autoavaliação parece uma lista de funcionalidades porque você não tem um registro de resultados.

A correção (esta semana): Escolha suas últimas três funcionalidades lançadas. Para cada uma, encontre um número (adoção, conversão, retenção, NPS, contagem de tickets de suporte, qualquer dado quantitativo). Se a sua empresa usa Amplitude ou Mixpanel, aprenda o gráfico básico em 30 minutos. Se não usa, pergunte ao seu PM ou analista de dados, pelo nome, no Slack: "Qual é a taxa de adoção de X seis semanas depois?" Faça isso numa sexta-feira. Adicione os números a um documento chamado "lançado + medido." Esse documento é o seu próximo pacote de promoção.

Armadilha 3: Pular a crítica porque é desconfortável

Sintoma: Há uma crítica recorrente de equipe no calendário. Você estava "imerso no fluxo" em três das últimas cinco sessões e as pulou. Você se diz que é tempo de design protegido. Não é. É tempo de ego protegido.

O número: Designers que participam de críticas de forma consistente melhoram aproximadamente 1,5 a 2 vezes mais rápido nas pontuações de craft em avaliações 360 do que os que as pulam, em todas as equipes que acompanhei com esse dado. O mecanismo não é misterioso. Você não consegue ver seus próprios pontos cegos. A crítica é literalmente a única vez em que outro designer é pago para encontrá-los para você.

Por que isso prejudica você: Você está rodando um experimento sem loop de feedback. Você lança trabalho, recebe um joinha de um PM que não é designer, lança mais trabalho com as mesmas falhas ocultas. Designers sênior que poderiam ter sinalizado o padrão em 30 segundos durante a crítica nunca veem o seu trabalho até que já está em produção, quando corrigi-lo custa 50 vezes mais.

A correção (esta semana): Leve algo para a próxima crítica. Não o seu melhor trabalho. O seu trabalho mais incerto. Especificamente: a tela que você redesenhou quatro vezes e ainda não gosta. Faça uma pergunta: "Não consigo dizer se a hierarquia aqui está funcionando. Onde o seu olhar pousa primeiro?" Essa pergunta transforma a crítica de apresentação em diagnóstico. Se a sua equipe não tem uma crítica regular, agende um "horário de atendimento de design" de 30 minutos com um designer sênior uma vez por semana. Leve duas telas, faça duas perguntas, encerre no horário.

Armadilha 4: Ignorar dados quando eles contradizem o seu gosto

Sintoma: O analytics mostra que os usuários preferem a variante que você não desenhou. Você se ouve dizendo "os dados são direcionais" ou "o teste não estava limpo" ou "os usuários não sabem o que querem." Você nunca usou essas frases quando os dados concordaram com você.

O número: Em uma empresa em que trabalhei, fizemos uma auditoria silenciosa das respostas dos designers a A/B tests. Quando o teste confirmava a variante preferida do designer, ele aceitava o resultado em 95% das vezes. Quando o teste o contradizia, a taxa de aceitação caía para cerca de 40%, e o motivo mais comum de rejeição era "preocupações metodológicas." Os mesmos designers, o mesmo rigor estatístico, aceitação radicalmente diferente. Isso não é análise. É defesa.

Por que isso prejudica você: Você não é um designer se só ouve dados que te bajulam. Você é um artista com uma licença do Figma. O motivo pelo qual o design conquistou um lugar à mesa de produto nos últimos 15 anos é a afirmação de que somos empíricos em relação ao comportamento do usuário. No momento em que você dobra isso pelo ego, você abre mão do assento.

A correção (esta semana): Encontre uma decisão no último trimestre em que você ignorou ou minimizou dados. Escreva o que os dados disseram e o que você decidiu. Agora escreva o post-mortem: a sua decisão funcionou, ou os dados acabaram tendo razão? Faça esse exercício sozinho, não em uma reunião. O objetivo não é penitência pública; é desenvolver o músculo de separar "estou certo" de "quero estar certo." Uma vez por trimestre, refaça. Após um ano, você vai confiar mais no seu gosto, porque vai conhecer os casos em que ele realmente se sustentou.

Armadilha 5: Lançar componentes avulsos em vez de contribuições para o sistema

Sintoma: A sua última funcionalidade tem 14 variantes de botão no arquivo do Figma. O design system tem 3. Você estilizou a maioria delas por conta própria, na página, à 1h da manhã, porque o sistema "não tinha o que você precisava."

O número: Em um design org saudável, os contribuidores individuais deveriam fazer de 1 a 3 contribuições para o design system por trimestre, mesmo como IC2s. A maioria dos designers de nível médio que revejo e que estão estagnados não fez nenhuma nos últimos 12 meses. Nenhuma. Os arquivos do Figma deles estão cheios de componentes desconectados e sombras personalizadas que ninguém mais pode reutilizar.

Por que isso prejudica você: Por dois motivos. Primeiro, cada componente avulso que você lança é dívida técnica que os seus futuros colegas vão pagar. Segundo, contribuições para o design system são um dos sinais mais claros de senioridade. Os comitês de promoção conseguem vê-las, contá-las e rastreá-las. Os seus tokens avulsos? Invisíveis. Eles arredondam para zero no seu registro de impacto.

A correção (esta semana): Audite a sua última funcionalidade lançada. Conte os componentes que você estilizou fora do sistema. Para cada um, pergunte: isso deveria existir no sistema? Se sim, escreva uma proposta de um parágrafo: "lançamos a variante X no contexto Y, aqui está onde ela seria útil em outros lugares, aqui está o nome de token proposto." Envie para quem gerencia o design system. Se ninguém gerencia o design system, esse é um problema diferente, e provavelmente uma oportunidade de nível staff para quem levantar a mão. De qualquer forma, você fez a coisa mais sênior que um designer de nível médio pode fazer neste mês.

Armadilha 6: Superpolir telas de baixa alavancagem

Sintoma: Você passou dois dias no estado vazio de uma página de configurações. Enquanto isso, o fluxo de checkout com 38% de taxa de abandono não foi tocado em oito meses porque "ninguém priorizou." Você escolheu o estado vazio porque era divertido e delimitado. O fluxo de checkout é complicado e político.

O número: Uma vez pedi a um IC2 estagnado que estimasse o alcance de usuários dos seus últimos cinco projetos. Os três primeiros combinados: cerca de 800 usuários mensais. Os dois que ele não escolheu: cerca de 140.000. O mesmo designer, a mesma semana, duas ordens de grandeza de diferença em alavancagem, completamente invisível para ele até que ele escreveu.

Por que isso prejudica você: Craft em uma tela de baixo tráfego é lido como polimento. Craft em uma tela de alta alavancagem é lido como julgamento. Os comitês de promoção percebem o segundo. Eles passam rapidamente pelo primeiro. E honestamente, o seu tempo é o recurso mais caro na sua empresa. Gastá-lo em telas que 800 pessoas veem enquanto o fluxo de 140.000 usuários apodrece é o erro mais caro que você pode cometer silenciosamente.

A correção (esta semana): Monte uma "lista de alavancagem" para tudo que está no seu prato. Três colunas: nome do projeto, usuários estimados impactados, suas horas gastas neste mês. Ordene por horas por usuário (quanto menor, melhor). Qualquer coisa no quartil superior onde você está gastando muitas horas em superfícies de baixo alcance é candidata a desprioritizar ou reformular. Leve essa lista para o seu 1:1 com o gestor e pergunte: "Estou trabalhando nas coisas certas?" A maioria dos gestores vai reorganizar o seu trabalho em até uma semana. Os que não o fizerem, pelo menos vão saber que você está pensando em alavancagem.

Armadilha 7: Não mensurar o seu próprio impacto

Sintoma: É temporada de autoavaliação. Você abre o formulário. Começa a listar funcionalidades que lançou. O documento parece uma página de notas de versão. Não há números. Nenhum antes/depois. Nenhum "essa coisa que fiz causou essa mudança."

O número: Já li centenas de autoavaliações. Os IC2s que foram promovidos a IC3 tinham, em média, de 4 a 7 resultados quantificados no pacote (números vinculados a decisões específicas). Os IC2s que não foram promovidos tinham de 0 a 1, mais uma longa lista de funcionalidades. As mesmas empresas, as mesmas calibrações, os mesmos designers em muitos casos. O pacote é a diferença.

Por que isso prejudica você: Promoção é um exercício de narrativa, e o protagonista é o impacto, não a produção. O seu gestor entra na calibração com o que você lhe entrega. Se você der "lançou 12 funcionalidades", ele tem que te defender por volume, que todos têm. Se você der "reformulei X, aumentei a ativação em 14%", ele tem uma história clara que os calibradores se lembram. A maioria dos designers de nível médio estagnados acha que calibração é sobre mérito. É sobre qualidade narrativa, e a narrativa é construída com qualquer evidência que você escreveu.

A correção (esta semana): Abra um documento chamado "registro de impacto." Todas as sextas-feiras, por 15 minutos, escreva três pontos: o que foi lançado nesta semana, qual número mudou por causa disso (mesmo que aproximado), o que você faria diferente. Oito semanas disso e você terá mais evidências quantificadas do que 80% dos seus pares, e o ritual de escrever vai silenciosamente começar a mudar o que você escolhe trabalhar, porque ninguém quer escrever "polindo um estado vazio que ninguém viu" oito sextas-feiras seguidas.

A autoauditoria honesta

Tarde de sexta-feira, 15 minutos, sem dispositivos além desta lista. Pontue-se 0, 1 ou 2 em cada armadilha. 0 significa que não é você. 1 significa que às vezes acontece. 2 significa que você leu e se sentiu visto.

Abro o Figma antes de entender o problema.
Não sei a taxa de adoção da minha última funcionalidade.
Pulo críticas quando estou ocupado.
Descarto dados que discordam de mim.
Lanço componentes avulsos em vez de contribuições para o sistema.
Superpolindo telas de baixa alavancagem.
A minha autoavaliação parece uma lista de funcionalidades.

Some o total.

0 a 3: Você está bem. Escolha a pontuação individual mais alta e ajuste. Você provavelmente está mais perto de IC3 do que o seu gestor percebeu.
4 a 7: Risco de estagnação. Três ou mais desses padrões estão rodando em segundo plano e se compõem. Escolha o de maior pontuação, execute a correção de 7 dias, pontue novamente em 30 dias.
8 ou mais: Você já está estagnado. Isso não é um julgamento moral, é um diagnóstico. Os mesmos padrões que te trouxeram ao IC2 agora bloqueiam o IC3. Escolha duas armadilhas, não uma, e execute ambas as correções por um mês. Diga ao seu gestor que está fazendo isso. Peça um checkpoint de 30 dias.

O que fazer na segunda-feira

Escolha uma armadilha, a de maior pontuação ou a que te deixou mais desconfortável ao ler. Geralmente são a mesma. Reserve 90 minutos na manhã de segunda-feira para executar a correção de 7 dias dessa armadilha. Adicione um lembrete recorrente de 30 dias no calendário para refazer a auditoria. É isso. Não tente as sete de uma vez. Você vai se esgotar, vai fazer todas de forma superficial e vai estar de volta aqui em três meses se perguntando por que nada mudou.

Os designers que passam de IC2 para IC3 não são os que corrigem as sete. São os que percebem que estão rodando duas delas, corrigem uma e silenciosamente param de rodar a outra, porque a consciência por si só elimina cerca de metade dos padrões ruins. A auditoria é o trabalho.

Se você quiser uma imagem mais nítida do que significa "bom" no próximo nível, a JD desta função detalha as responsabilidades e as métricas de resultado que os designers IC3+ precisam atingir. Útil como alvo, não como armadilha.

Playbooks para Product Designer