DoubleDiamondnapráticaparaescolheroqueautomatizar

Quando um escritório de advocacia me pediu que “os agentes aprendessem”, o pedido chegou com a solução dentro: treinar um modelo. Pesquisei esse caminho e ele não fechava: sem oferta para os modelos atuais, caro de manter no ar e arriscado com dado de cliente. Por trás do pedido havia outra pergunta: como o sistema fica melhor com o nosso jeito de trabalhar? Essa tinha outra resposta, e ela não exigia treinar nada.

Pedido de automação quase sempre chega assim, com o segundo losango já aberto. O método para voltar ao primeiro eu aprendi em projetos de design. O exemplo que uso para explicá-lo é de um projeto que desenvolvi para a Eduzz, em 2024.

Naquele ano, a Eduzz ia fazer, de novo, a retrospectiva anual dos produtores: uma sequência de telas no formato stories com as conquistas do ano de cada um. A peça já existia. O caminho natural era abrir o arquivo do ano anterior, trocar as cores e pensar em telas novas.

A pergunta que chegou era “como fazer uma retrospectiva bonita”. A que saiu do primeiro losango foi outra: como fazer uma retrospectiva que as pessoas queiram mostrar. Retrospectiva que ninguém compartilha é só um relatório com animação.

O que fez a pergunta mudar não foi opinião. A edição anterior tinha deixado um dado: a taxa de compartilhamento de cada tela. A mais compartilhada (21%) não era a de faturamento. Era a que dizia quantas vidas o produtor ajudou a transformar. Logo atrás (20%) vinha a abertura com o nome da pessoa. As telas institucionais ficavam no fim da fila. Esse dado foi a descoberta, e ele decidiu o conteúdo antes de qualquer tela nova.

Este artigo é sobre essa parte do método, a que costuma ser pulada.

O modelo em uma imagem

O Double Diamond foi popularizado pelo Design Council britânico em 2005. A ideia central é que resolver bem um problema exige duas aberturas e dois fechamentos: uma para entender o problema e outra para encontrar a solução.

1. DescobrirDado de compartilhamento da edição anterior e benchmarking
2. DefinirDe “bonita” para “que as pessoas queiram mostrar”
3. DesenvolverWorkshop com stakeholders em quatro frentes
4. EntregarMatriz impacto × esforço e protótipo interativo

• Descobrir (divergir): sair da sala, ouvir, observar, coletar dados. O objetivo é aumentar o entendimento, não chegar a uma resposta.
• Definir (convergir): organizar o que foi aprendido e escolher um problema. O entregável é uma frase, não uma tela.
• Desenvolver (divergir): explorar muitas soluções para o problema escolhido.
• Entregar (convergir): testar, refinar e lançar a solução que sobreviveu.

Onde os times erram

O erro mais comum é tratar o primeiro losango como formalidade. O briefing já chega com a solução (“precisamos de um dashboard”, “vamos fazer um app”), e o time pula direto para o segundo losango. O Double Diamond vira um Single Diamond com mais etapas no Jira.

Na Retrospectiva, a tentação era exatamente essa. A peça existia, o formato era conhecido e o prazo era de duas semanas. Pular a descoberta pareceria eficiência. O resultado provável seria repetir a fórmula de encher telas com métricas e torcer para alguém achar aquilo interessante.

Os sintomas de pular o primeiro losango aparecem depois, e caros:

Sintoma no fim do projeto	Causa no primeiro losango
A feature foi lançada e ninguém usa	O problema era de outro público, ou não era prioridade
Cada stakeholder entende o objetivo de um jeito	A definição nunca foi escrita nem negociada
O teste de usabilidade “passou”, mas a métrica não mexeu	Testou-se se a tela é usável, não se resolve a dor
Retrabalho no modelo de dados depois do lançamento	O modelo mental de quem usa não foi mapeado

O que acontece no primeiro diamante

Descobrir: aumentar o entendimento

A descoberta mistura fontes, porque nenhuma sozinha basta:

