PM e Designer, uma história de amor

Pedro Torres
Passei Direto Product and Engineering

--

Deixa eu tentar adivinhar algumas coisas sobre você. Você se preocupa com seus usuários, se preocupa em garantir que eles estão entendendo como usar seu produto e se seu produto está acabando com a dor deles. Você acompanha o que seus concorrentes estão fazendo, até se baseia neles quando vai começar uma atividade. Você passa boa parte do seu dia conversando com vários stakeholders e garantindo que todos estão na mesma página. Acertei?Viu como eu não precisei saber se você era PM ou Designer?

PMs e Designers possuem uma interseção muito grande e tem, basicamente, o mesmo objetivo: entregar um produto de qualidade que satisfaça o usuário. Ainda assim (ou talvez por causa disso), PMs e Designers de um mesmo squad/time muitas vezes não sabem trabalhar em conjunto e isso é bem ruim pra o time como um todo.

Aqui vão algumas dicas e boas práticas que os dois lados podem fazer para um melhor relacionamento!

PM e Designer são pares

Essa é a parte mais importante e quase pré-requisito pra os demais pontos poderem acontecer. Não existe um acima do outro. As duas áreas andam em conjunto. Uma hora vai ser preciso tomar uma decisão mais estratégica ou de negócios, já na outra uma decisão mais de usabilidade ou experiência. Por mais que em cada caso exista o papel principal, tanto PM como Designer precisam discutir juntos e entender a decisão. Ninguém trabalha sozinho.

Designer não só desenha

Um erro comum do PM é achar que ele deve chegar com a solução pronta e só jogar pra o designer fazer as telas. Além de apresentar uma solução pobre (porque só o PM pensou), ele ainda vai estar subutilizando o Designer, deixando-o desmotivado.

O PM deve olhar a visão mais a longo prazo do Roadmap, que foi definido em conjunto com a liderança de Design. O PM deve ir trocando as primeiras ideias com os stakeholders e entendendo melhor o problema que querem resolver. Nesse momento o Designer deve ser envolvido superficialmente pra saber quais são as próximas inciativas que estão pra chegar e já estar por dentro.

Quando essas inciativas chegam (o Near Future) é o momento de aprofundar o Product Discovery. Nessa etapa é essencial a participação do Designer! É ele que vai ser responsável pelas pesquisas, teste de usabilidade, benchmarking, prototipação e etc. Claro que o PM também deve estar envolvido. Ele divide boa parte da responsabilidade dos processos de Discovery. A multidisciplinaridade das duas áreas vai aumentar as chaces de chegar numa melhor solução para o problema

O PM não concentra as decisões

Por mais que o processo de Discovery tenha sido muito bem feito, ainda podem existir furos que só são percebidos no processo de Delivery, principalmente pelos próprios desenvolvedores. Nesse momento, alguém precisa tomar a decisão e resolver o problema levantado.

Já vi times onde qualquer decisão que o dev tomava junto com o designer, precisava necessariamente ser aprovada pelo PM. Ou pior, o PM servia de pombo correio pra levar a dúvida do dev ao designer e trazer de volta a decisão. Isso burocratiza muito o Delivery e sobrecarrega, o já sobrecarregado, PM.

Quando o PM e Designer do time estão bem alinhados, o dev pode ir diretamente em qualquer um dos dois e ter sua dúvida respondida mais rápido. Tanto o PM como o Designer podem repassar a dúvida um pra o outro quando acharem que a outra pessoa vai ter mais prioridade pra responder, não precisando “confirmar” a decisão que ela tomou, apenas confiando que foi a melhor. Essa confiança só acontece porque os dois estão na mesma página.

Não seja flanelinha de layout

“Dado pessoas suficientes em uma sala, um designer nunca vai agradar a todos”. Essa frase é muito verdade! O que ela quer dizer é que nunca um layout vai satisfazer todas as pessoas, incluindo você. Então, quando for dar um feedback não simplesmente diga frases como “eu não gostei”, muito menos “move esse botão mais pra cá” ou “muda a cor desse texto”. Não seja o famoso flanelinha de layout.

Em vez disso, prefira frases como “Esse fluxo pode estar confuso para o usuário” ou “Talvez possa ser melhor dar mais ênfase nessa parte para deixar mais claro”. Procure sempre embasar seus argumentos, mire seus feedbacks no problema, não na solução. Indague se os princípios de UX estão sendo seguidos. Assim você vai conseguir passar melhor a sua opinião e o designer vai conseguir trabalhar melhor em cima do problema, sem ser microgerenciado.

E aí, como é o relacionamento entre você e seu PM/Designer? Você concorda com esses pontos? Quais os processos que vocês aplicam no seu dia-a-dia que dão certo? Onde vocês precisam melhorar?

--

--