Ep. 121 - Bora prototipar?

O episódio começa retomando a separação entre upstream e downstream no fluxo de descoberta e entrega de valor das organizações: de um lado, o momento de descobrir, aprender e validar; de outro, o momento de construir e disponibilizar uma solução. As convidadas relacionam essa divisão aos diamantes do design thinking: o upstream corresponde ao primeiro diamante, quando o time busca entender melhor o problema e o desafio, e o downstream aos diamantes seguintes, quando já se caminha para a convergência em uma solução concreta. Um dos pontos levantados é que boa parte da confusão em torno desses termos vem do próprio vocabulário em inglês adotado pelo mercado, nem sempre compreendido por todo mundo desde o início.

A partir daí a conversa mostra o equívoco comum de partir da certeza de que já se sabe o que precisa ser construído, em vez de reconhecer que existe um espectro grande do que significa "minimamente validado": pode ser um protótipo, uma pesquisa, um input de mercado ou a percepção de um concorrente. É nesse espaço que entra a prototipagem, conectada à discussão sobre outputs e outcomes de um episódio anterior do podcast: reduzir a incerteza antes de comprometer esforço e dinheiro na construção. Diminuir essa incerteza também evita testar a solução já no lançamento, o que pode gerar insatisfação e desgaste com a base de usuários; testar antes, em ambiente seguro, permite prever movimentos e chegar a uma relação melhor com o produto ou a marca.

Um artigo do IDEO sobre benefícios da prototipagem é citado para reforçar pontos como: melhorar a comunicação com stakeholders ao demonstrar ideias, economizar tempo e dinheiro no longo prazo, servir como contraponto a opiniões fortes e certezas cristalizadas dentro das organizações (o protótipo traz um fato, não uma opinião), e gerar novas ideias, inclusive quando invalida alguma hipótese. Também se destaca que prototipar não serve só para validar: serve para aprender, e o processo de construção do protótipo por si só já produz insights.

A conversa passa então a desmistificar o protótipo com exemplos práticos: usar UI kits prontos para montar telas enquanto se ouve o stakeholder, prototipar já durante a fase de entendimento, registrando as "verdades" de quem está sendo ouvido, mesmo que o resultado pareça um "ornitorrinco" antes de fazer sentido, e tratar a prototipagem como algo natural e contínuo do dia a dia, não uma etapa isolada anunciada como "vamos prototipar agora". É levantada a pergunta de um ouvinte, Nicolas, sobre se só profissionais de UX podem prototipar; a resposta é enfática: não, qualquer pessoa pode, mesmo sem formação em design, usando o design thinking para tangibilizar ideias, "fazer o download" do que está na cabeça de alguém. Prototipar também não exige recursos sofisticados: um dashboard feito no Excel pode ser um protótipo legítimo se usar a ferramenta com que a pessoa tem mais familiaridade.

Outro bloco detalha os tipos e níveis de fidelidade de um protótipo (baixa, média e alta), que variam conforme a verossimilhança com a realidade: de um texto genérico a um texto próximo do mundo real, de uma interface sem cor, ícones ou botões até um desenho já com forma e cor definidas. Exemplos concretos incluem protótipos físicos (como o exercício de prototipar uma maçaneta em um curso de design), um pitch como protótipo de uma proposta de valor, o uso de massinha, palitos e outros materiais do design thinking, e até uma encenação teatral simulando a interação de um serviço. Também aparece o exemplo do "Post-it Palooza" da IDEO, usado para prototipar até projetos textuais, como um projeto de mestrado.

Uma pergunta da comunidade, de Natasha, questiona que informações são necessárias para montar um bom protótipo. A resposta indica que depende da estratégia e do papel de quem prototipa: na fase de entendimento, o critério é conseguir tirar a ideia da cabeça de alguém e tangibilizá-la a partir das "verdades" dos stakeholders; em fases mais avançadas, o protótipo precisa respeitar as hipóteses que está tentando validar ou invalidar, e ter clareza do objetivo e da dor que se está tentando resolver; sem isso, corre-se o risco de tentar resolver uma dor que não existe. É contado um caso real de um protótipo que cresceu além do previsto porque foi incorporando todas as expectativas dos envolvidos, o que gerou frustração, mas também serviu de aprendizado sobre a complexidade real do que estava sendo pedido, inclusive levando a decidir por um MVP a partir de um "caminho feliz" mapeado no protótipo.

A discussão avança para o distanciamento, em muitas organizações, entre quem faz a descoberta e quem constrói, um modelo de "passagem de bastão" no qual a certeza é entregue pronta para quem vai apenas executar, o que não faz sentido quando se trabalha com pessoas de conhecimento e criatividade. Como alternativa, são citadas equipes multidisciplinares e, quando isso não é possível, ao menos a socialização contínua do conhecimento gerado, levar quem representa a execução para dentro do processo desde a descoberta, compartilhando o racional e não só o resultado. A cocriação, inclusive envolvendo clientes, é destacada como forma de reduzir vieses e fortalecer o senso de pertencimento das pessoas envolvidas.

Em uma dinâmica de perguntas com respostas "sim ou não" seguidas de justificativa, surge a pergunta se é preciso discovery e protótipo para tudo. A resposta é sim, no mundo ideal: sem esse momento de entendimento e imersão, corre-se o risco de não saber exatamente o que está sendo resolvido. Mas se reconhece que, na prática, o mercado usa o termo discovery de formas muito diferentes, como etapa, como item contínuo dentro do fluxo, ou até como algo vago que gera ansiedade e expectativas que nem sempre são atendidas. Um ponto de atenção levantado é que entrar em um processo de descoberta pressupõe justamente não saber ainda o que se vai encontrar, e não se deve tratar essa fase como algo que só existe se durar muito tempo ou como se fosse garantido gerar um entregável específico: o entregável de um discovery pode ser desde uma lista de features até um protótipo de alta fidelidade, um pitch em slides ou um benchmark, desde que sintetize e torne reproduzível o aprendizado gerado.

Por fim, uma pergunta de outro ouvinte, Augusto, sobre a diferença entre protótipo e MVP fecha o episódio com um exemplo direto: o protótipo de um carro pode ser um carrinho de brinquedo, que não entrega o valor prometido de levar alguém do ponto A ao ponto B; já o MVP se compromete a entregar esse valor, mesmo que de forma mínima: seria como um skate, que efetivamente leva a pessoa de um ponto a outro, mesmo sem ser o produto final. O MVP não é um pedaço da solução final, mas uma versão completa, dentro da sua proposta, que já trabalha com hipóteses validadas e permite ciclos de feedback para evolução; o protótipo, por sua vez, apenas tangibiliza uma ideia, sem o compromisso de entregar valor de uso. O episódio termina reforçando o recado central: desmistificar a prototipagem, entendendo que qualquer pessoa, em qualquer contexto profissional ou pessoal, pode prototipar a partir do momento em que consegue desenhar hipóteses e encontrar uma forma de validá-las ou invalidá-las.