A mensagem de texto que teria tornado a espera suportável

Algumas semanas atrás, passei meio dia na sala de espera de um hospital veterinário com o meu cachorro, o Tupí. Nossa clínica de sempre não podia nos atender, nem as muitas outras para as quais ligamos. Então fizemos o que todo mundo ali tinha feito: fomos para onde a porta estava aberta… e esperamos.

Depois de algumas horas juntos, os desconhecidos começam a conversar. Primeiro sobre os bichos, depois sobre a outra coisa que tínhamos em comum: a espera. A conversa foi parar no hospital de gente, onde todo mundo concordava que é pior. Eu tinha uma história para contribuir: uma espera de 15 horas no pronto-socorro, alguns anos atrás, por algo que nenhuma clínica aceitava ver sem agendamento. Alguns hospitais do Quebec agora publicam o tempo médio de espera e a lotação de cada pronto-socorro, o que ajuda antes de sair de casa. Mas, uma vez lá dentro, ninguém sabe dizer quando o seu nome vai ser chamado.

Uma mulher ali tinha uma solução: “Por que eles não mandam só uma mensagem quando está quase na minha vez?”

Eu tinha tido a mesma ideia anos atrás. Não é uma ideia ruim. Esperar em casa, comer, dormir, voltar quando chamarem. Menos gente na sala, uma equipe mais calma, uma noite melhor para todo mundo. Seria barato de construir, e se um hospital me pedisse para desenhar isso eu teria um protótipo muito rápido. Mesmo assim, há razões muito boas para desacelerar aqui.

O que a funcionalidade aceita

Toda solução carrega dentro de si um modelo do mundo. A mensagem de texto carrega este: o pronto-socorro é um lugar onde se espera tanto tempo que vale a pena ir para casa no meio. A funcionalidade torna isso suportável, talvez até agradável. Mas não toca na origem do problema.

Vamos olhar o que ela deixa de pé. Não existe nenhum caminho até o atendimento que não termine no pronto-socorro, porque os lugares que antes absorviam uma dor de garganta, as clínicas de atendimento sem hora marcada, na maioria passaram a atender só com agendamento, e os agendamentos costumam ficar semanas à frente, quando se encontra algum. O pronto-socorro virou a porta de entrada por padrão. A mensagem de texto seria uma campainha muito bonita nessa porta.

O enquadramento habitual é capacidade: mais médicos, mais leitos, e a fila diminui. Há verdade nisso, e não estou em posição de discutir política de saúde. O argumento contrário, como designer, é mais estreito: a fila é um sintoma, e o sistema que a produz é um sistema sem porta de entrada. Construir conforto dentro da fila é apostar que a fila é permanente.

A dor e o problema são reais, os dois

Isto não é um argumento contra a funcionalidade. A mulher da sala de espera estava certa. A dor é real, e um time de produto que a descartasse mereceria perdê-la.

É um argumento sobre ordem. Em produto, o pedido quase sempre chega como solução para uma dor, formulado como solução para um problema: uma mensagem de texto, um dashboard, um botão de exportar, um formulário mais rápido. Resolver o que foi pedido, do jeito que foi pedido, costuma ser a forma mais rápida de deixar um usuário feliz neste trimestre. Um “quick win”, digamos. Também é, com frequência, a forma como um processo quebrado se torna permanente, porque, uma vez que a dor some, ninguém mais tem motivo para ir procurar a causa. Na medicina, um tratamento que alivia o sintoma e deixa a doença avançar já tem nome. Não é “cura”.

Já estive dos dois lados. Já construí a campainha quando o orçamento, o mandato e o calendário não deixavam espaço para a porta. Também já vi times construírem três gerações de campainhas para uma porta que ninguém tinha permissão de questionar.

Três perguntas antes de construir o que foi pedido

Quando um pedido chega já no formato de funcionalidade, tento fazer três perguntas antes de dizer sim.

• O que esta funcionalidade aceita como permanente? Escreva a frase. “Pronto-socorro é um lugar onde se espera tempo suficiente para ir para casa.” Se é uma frase que a organização nunca colocaria numa parede, isso é informação.
• Quem fica mais quieto se a gente construir? Uma funcionalidade que alivia a dor também tira a pressão que essa dor exercia sobre o sistema. Às vezes, esse é o objetivo. Às vezes, essa pressão era a única coisa mantendo o problema real visível.
• Qual é a menor versão que trata a dor sem fechar a pergunta? Uma mensagem de texto que também registra por que cada pessoa veio, e se uma clínica poderia tê-la atendido, trata a mesma dor e mantém o problema da porta sobre a mesa. Mesmo custo, outro modelo do mundo.

Nada disso é motivo para recusar o pedido. As organizações têm recursos limitados, mandatos limitados e influência limitada sobre os sistemas ao redor. Às vezes, tratar a dor é a única coisa honesta ao alcance, e fazer isso bem é um bom trabalho. O erro não é construir a campainha. O erro é construí-la e declarar a porta consertada.

A pergunta em aberto

Então, onde fica a linha? Quando é certo tratar a dor e não o problema, e quando uma funcionalidade que torna um sistema quebrado suportável vira a coisa que permite que ele continue quebrado?

Não acho que exista uma resposta geral. Acho que a pergunta precisa ser feita em voz alta, toda vez, antes do primeiro wireframe. Se você tem um caso em que traçou essa linha, para um lado ou para o outro, gostaria de saber como decidiu.