O que aprendi no meu primeiro processo de Discovery & Definition em UX
Se você — assim como eu — é Designer e migrou ou está pensando em migrar para a área de Produto, aqui está um artigo recheado dos meus principais insights sobre tocar pela primeira vez as fases de Discovery & Definition de um projeto.
Eu já havia lido documentações, artigos, sabia de muitas teorias e já tinha tocado projetos nas etapas de Develop & Deliver, porém essa foi a primeira oportunidade de mergulhar a fundo num problema e seguir a metodologia do Double Diamond completa, desde o início, agora como Product Designer.
Agora que passou, posso dizer que foi:
- diferente do que idealizei
- uma experiência muuuuuito rica
- um processo que mexeu bastante comigo
Double Diamond? Discovery? Definition? Oi?
Só para deixar todas as pessoas que lerem esse artigo na mesma página: de forma bem superficial, o Double Diamond é um processo de encontrar soluções que se baseia em 4 etapas (Discover, Define, Develop, Deliver).
O que estamos chamando de Discovery & Definition nesse artigo são as primeiras etapas (primeiro diamante), que consistem em entender bem o cenário que o projeto está inserido e fazer a definição do problema para as próximas fases.
Na teoria, a prática é outra
Por mais que a gente leia e estude, quando o cenário da vida real se apresenta, as coisas andam de forma diferente do que planejamos.
Pode chamar de ingenuidade (ou falta de noção da realidade hahaha): eu fiz meu planejamento dessas etapas com tudo que tinha direito — análise de Dados, testes de usabilidade, análise de benchs, dinâmicas com várias pessoas etc. Tudo isso dentro de um prazo limitado, já definido e acordado entre muitos envolvidos (eu ouvi OKRs de final de ano? rs).
A realidade me deu um choque quando perguntei para um colega da área de Dados quanto tempo ele precisaria para me entregar uma análise e descobri que eu teria que ter feito o pedido com um bom tempo de antecedência. Ops. É um clássico achar que o trabalho dos outros é na velocidade da luz enquanto o nosso precisa de etapas e prazos a serem cumpridos bem certinho, não é? Dei mole, eu sei.
Claro que entendi super o lado do meu colega e me dei conta que os dados não iam simplesmente cair no meu colo: eu precisava me aventurar a encontrar os já coletados para entender o que poderia me ajudar no processo de Discovery. Achei que não fosse dar conta, tive que pedir ajuda para o PM do meu squad que tinha mais intimidade com a ferramenta… mas rolou!
A cada informação que eu me deparava, várias outras surgiam como perguntas na minha cabeça e, curiosa como eu sou, queria entender mais e mais. Fiquei bem feliz de ver minha empolgação nessa parte, porque pensei que fosse uma tarefa mais burocrática e menos legal. Acabei entendendo que pra quem tem curiosidade e disposição, os processos que eu nunca tinha feito não eram monótonos e sim instigantes.
Tipo o buraco do coelho da Alice, sabe? Quanto mais fundo você vai, mais você descobre que tem muito mais caminho para seguir.
Ninguém é uma ilha
No começo da minha carreira, como Designer Gráfico (trabalhando em agências), eu me virava super bem criando sozinha. Recebia o briefing, ficava fritando pensando em como solucionar visualmente o que foi pedido e encarava o processo todo comigo mesma, fazendo a entrega completa. Só depois entravam os feedbacks, os ajustes eram feitos e pronto — próxima demanda.
Nos últimos 3 anos atuei na parte de Branding/Marketing na Passei Direto e já senti diferença: agora eu tinha voz ativa desde a concepção dos projetos e ajudava nas decisões. Mas o trabalho da criação visual em si ainda era dessa forma mais solitária. Embora os feedbacks entrassem em várias etapas e me ajudassem muito, na hora de fazer os layouts era só eu e as ferramentas de criação.
Agora em Produto (ainda na mesma empresa 🧡) entendi que precisava do envolvimento de mais pessoas para encontrar as melhores soluções em todas as etapas, afinal, muitas cabeças pensam melhor do que uma só.
Sempre que puder, envolva pessoas! As mais diversas, de preferência.
Consegui fazer uma dinâmica semi-síncrona* para fazer análise heurística de um elemento do produto e foi riquíssimo ter as visões de um UX Researcher, um Product Manager, uma Product Designer de outra Tribo e uma UX Writer. Em outras oportunidades, participei de dinâmicas de criação em conjunto com outros Product Designers e foi muito incrível!
Isso vale não só para ter insights de outras pessoas com outras vivências e experiências, mas também para pedir ajuda quando for necessário. Por exemplo: fiquei sobrecarregada pela ansiedade de achar que tinha que fazer tudo sozinha e foi um aprendizado enorme levantar a mão e pedir auxílio de outras pessoas para encontrar caminhos e informações que eu precisava para continuar o projeto.
Lembram que pedi ajuda para o PM para encontrar dados? É sobre isso e tá tudo bem.
*Foi a primeira dinâmica que fiz dessa forma. Para otimizar o tempo de todas as pessoas envolvidas, preparei um board do Miro com toda a dinâmica e fiz uma reunião síncrona de 20 minutos explicando os conceitos (cada critério da avaliação e como considerar as notas de cada um) e como iria acontecer (cada pessoa avaliaria individualmente o elemento do produto em web e mobile, no seu tempo).
Sugeri um prazo máximo de realização dessa atividade assíncrona e fiquei à disposição para dúvidas e trocas que as pessoas sentissem necessidade. Depois que todos fizeram suas avaliações, analisei quais critérios foram melhores e piores, agrupei os insights mais parecidos e tirei insumos incríveis para a solução que queria desenvolver.
Dados são ótimos… mas pra quê você precisa deles mesmo?
A provocação da minha então líder veio no primeiro dia trabalhando em Produto: “Quando for fazer Discovery, tente pensar bastante em como você vai usar de fato os dados que você solicitar e/ou coletar”.
Em uma empresa com muitos dados a disposição para coleta e análise, pode ser muito tentador querer saber tudo sobre todos os aspectos do problema que você está tentando resolver, então o foco é fundamental para otimizar seu tempo e o tempo das pessoas que vão trabalhar com você para chegar nesses dados.
Saber o número de cliques em um botão pode ser uma informação até básica, mas o que exatamente você vai fazer com ela? Comparar com outro dado para gerar inteligência e assim ter um insight sobre uma possível solução?
Como um (ou vários) dado(s) vai se transformar em ação da sua parte? Parece óbvio, mas quando a gente faz esse exercício (vou usar dado X para decidir se o botão dessa página vai continuar como está ou precisa mudar), as coisas ganham perspectiva e você consegue entender exatamente o que precisa dos números — ao invés de se afundar neles sem ter muita noção do que fazer com tantas informações.
Saber perguntar é mais importante do que ter respostas
Isso tem muito a ver com o tópico anterior. Se com os dados esse cuidado sobre o que perguntar é essencial, quando estamos falando de um problema macro a ser resolvido, isso fica ainda mais crítico: imagina a quantidade de tempo e energia de tantas pessoas envolvidas para resolver uma questão que no final das contas não estava bem formulada e não traz os resultados esperados?
A definição do problema é o racional que vai guiar TUDO que será feito depois. Se essa pergunta não estiver bem formulada — seja por falta de informações ou pressa de pular para respostas — vai ser preciso muito mais tempo, energia e dinheiros para entender porque a solução não está dando certo.
A documentação é sua melhor amiga
É primordial deixar tudo registrado, com fácil acesso e de fácil entendimento para todas as pessoas envolvidas no projeto. Pode ser que cada Designer faça do seu próprio jeito ou que exista um modelo específico na empresa que está trabalhando, mas é absolutamente necessário que as informações e todo o racional do processo esteja acessível para análises futuras, contexto de todos os stakeholders a qualquer momento e ajuda/guia para os outros profissionais de UX da sua equipe.
Eu, particularmente, gosto de fazer um arquivo de apresentação com absolutamente todos os links, prints etc. Muita gente usa o Notion, a maioria deixa em camadas no Figma, enfim, não existe certo e errado. O que precisa existir é organização!
É com essa documentação que você vai justificar decisões, é nela que você vai voltar sempre que precisar achar alguma informação (por menor que seja), é ela que vai te salvar quando você estiver #semtempoirmão e algum colega precisar de contexto sobre o que você trabalhou. Ela vai ser uma mão na roda na hora de fazer seu portfólio e é ela que vai salvar colegas de profissão quando você não estiver mais em uma empresa. Trata ela com carinho, na moral.
Acabou. Acabou?
Lá em cima nesse mesmo artigo eu contei que essa experiência mexeu muito comigo — e mexeu mesmo.
O processo foi intenso, senti minha confiança em mim mesma abalar algumas vezes… Me senti perdida, sem saber bem por onde começar mesmo tendo um caminho para me basear. Mas depois das partes mais difíceis e conversas com lideranças que me fizeram entender o processo e até ser mais gentil comigo mesma nesse momento de muito aprendizado, posso dizer que saí com a autoestima profissional resgatada por me sentir capaz de fazer esse trabalho que até então era desconhecido por mim.
Esse projeto que fiz as etapas de Discovery & Definition enfim pôde passar para a próxima fase. E eu, me dando todo o direito de falar um clichê, posso dizer que o processo de Discovery de mim enquanto profissional de Produto só começou. Agora me sinto confiante, empolgada e mal posso esperar pelos próximos desafios.
