.png)
Um guia visual do nosso modelo de descoberta no Figjam, o uso da Matriz CSD e a comunicação assíncrona que nos torna mais ágeis e assertivos.
O maior obstáculo de um bom produto não é a falta de ideias, mas a falta de clareza. Um roadmap pode apontar a direção, mas sem um processo de Discovery sólido, ter sucesso no lançamento, sem ter um conceito bem definido, é como apostar às cegas. Nesse contexto podemos apontar várias frustrações que desmotivam todos os times envolvidos: reuniões improdutivas, suposições não validadas e, o pior de tudo, retrabalho. Em outras palavras… “Ouvir as vozes da sua cabeça” não vai te levar a lugar algum.
Aqui no time de Design nós decidimos transformar a etapa de Discovery em um modelo muito mais visual e colaborativo, e isso transformou a forma como estruturamos as ideias, esclarecemos todas as nossas dúvidas e definimos um cronograma com a nossa Product Manager (PM) e os times de Desenvolvimento. O resultado é um processo sólido, simples que permite que essa comunicação seja assíncrona, com reuniões pontuais e estratégicas.
Nosso modelo foi pensado para ser colaborativo, centralizado em um board no Figjam, que organiza nosso raciocínio e garante que toda a equipe tenha clareza do que precisa ser feito. Neste artigo, vamos abrir nosso board e mostrar, passo a passo, como transformamos a incerteza em clareza, desde a ideia no roadmap até um item pronto para ser prototipado.
Nosso discovery começa sempre pelo roadmap estratégico do produto. É esse documento que nos dá a visão de quais entregas estão previstas e quais são as prioridades para o trimestre. Com o roadmap em mãos, o segundo passo é o planejamento conjunto. Nos reunimos mensalmente com as equipes de desenvolvimento responsável por nossos produtos e alinhamos a ordem de priorização dos itens. Esse alinhamento inicial é crucial para garantir que estamos todos olhando para a mesma direção e, dessa forma, cada time pode se organizar em seu cronograma e organização de capacity.
Alinhadas as priorizações, mergulhamos no discovery de cada item! Pegamos como base o documento estruturado pela nossa PM, o “Business Case”. Através da leitura e passagem de conhecimento dele, começamos preenchendo informações gerais:
→ O que é: Definimos em poucas palavras o que é o projeto que iremos tocar
→ Para quem: É o nosso usuário de foco, para quem iremos desenvolver esse projeto
→ Como: Definimos como devemos idealizar cada parte do projeto para atingir seu objetivo
Após este detalhamento, partimos para o coração do nosso processo, uma metodologia básica e extremamente eficaz nesse processo, a Matriz CSD (Certezas, Suposições e Dúvidas). Por vezes me deparei com líderes que tinham um discurso reativo ao uso de “ferramentas e metodologias acadêmicas”, mas ao contrário do que muitos entendem como “burocratizar” um processo, o uso da matriz é uma forma rápida de estruturar nosso pensamento e o que sabemos ou não sobre o projeto que iremos idealizar e, na maior parte dos casos, preenchemos essa matriz em menos de 10min. Com isso, alcançamos as seguintes definições:
→ Certezas: O que já sabemos sobre o problema ou a solução.
→ Suposições: O que achamos que sabemos, mas precisamos validar.
→ Dúvidas: O que não sabemos e precisamos investigar.
Essa organização nos ajuda a direcionar as perguntas certas e a focar nosso trabalho no que realmente precisa de nossa atenção. Para ilustrar, veja exemplos reais de um de nossos boards:
Todo o nosso processo de discovery é trabalhado em um único board no FigJam, que chamamos de “Workshop Design <> PM”. Dentro dele, criamos pequenos boards, dentro de sessions, dedicados para cada funcionalidade ou projeto.
Cada session contém as informações gerais da funcionalidade e a Matriz CSD, como vimos anteriormente. Além disso, registramos e alinhamos as restrições técnicas com os times de desenvolvimento e definimos os próximos passos para cada integrante do nosso time.
Como facilitador do entendimento completo do projeto, podemos desenvolver alguns wireframes e/ou jornadas de funcionamento, seja de usuário ou um rascunho da arquitetura do projeto.
Para que esse ecossistema funcione, usamos um sistema de comunicação visual que torna nosso trabalho assíncrono muito mais eficiente:
Neste tópico, usamos a teoria das cores e sua aplicabilidade a nosso favor! Organizamos os itens através de uma dinâmica de cores que nos indicam o status de cada session:
→ Verde para os projetos entregues;
→ Azul para projetos em backlog;
→ Vermelho para projetos que ainda estão em discussão técnica;
→ Cinza para projetos descontinuados;
Nesse momento consigo imaginar o famoso estereótipo de que Product Designers são “flanelinha de post-its” (risos). Mas a verdade é que podendo nos identificar através deles, nos permite saber quem adicionou cada nota e, entendendo o contexto de cada contribuição, conseguimos direcionar o esclarecimento de dúvidas com mais assertividade e otimizando o tempo de passagem de conhecimento.
E vamos combinar que poder distribuir post-its online é sustentável e econômico!
É aqui que nosso trabalho fica divertido e eficiente. Usamos stickers de "joinha" (👍/👎) para validar as certezas e o que está correto e incorreto. Usamos ícones intuitivos para sinalizar atenção (⚠️), conclusão (✅) e dúvida (❓).
Todo esse método, por ser estritamente visual, nos dá uma visão clara do que precisa ser feito, por quem, para quem e por quê.
Agora que sabemos de tudo isso, quando entendemos que o discovery terminou?
Um ponto crucial em nosso fluxo é que a discussão sobre a viabilidade técnica acontece entre a equipe de desenvolvimento e a PM antes da passagem de conhecimento final para os Product Designers. Isso é fundamental para garantir que não estamos dedicando nosso tempo e esforço em uma solução que não é tecnicamente viável.
Uma vez que preenchemos toda essa dinâmica e iniciamos a prototipação, o discovery é concluído!
Adotar um processo de discovery mais estruturado transformou a maneira como trabalhamos. Saímos de um cenário que dependia de conversas síncronas, desgastantes e pouco documentadas para um modelo que privilegia a clareza visual e a comunicação assíncrona eficaz.
Este framework não serve para engessar, mas para acelerar a entrega de valor. Ele garante que, quando começamos a idealizar as telas, já temos um profundo alinhamento sobre o problema que estamos resolvendo, para quem estamos resolvendo e quais são as restrições do caminho. Isso resulta em menos retrabalho e, no fim do dia, em produtos melhores.
~ E em post-its free ~
E acesse, em primeira mão, nossos principais conteúdos diretamente do seu e-mail.