• Entrevistas com quem vive o problema, sobre o passado e não sobre o futuro (“me conta a última vez que você fez isso”, nunca “você usaria?”).
• Observação do uso real: acompanhar o suporte por uma tarde, assistir a uma sessão de trabalho.
• Dados de comportamento que já existem: funil, taxa de compartilhamento, tickets, buscas internas sem resultado.
• Benchmarking para entender o que já é padrão e o que ninguém resolve.

Na Retrospectiva, duas dessas fontes fizeram o trabalho. A primeira foi o dado de comportamento. Ninguém precisou perguntar aos produtores o que eles achavam da edição anterior: o compartilhamento de cada tela já respondia, e respondia melhor do que uma pesquisa de opinião. As pessoas não compartilham números. Compartilham o que os números dizem sobre elas.

A segunda foi o benchmarking com o Spotify Wrapped. A referência era óbvia, e o cuidado foi usá-la para entender o mecanismo, não para copiar a estética: formato stories, uma ideia por tela, dado pessoal transformado em identidade, narrativa em primeira pessoa.

Benchmarking bem feito vira argumento, não moodboard. No conceito do Conker, um app para descobrir trilhas e cachoeiras, a comparação com Waze, Strava e Google Maps mostrou que cada um resolvia um pedaço e nenhum resolvia o todo: descobrir um lugar de atividade ao ar livre perto de você, com comunidade. A oportunidade do produto saiu da comparação.

Definir: escolher um problema

Convergir é a fase mais difícil politicamente, porque escolher um problema é não escolher os outros. O que ajuda:

1. Sintetizar o que foi aprendido em temas e transformar temas em oportunidades: necessidades, dores ou desejos de quem usa, não features.
2. Priorizar as oportunidades por tamanho do impacto e por evidência. Opinião de quem ganha mais não conta como evidência.
3. Escrever a definição: uma frase curta, negociada com os stakeholders, que vai guiar o segundo losango.

Na Retrospectiva, a definição foi a troca de pergunta. “Bonita” é um critério de quem desenha. “Que as pessoas queiram mostrar” é um critério de quem recebe, e ele reorganiza tudo: a abertura precisa chamar pelo nome, o miolo precisa falar do impacto do produtor nas outras pessoas, e a mensagem institucional deixa de ser o centro.

1. 01Coletar

   Compartilhamento por tela da edição anterior e benchmarking do Wrapped.

2. 02Ler o padrão

   Impacto nas pessoas (21%) e personalização (20%) lideram; o institucional fica no fim.

3. 03Oportunidade

   O produtor quer mostrar o que o ano diz sobre ele.

4. 04Definir

   Uma retrospectiva que as pessoas queiram mostrar.

Um formato de definição que funciona:

Reescrevendo hoje a definição da Retrospectiva nesse formato, ficaria assim: produtores precisam de uma retrospectiva que diga algo sobre eles, porque telas cheias de métricas genéricas não são o que se compartilha. Sabemos disso porque, na edição anterior, as telas de impacto e de personalização foram as mais compartilhadas e as institucionais, as menos. Vamos considerar resolvido quando a taxa de compartilhamento por tela for a métrica de sucesso da nova edição.

A última parte é a mais ignorada e a mais importante. Sem ela, o segundo losango não tem critério para dizer que acabou. E repare que, nesse caso, o critério e a evidência são a mesma medida: o dado que abriu o projeto é o que vai julgá-lo.

O segundo diamante, com a pergunta certa

Com o problema definido, o segundo losango é o mais conhecido: gerar alternativas, cortar, prototipar e testar.

Na Retrospectiva, a divergência foi um workshop com os stakeholders, em outubro de 2024. As ideias foram organizadas em quatro frentes: Produto, Produtores, Jornada e +Humano. A convergência veio numa matriz de impacto por esforço, para decidir o que entrava nesta edição. O artigo Do post-it à oportunidade mostra o quadro por dentro.

