Como evoluímos o design das mensagens agendadas no WhatsApp

Como evoluímos o design das mensagens agendadas

O que acontece quando um desenvolvedor tenta fazer "RCP" (reanimação cardiopulmonar) em um recurso morto enquanto aprende design com nosso cofundador?

Eu te conto! :)

Eu não sou designer. Sou um desenvolvedor que, de algum jeito, acabou desenhando recursos enquanto os programava. Esta é a história de como levei nosso recurso de mensagens agendadas de um experimento fracassado a algo de que temos orgulho e que as pessoas usam de verdade.

O cemitério de recursos

Quando herdei as mensagens agendadas, elas já estavam mortas. Meus colegas tinham testado algumas versões:

Clique em um botão ao lado de enviar. Escolha uma data. Mensagem agendada. Quer outra? Clique de novo. Escolha a data de novo.

Toda. Santa. Vez.

Depois alguém adicionou um modal que bloqueava a tela inteira à noite: "Ei! Está tarde! Quer agendar isso para amanhã?"

Os usuários odiaram. O time removeu. Foi parar no nosso cemitério de recursos.

Aí veio a missão de RCP: "Ressuscite as mensagens agendadas. Faça com que deixem de ser ruins."

Versão 1: minha primeira tentativa de ressurreição

Começar uma RCP é estranho. Você sabe que o recurso fracassou, mas não quer só dar um retoque no cadáver. Precisa reimaginá-lo por completo.

Criei o "Modo Enviar mais tarde": uma barra laranja no topo que colocava você no modo de agendamento. Ativou, todas as suas mensagens ficam agendadas. Achei que tinha resolvido.

O feedback do Mati chegou em 30 segundos:

"quando abro a conversa, a animação da barra superior se repete. e não gosto da animação. os estilos não são consistentes. as bordas são diferentes e a cor parece estranha. quebra os atalhos. dá pra fazer melhor."

"Dá pra fazer melhor." A frase que ia definir as semanas seguintes da minha vida.

O processo de RCP: morrer e renascer, de novo e de novo

RCP não é só consertar o que está quebrado. É entender por que aquilo morreu e reimaginar tudo. E muitas vezes você precisa falhar mais algumas vezes para entender como é o sucesso.

Versões 2 e 3: atendi ao feedback do Mati. Ajustei as cores, mudei coisas de lugar, adicionei badges.

Mati: "não gosto do estilo da barra superior. dá pra fazer melhor."

O recurso já estava melhor do que o que meus colegas tinham tentado. Mas "melhor do que morto" não é a régua que buscamos.

Versão 4: exagerei. Tooltips, badges, contadores, gerenciamento de estado complexo. 500 linhas de código. "Se você quer melhor, vou te dar tudo", pensei.

Mati: "tira os efeitos. não é intuitivo como voltar. a gente não deveria levar o foco para a caixa de mensagem inteira."

Ele estava derrubando minhas soluções espertas uma por uma.

Versão 5: frustrado, sugeri: "E se a gente simplesmente deixar a caixa de mensagem azul quando estiver no modo agendado?"

Mati: "Melhor."

Uma palavra. Depois de semanas de "dá pra fazer melhor".

O que RCP significa de verdade

Depois de várias RCPs, aprendi que não se trata de consertar recursos. Trata-se de entender por que eles falharam e ter coragem de tentar algo completamente diferente.

A primeira versão falhou porque adicionava atrito. Clicar no botão, escolher a data, repetir. Minhas primeiras versões falharam porque eu adicionava complexidade em vez de tirar atrito.

A virada da v5 não foi adicionar algo novo. Foi perceber que a caixa de mensagem já estava ali. Só precisávamos mudar o estado dela, não construir em volta.

Versão 6: a verdadeira ressurreição

A versão final era tão simples que dava vergonha:

• A caixa de mensagem fica azul no modo agendado
• Um texto limpo mostrando o horário agendado
• Um badge pequeno para mensagens pendentes
• 100 linhas de código, não 500

Mati: "Bom. Pode lançar."

O recurso que tinha morrido nas mãos dos meus colegas, e que eu tinha complicado demais por 4 versões, finalmente estava vivo. E parecia que sempre tinha feito parte do WhatsApp.

O que aprendi sobre RCP (e design)

A verdade sobre RCP: não é sobre quem está certo ou errado. É sobre ter coragem de continuar insistindo quando qualquer outra pessoa já teria lançado a v2.

Não erramos nas primeiras tentativas: estávamos explorando. Cada versão "fracassada" foi um passo necessário. O modal que bloqueava a tela? Precisava existir para percebermos como interrupções incomodam. Minha barra laranja? Precisava existir para entendermos que diferente nem sempre é melhor.

"Dá pra fazer melhor" não é crítica. É um padrão compartilhado.

Quando o Mati diz isso, ele não está dizendo "você falhou". Está dizendo "ainda não encontramos". Esse "a gente" implícito muda tudo. Não é a visão dele nem o meu código. É o nosso compromisso de continuar insistindo até parecer certo.

O que esta RCP ensinou ao nosso time:

• A versão 1 nunca é a resposta, é a pergunta
• Soluções simples se escondem atrás de tentativas complexas
• Se precisa de instruções, ainda não terminamos
• Os melhores recursos parecem que sempre estiveram ali
• "Bom o suficiente" é inimigo de "caramba, isso está perfeito"

A mágica não está no feedback do Mati nem no nosso processo criativo. Está em se recusar a se acomodar. Qualquer time pode lançar a v2 e seguir em frente. É preciso um tipo especial de teimosia para chegar à v6 e continuar acreditando que existe uma solução mais simples escondida ali.

RCP não é sobre ressurreição. É sobre evolução.

Não estamos só trazendo recursos mortos de volta. Estamos evoluindo nosso entendimento do que faz algo valer a pena ser lançado. Cada iteração, cada "dá pra fazer melhor", cada versão descartada: tudo faz parte de encontrar aquela solução inevitável.

Nossa filosofia de RCP hoje

Quando fazemos RCP em um recurso:

1. Estudamos por que ele morreu (geralmente: complexo demais)
2. Tentamos algo completamente diferente (geralmente: ainda complexo demais)
3. Ouvimos "dá pra fazer melhor" (sempre)
4. Tiramos tudo (dói, mas é necessário)
5. Encontramos a solução simples que estava escondida (ela sempre está lá)
6. Lançamos quando parece inevitável (não quando impressiona)

Agora estou fazendo outra RCP. Versão 4. O Mati acabou de dizer "dá pra fazer melhor".

Sei o que vem por aí. As versões 5 e 6 vão doer. Mas em algum lugar dessa dor vamos encontrar a solução simples que traz esse recurso de volta à vida.

Os números que importam

Antes da RCP: 0% dos usuários usavam mensagens agendadas. Recurso morto. Abandono total.

Depois de 6 versões de "dá pra fazer melhor": mais de 20% dos usuários usando ativamente, semana após semana.

É disso que a RCP trata de verdade. Não só de trazer recursos de volta dos mortos, mas de torná-los tão intuitivos que as pessoas queiram usá-los. A diferença entre 0% e 20% não são só iterações de design: é a diferença entre um recurso que faz o usuário pensar e um que simplesmente funciona.

No fim, "dá pra fazer melhor" valeu a dor.

P.S.

Para meus colegas cujas versões "fracassaram" antes