Depois de trabalhar na indústria de design por um período de tempo significativo, percebi que fazer designs não é muito inteligente. Pode-se chegar a algumas soluções muito boas com base em sua experiência passada e ser complacente com suas habilidades de design. No entanto, a verdadeira luta começa quando temos que convencer todos os PMs envolvidos, gerentes de design, engenheiros, etc. sobre nossas decisões para que os projetos possam realmente ver a luz do dia.
Em uma ocasião, lembro-me de apresentar meus projetos aos stakeholders internos para seguir a versão x , porque parecia mais moderno. O stakeholder olhou com ceticismo e perguntou:
“O que você quer dizer com design moderno?”. Respondi designs modernos como no Airbnb, a interface Medium tendo o mínimo….. Ele interrompeu no meio e questionou que o que é moderno pode não ser moderno para os outros.
E ele estava muito certo, não estava? A verdade é que todo design é subjetivo. O que uma pessoa gosta, outra pessoa pode odiar. Termos como moderno, intuitivo são muito vagos para serem apresentados ao defender seus projetos.
Recentemente li o livro “Articulando decisões de design” de Tom Greever, para entender melhor esse tema. E, neste artigo, eu compartilharia as 10 sugestões (resumidas no final) com base no livro e na minha experiência, que achei que vale a pena incorporar para uma sessão de feedback construtivo:
A. Abordando a declaração do problema
Pode soar muito clichê “Tem clareza na declaração do problema?”. Isso não é algo que estamos acostumados a ouvir no primeiro dia do curso de design? Mesmo assim, depois de ouvir essa frase inúmeras vezes, às vezes ainda me sinto desviado da declaração original do problema. Quando começamos a trabalhar em uma declaração de problema, essas são tantas ideias que começam a preencher “vamos fazer isso”, “oh espere, vamos tentar isso”… Essas ideias podem estar genuinamente melhorando a experiência do produto, mas estão alinhadas com o espaço do problema original? Temos que estar cientes dos engenheiros e do cronograma dos PMs, e essas ideias magníficas podem ser colocadas na lista de pendências de design por enquanto.
Para as vitórias imediatas, precisamos nos alinhar com a declaração do problema. E para conseguir isso, precisamos nos perguntar constantemente “Que problema mensurável estou tentando resolver com isso?”, “Quem são os usuários-alvo e seu comportamento atual?”, “Temos algum tipo de dados em torno do espaço do problema ?”, “qual é o resultado comercial esperado?”, “Como os projetos podem ser testados e verificados?”
B. Empatia com as partes interessadas
1. Entenda o modo de pensar do público: Assim como é preciso ter empatia com os usuários para um produto de sucesso, é preciso ter empatia com as partes interessadas para uma apresentação bem-sucedida. Lembro-me de conversar com um dos líderes de produto para seguir a fonte serif sobre sans-serif nos designs do blog e destacar o aspecto de legibilidade da fonte. Percebi sua falta de interesse nesse tópico e percebi que ele estava mais preocupado com o lado comercial do que com a experiência do usuário. Então, da próxima vez, ao fazer um pitch para ele, eu tenderia a apresentar de uma maneira que destacasse o aspecto comercial. Para resumir, não se deve ter o mesmo conteúdo ao apresentar para as diferentes partes interessadas. Um gerente de produto pode estar mais inclinado para o lado comercial, um gerente de design mais para o usuário, um gerente de engenharia para o lado do desenvolvimento e assim por diante.
2. Antecipar Reações: Com base na interação anterior com as pessoas com quem você está trabalhando, você deve ser capaz de antecipar como elas reagirão aos seus projetos. Por exemplo, um dos pontos que sempre são levantados em nossa sessão de crítica de design é como os designs funcionariam em diferentes moedas e dispositivos como “Os designs serão suficientes para valores de moeda vietnamita (que são super longos)?”, “Como seria olham em aparelhos menores?”, etc… Então, costumo preparar as lâminas de acordo, antecipando a reação o máximo que posso.
3. Evite jargão de design, a menos que seu público esteja familiarizado com ele: Uma das declarações de problema em que eu estava trabalhando era melhorar a disponibilidade do elemento de pesquisa principal. Eu estava tão acostumado com o termo “affordance” que não percebi que os outros poderiam não estar cientes disso. Na sessão de feedback, continuei usando esse termo várias vezes. E após o término da apresentação, um desenvolvedor perguntou o significado de affordance? Senti uma pontada de culpa ao imaginá-lo se perdendo durante a apresentação. Em retrospectiva, a apresentação faria muito sentido se eu tivesse comunicado antecipadamente o significado de affordance ou não tivesse usado o termo.
4. Lembre-se de que nem tudo está sob seu controle: em uma das empresas iniciantes em que trabalhei, tivemos que obter a aprovação do CTO antes de poder passar para o ciclo de desenvolvimento. E com o tempo, senti que o processo de aprovação do projeto era falho porque isso dependia do temperamento dele. E pode acontecer que, embora você esteja apresentando o melhor do seu trabalho, ele seja rejeitado porque ele teve um dia muito difícil ou perdeu um possível negócio. Parece estranho, não é? A dura verdade é que sempre há coisas que influenciam o comportamento das pessoas das quais não temos conhecimento e estão além do nosso controle. Quanto mais vezes nos lembrarmos disso, melhor estaremos.
C. Ensaio geral
O sucesso depende de como as partes interessadas percebem os projetos, e não de como você percebe esses projetos. Seus projetos podem ser revolucionários, mas um vendedor agressivo e bem falado tem mais probabilidade de obter suporte se puder lançá-lo bem.
É importante dedicar um tempo considerável para praticar como comunicar as decisões de design adicionando uma narrativa narrativa a elas. Não se pode simplesmente ir e apresentar “Ei, este é o projeto proposto. Dê-me feedback.” Tem que comunicar uma história. Ele deve destacar o processo pelo qual você passou enquanto criava as soluções. Quais foram os desafios técnicos, limitações de design, resultados de benchmarking de concorrentes, exploração inicial, a lógica por trás dessa abordagem específica, etc? E uma vez feito com a apresentação, faça uma breve leitura em voz alta deles. Durante o passo a passo, muitas vezes costumo descobrir que a ordenação de alguns slides precisa ser modificada para um melhor fluxo de fala, ou algumas explorações precisam ser colocadas de lado para terminar no tempo previsto.
D. Apresentando projetos
Aqui vem a parte mais crucial, o momento em que você apresenta os designs para seus stakeholders:
1. Introdução e configuração de contexto
- Declare o objetivo: A ideia aqui é configurar o contexto, destacar a declaração do problema, o ponto de dor do usuário e o resultado comercial esperado.
- Mostrar uma linha do tempo: destaque em qual fase do projeto você está trabalhando no momento. As métricas da linha do tempo podem variar dependendo do projeto.
- Resuma a última reunião : Muito provavelmente, as pessoas não se lembrariam do conteúdo da última reunião. Portanto, dedique algum tempo para mencionar os pontos importantes que foram levantados anteriormente.
- Especifique o feedback que você precisa : Isso é muito importante. Eu experimentei muitas vezes as partes interessadas dando algum feedback aleatório. Portanto, você deve mencionar o tipo de feedback que está procurando e, às vezes, até explicitamente, o tipo de feedback que não está procurando. Apesar disso, se você receber algum feedback fora de contexto, proponha adicioná-lo ao backlog de design que pode ser discutido posteriormente.
2. Defendendo as decisões de design
- Mostrar uma comparação: coloque os designs anteriores e propostos lado a lado para uma comparação rápida.
- Proponha uma alternativa: por mais bons que sejam os designs, muitas vezes vêm com algumas compensações. Portanto, é melhor ter algumas soluções alternativas à mão para mostrar a comparação e por que você acha que o design proposto funcionaria melhor.
- Não confie simplesmente nas telas dos concorrentes: não proponha designs com a lógica de que “é assim que a Apple faz.”, então vamos nos alinhar em torno disso. É bom encontrar inspiração em outros produtos. Mas é mais importante explicar por que essa abordagem funcionaria melhor.
- Use histórias reais: dependendo das partes interessadas, uma vitrine de histórias reais de entrevistas de usuários pode ser ainda mais eficaz do que números e gráficos.
3. Uso do vocabulário
- Evite usar “De uma perspectiva de design.”:
Quando começamos uma frase com “De uma perspectiva de design…” esse tipo de som parece “da minha perspectiva”. E honestamente, as partes interessadas não se importam com sua perspectiva; tudo o que eles se importam é com os usuários ou a perspectiva de negócios. Então, diga “Do ponto de vista do usuário ou do negócio…” - Evite usar “Gostei disso…”. : Novamente, ninguém está interessado em suas preferências pessoais e no que você gosta ou não. As pessoas estão interessadas no que funcionaria e no que não funcionaria com base na usabilidade e eficácia dos designs, então você deve dizer “Isso funcionaria além disso porque…”
E. Concluindo
Você pode ter recebido toneladas de feedback, o que pode até ser esmagador às vezes. Portanto, reserve um tempo para refletir, anote os pontos, declare os próximos passos acordados e compartilhe-os no grupo para visibilidade. Alguns dos pontos podem não estar esclarecidos, então você pode querer agendar uma ligação com a pessoa para melhor entendimento. Além disso, é importante lembrar que nem todos os comentários fariam todo o sentido. É sua responsabilidade filtrar os úteis e improvisar os designs existentes.
Fonte: Medium