O que o primeiro losango mudou no segundo foi o filtro. Com a pergunta “bonita”, qualquer ideia visualmente interessante competia em pé de igualdade. Com a pergunta “que as pessoas queiram mostrar”, as ideias passaram a ser julgadas pelo que dizem sobre o produtor. A narrativa final seguiu isso: começa pela pessoa (personalização), passa pelo impacto dela nos outros e termina olhando para frente, com a faixa do programa de reconhecimento que o produtor pode alcançar no ano seguinte.

Dois lembretes para essa fase:

• Divergir de verdade. Três soluções diferentes para o mesmo problema ensinam mais do que três versões da mesma solução. Quatro frentes com nomes diferentes ajudam a forçar essa variedade.
• Testar contra a definição. O teste de usabilidade responde “a pessoa consegue usar?”. A pergunta do Double Diamond é outra: “isso muda o comportamento que definimos lá atrás?”. Na Retrospectiva, o protótipo foi interativo e navegado no celular, tela a tela, para os stakeholders verem como o produtor veria. A régua final continua sendo o compartilhamento.

O primeiro losango de uma automação

O mesmo método, aplicado a operação manual, muda de material e não de forma. No lugar da taxa de compartilhamento, o dado é o trabalho como ele é feito hoje.

No agente jurídico, o primeiro losango foi documentar o fluxo que já existia: os advogados usavam um chat de IA com instruções escritas pelo próprio escritório, e o retrato saiu das telas de uma sessão real. Dali vieram quatro requisitos que viraram lei do produto: a conclusão binária, a lacuna documental com a defesa que ela abre, declarar o que não se conseguiu ler e a âncora obrigatória em cada afirmação. E o pedido de “aprender” virou outra definição: manter o modelo fixo e fazer o contexto evoluir, com lições curtas aprendidas das correções, propostas pela máquina e promovidas por um sócio.

No sistema de pedidos de uma distribuidora, o primeiro losango coube numa decisão: não pedir para ninguém mudar de hábito antes de ganhar alguma coisa com isso. O comprador já fotografava a anotação. Reescrita hoje no formato acima, a definição seria: o back-office precisa receber o pedido sem redigitar, porque quem redigita também interpreta, e interpretar dá erro. Sabemos disso porque “balde” quer dizer 20 litros e “tb” quer dizer tambor. Vamos considerar resolvido quando o pedido por foto terminar na mesma fila que o pedido por catálogo, sem nenhuma linha duvidosa passar sem decisão.

Nos dois casos, a definição não cita a IA. Ela cita o trabalho. A IA entrou no segundo losango, como uma das soluções, e com uma pessoa confirmando.

O Double Diamond não é uma sequência

Na prática, os losangos se repetem e se sobrepõem. Um protótipo no segundo losango pode revelar que o problema estava mal definido, e tudo bem voltar. O modelo não é uma linha de produção; é um lembrete de que abrir e fechar são atividades diferentes, e que o time precisa saber em qual das duas está.

Também não é uma questão de tempo. A Retrospectiva durou duas semanas. O primeiro losango não precisou de um mês de pesquisa: precisou de alguém que olhasse o dado que já estava na mesa antes de abrir o arquivo de design. Descoberta barata ainda é descoberta.

Checklist para o primeiro diamante

• Antes de ter ideias novas, olhamos o que os usuários já disseram com o comportamento (uso, compartilhamento, suporte)?
• Falamos com quem vive o problema, sobre situações reais e recentes?
• O benchmarking explicou um mecanismo ou uma lacuna, e não só uma estética?
• A síntese separa o que observamos (fato) do que achamos (interpretação)?
• A definição cabe numa frase e não cita nenhuma interface?
• Existe um critério observável de “resolvido”, de preferência medido com o mesmo dado da descoberta?
• Os stakeholders concordaram com a definição antes do primeiro protótipo?
• O pedido de automação foi tratado como hipótese, e não como requisito?

Se alguma resposta for não, o time ainda está no primeiro losango, mesmo que a IA já esteja escolhida.