Não é uma lista de soft skills. Os instintos específicos que uma base em design constrói, onde são genuinamente úteis no trabalho de produto, e o único hábito que tive de desaprender por completo.
Gestão de ProdutoUX DesignPensamento VisualPessoal
7 min de leitura
A maioria dos artigos sobre PMs com background em design diz coisas como "trazes empatia" e "pensas no utilizador". Não é errado, mas não é a parte interessante. Isso é o mínimo. Qualquer PM que não pense no utilizador não está a fazer o trabalho.
O que é mesmo interessante são os instintos específicos e treinados que vêm de anos a fazer design. Alguns transferem-se bem para a gestão de produto e tornam-se verdadeiras vantagens. Outros criaram hábitos que tive de desfazer deliberadamente. Este é o meu relato honesto de ambos.
Vantagem Um
A maioria dos PMs não sabe esboçar, e nota-se
Não esboçar no sentido artístico. Esboçar no sentido de "pegar num caderno numa reunião e desenhar como o fluxo funcionaria". Depois de anos de design, pensar visualmente torna-se um modo por defeito. Não descreves um layout em palavras, desenha-lo. Não explicas uma jornada de utilizador em prosa, fazes um diagrama dela.
No trabalho de produto, isto revela-se desproporcionalmente útil. Quando uma discussão sobre uma nova funcionalidade fica abstrata, a forma mais rápida de alinhar a sala é pôr algo visível num quadro. Quando escreves uma spec, um wireframe tosco comunica restrições que um parágrafo de texto deixa ambíguas. Quando revês uma proposta de engenharia, um diagrama de fluxo rápido apanha edge cases que a lógica pura falha.
O valor não está na arte do desenho. Ninguém quer saber se as caixas estão direitas. O valor está no hábito de externalizar o pensamento visualmente, o que força uma especificidade que a descrição verbal não exige. Não consegues desenhar um design vago.
O pensamento visual não é uma soft skill. É um instrumento de precisão. Quando desenhas algo, cada ambiguidade torna-se um espaço em branco que tens de preencher.
Vantagem Dois
Lês um design antes de ele te ser explicado
Depois de anos a rever, criticar e iterar trabalho de design, algo muda na forma como percecionas interfaces. Deixas de ver ecrãs e começas a ver decisões. A colocação de um botão não é só a colocação de um botão; é uma hipótese sobre atenção e hierarquia. Um empty state não é uma lacuna a preencher; é uma oportunidade aproveitada ou perdida.
Hierarquia visual
Notas imediatamente se a ação mais importante de um ecrã não carrega o maior peso visual. Consegues dizer especificamente porquê (rácio de contraste, tamanho, posição, espaço em branco), não só que algo está mal. Essa especificidade torna as revisões de design realmente úteis em vez de vagas.
Affordance e custo de interação
Anos de design ensinam-te a sentir a fricção numa interface. Um fluxo multi-passo que podia ser colapsado. Um formulário que pede informação antes de ganhar a confiança necessária para a dar. Um padrão de navegação que funciona no desktop e parte no mobile. Estes registam-se como problemas específicos, não como mal-estar genérico.
Reconhecimento de padrões entre produtos
Um designer que trabalhou em vários produtos constrói uma biblioteca mental do que funciona e do que não funciona em diferentes contextos. Ao avaliar um novo design, estás a compará-lo com padrões que viste ter sucesso e falhar, o que é mais rápido e mais específico do que raciocinar a partir de princípios de raiz de cada vez.
Isto importa mais nas revisões de design, onde a função do PM não é redesenhar o trabalho mas apanhar problemas funcionais antes de irem para produção. Feedback vago ("isto parece desajeitado") manda o designer adivinhar o que corrigir. Feedback específico ("a ação primária está escondida abaixo da dobra no mobile porque a imagem de destaque a empurra para fora do alcance do polegar") corrige-se numa tarde.
Vantagem Três
O texto é uma decisão de design
Esta leva anos à maioria dos PMs a interiorizar. Num background de design, aprendes cedo que as palavras fazem parte do layout. A etiqueta de um botão muda a carga cognitiva de o clicar. O tom de uma mensagem de erro determina se um utilizador frustrado tenta de novo ou desiste. O texto do empty state numa conta nova é, por vezes, o momento de onboarding de maior alavancagem do produto.
Etiquetas de botões
"Submeter" e "Enviar a minha mensagem" descrevem a mesma ação. Uma diz ao utilizador o que o sistema faz; a outra confirma o que o utilizador está a fazer. A segunda converte melhor porque resolve a ambiguidade no momento do compromisso. Os designers aprendem isto com testes A/B e testes com utilizadores. A maioria dos PMs aprende-o muito mais tarde, se aprender.
Mensagens de erro
"Ocorreu um erro" não é uma mensagem. É a ausência de uma. Uma boa mensagem de erro nomeia o que correu mal, porque importa e o que fazer a seguir, em linguagem simples, sem culpar. O trabalho de design obriga-te a escrevê-las sob restrição, o que constrói o músculo depressa. A engenharia trata muitas vezes as mensagens de erro como notas de developer que escaparam para produção.
Empty states
O ecrã que um novo utilizador vê antes de ter feito o que quer que seja é um dos momentos mais importantes do onboarding. A maioria dos produtos trata-o como pensamento posterior, uma caixa cinzenta com "Ainda sem dados". Os PMs com formação em design reconhecem-no como a primeira oportunidade de mostrar ao utilizador para que serve o produto e tornar a primeira ação óbvia e de baixa fricção.
Prompts de onboarding
A primeira coisa que um produto diz a um utilizador define o registo de tudo o que se segue. Formal ou amigável, direto ou exploratório, confiante ou pedinte de desculpas. Não são só preferências de tom. Criam expectativas sobre como o produto se vai comportar, que o utilizador leva para cada interação seguinte.
O texto não é o que acrescentas depois de o design estar pronto. Faz parte do design. Os PMs que percebem isto entregam melhor onboarding, interfaces mais claras e menos tickets de suporte.
Vantagem Quatro
Consegues nomear o que está mal, com precisão
Há uma versão de feedback de design que é pior do que nenhum feedback: "Não sei, simplesmente não me soa bem." Um designer que recebe essa nota tem de adivinhar o que corrigir. Faz alterações. Mostra de novo. O PM diz "mais perto, mas ainda há qualquer coisa". Este ciclo é caro, desmoralizante e normalmente acaba com o designer a desistir de perceber a intenção do PM e a produzir variações até uma colar.
Um background de design quebra este ciclo. Não porque sabes mais do que o designer (não sabes, e o instinto de redesenhar em vez de orientar é algo que tens de suprimir ativamente) mas porque tens vocabulário para os problemas específicos que estás a ver.
01
Nomeia o problema específico, não o sentimento
Em vez de "isto parece pesado de mais", podes dizer "o body copy está a 16px numa baseline grid de 14px com line-height apertado, por isso está visualmente denso e vai cansar os leitores em mobile". É uma coisa clara a corrigir, não um convite a repensar a página toda.
02
Separa preferência estética de preocupação funcional
Os PMs com formação em design aprendem a distinguir "eu teria feito isto de forma diferente" (irrelevante) de "isto cria um problema funcional para o utilizador" (a única coisa que importa). A maioria dos PMs confunde as duas e acaba a redirecionar designers com base em gosto pessoal, o que destrói a confiança depressa.
03
Enquadra o feedback como restrição, não como receita
"O CTA precisa de ser mais visível no mobile" dá ao designer um problema para resolver. "Põe o botão azul e maior" tira-lhe a resolução do problema. O primeiro produz melhores resultados e uma melhor relação de trabalho. Saber a diferença (e ter a contenção para ficar na tua faixa) é algo que a experiência de design ensina pelo fracasso antes do sucesso.
A Parte Difícil
A limitação honesta
Esta é a parte que a maioria dos artigos "de design para PM" salta. Os mesmos instintos que tornam os backgrounds de design úteis também criam um modo de falha específico, e vale a pena ser explícito sobre ele.
Os designers são treinados para se importar com a qualidade ao nível do detalhe. O espaçamento está 2px desalinhado. O easing da animação não está bem. O ícone não combina com a linguagem visual do resto do produto. São preocupações legítimas num contexto de design, onde a qualidade sinaliza fiabilidade e o trabalho de detalhe acumula ao longo do tempo num produto que parece pensado.
Na gestão de produto, esse instinto pode tornar-se um passivo.
Três instintos de design que jogam contra ti como PM
Segurar uma funcionalidade até estar polida. No design, entregar algo imperfeito reflete-se na tua arte. Em produto, entregar algo imperfeito é como descobres se a ideia subjacente vale a pena refinar. O instinto de polir atrasa a aprendizagem. O hábito a ignorar é "isto não está pronto"; a pergunta honesta é "pronto para quê, exatamente?".
Resolver primeiro os problemas visuais. Os backgrounds de design criam um viés para o visível. Mas os problemas de produto mais importantes são muitas vezes invisíveis: a API que torna uma funcionalidade tecnicamente viável, o problema de qualidade de dados que torna enganadora uma funcionalidade de personalização, a restrição operacional que determina se um processo escala. Se o visual está limpo e a infraestrutura está partida, decoraste um problema.
Subvalorizar a complexidade de engenharia. Os designers interagem muitas vezes com a engenharia sobretudo como função de entrega, quem constrói o que o design especifica. Os PMs têm de segurar o modelo do utilizador e o modelo de engenharia ao mesmo tempo, e os trade-offs entre eles são o trabalho. Os instintos de design não treinam para isto; às vezes jogam ativamente contra, ao apresentar soluções tecnicamente caras como obviamente corretas só por serem visualmente elegantes.
O background de design é uma vantagem no trabalho de produto, mas só se souberes que instintos seguir e quais pôr de lado. Os que tens de pôr de lado são normalmente os que parecem mais naturais, o que os torna os mais difíceis de apanhar.
Se vens de um background de design e queres mapear as tuas competências face a funções de PM e adjacentes, o TryCareerMatch faz exatamente isso. Gratuito, sem registo.