Quando a experiência não funciona, pessoas da realidade sofrem

Entre tempestades na Costa Rica, lembrei de outra tormenta: a de confiar em produtos que esquecem das pessoas.

Era novembro de 2023, após uma semana de trekking na montanha Aconcágua, voltei a Mendoza na Argentina, exausta e com 3 objetivos: tomar banho, comer e dormir.

Após o banho, escuto meu namorado, Romain, gritar do chuveiro: “Quero comer comida venezuelana!”.

Instantaneamente, desejei arepas recheadas com feijão e queijo. Abri o app PedidosYa, adicionei nosso novo endereço e iniciei a busca por um restaurante. Ao olhar a listagem algo me incomodou:

Não havia nenhuma indicação da cidade, província e distância dos restaurantes em relação à nossa localização.

Parece um detalhe menor, mas como product designer, sei que a ausência de uma informação importante gera insegurança no usuário e se torna uma falha grave, especialmente ao realizar ações importantes, como efetuar uma compra. E foi isso o que me ocorreu, acabei refazendo o fluxo de busca de novo, para ter certeza de que o endereço estava correto.

­

Quando a fome encontra a negligência

A interface do checkout era visualmente adequada, porém mais uma vez a heurística 1 (Visibilidade do Status do sistema) foi ignorada.

O app seguia não identificando o município e a província ao apresentar o endereço de entrega no resumo do pedido.

Em um país onde “Suipacha” é nome de rua em múltiplas cidades, a ausência dessas informações deveria ser uma bandeira vermelha e a exibição do endereço deveria ser repensada pelo time responsável.

Então agora além de insegura passei a me sentir desconfiada, revisei o endereço diversas vezes e mais uma vez ignorei minha intuição pensando:

“Eles operam na América Latina inteira, devem ter APIs robustas de geolocalização. Estou exagerando na desconfiança!”

Ao finalizar o pagamento, outro tropeço: cartões estrangeiros não eram aceitos.

A copy de erro da interface não sinalizou isso ao processar os dados do cartão apenas apresentou um erro genérico “tente novamente”. Obtive clareza da limitação entrando em contato com o suporte.

Frustrada me dei conta que fazia 20 minutos que estava tentando concluir o pedido, e veio à mente aquele ditado: “tá no inferno? Abraça o capeta” e foi o que fiz, aceitei pagar em dinheiro (como faziam os Incas).

­

A falha atravessa cidades

Cerca de 40 minutos depois, o entregador envia a mensagem: “Estou no endereço, mas ninguém responde à campainha.”

Depois de trocar algumas mensagens a verdade: O entregador estava em Buenos Aires em vez de Mendoza.

Cansado, ele disse ser a segunda vez naquele dia que passava por esse problema: pedidos foram realizados em localizações diferentes e não era essa a intenção do comprador.

Ambos não conseguiram suporte do app.

Ele já acumulava 30 mil pesos argentinos de prejuízo, e não conseguiria continuar trabalhando naquela noite…

Precisávamos pagar o entregador, mas excluímos a possibilidade de transferir dinheiro devido às barreiras internacionais e à taxa absurda de um app que realiza esse tipo de transferência. Por fim acionamos nosso amigo argentino, Rodri, que fez uma transferência ao entregador.

Após o pagamento o entregador cancelou o pedido e pediu desculpas. Fomos dormir com fome e convictos de nunca mais usar esse app!

Mais tarde, pesquisando sobre as dificuldades dos usuários com o app para embasar melhor esse artigo confirmei que minha experiência não foi um caso isolado:

­

Como evitar que isso se repita?

Longe de mim querer ensinar sobre como algo deve ser feito, mas, como profissional de produto, é inevitável pensar: se as primeiras avaliações negativas começaram a surgir (e o suporte se mostrou ineficiente), o caminho natural seria reunir todos os stakeholders: Produto, Design, Tecnologia, Suporte e CX para entender o que está acontecendo.

E a partir do diagnóstico coletivo, seria possível redesenhar o fluxo de busca de forma responsável e centrada em quem mais importa: as pessoas que dependem do app para trabalhar e fazer a compra de uma refeição ou outras compras essenciais.

­

Problemas identificados

• API de busca e geolocalização: falha estrutural na identificação correta do endereço cadastrado na busca e na apresentação de restaurantes na listagem.
• Quebra de heurísticas e falhas de microcopy: ausência de informações essenciais, feedback inadequado de erro e falta de compatibilidade com o mundo real.
• Suporte automatizado ineficiente: incapaz de detectar, escalar ou resolver situações graves, prejudicando compradores e entregadores.

­

­Como podemos chegar a uma solução?

Pensando no contexto de UX, aplicaria as seguintes metodologias com os stakeholders antes de propor qualquer fluxo ou desenho de solução:

• Análise Heurística do fluxo de busca;
• Jobs to Be Done;
• How Might We;
• Matriz CSD;
• MoSCoW.

­

Análise heurística para compradores:

­

Jobs To Be Done para compradores:

Se esses jobs não são atendidos, o comprador não apenas tem uma experiência ruim. Ele perde dinheiro, desiste da plataforma e pode espalhar uma reputação negativa, afetando o crescimento do app.

­

Análise heurística para entregador:

Observações:

• Esses problemas de heurística para o entregador são muito mais graves, porque não impactam apenas a experiência de uso, mas também o ganho financeiro e o bem-estar de quem depende do app para viver.
• Falhas nesse nível tendem a gerar churn oculto entre entregadores (abandono da plataforma sem feedback formal).
• Também impactam o nível de serviço para clientes (entregas não concluídas, atrasadas ou canceladas).

­

Jobs To Be Done para entregador:

­

A história contada é um exemplo prático de como falhas de usabilidade desencadeiam impactos desproporcionais na realidade de compradores e entregadores que dependem do app como fonte de renda.

Do ponto de vista técnico, as falhas apresentadas violam princípios básicos de design de interação (heurísticas de Nielsen) e refletem ausência de validações de jornada centradas no usuário.

Esses problemas não comprometem apenas a experiência individual do usuário, como também ampliam desigualdades estruturais: trabalhadores precarizados assumem prejuízos financeiros por erros que deveriam ter sido evitados por um sistema mais robusto. Compradores, por sua vez, perdem confiança, abandonam a plataforma (churn) e amplificam uma percepção negativa que compromete o crescimento de negócio.

­

A reflexão para nós, profissionais PMs e PDs é simples e profunda:

• Cada decisão de design tem impacto social, econômico e emocional.
• Validar fluxos críticos através de pesquisas, testes de usabilidade e análises heurísticas não é opcional é uma responsabilidade ética.
• Trabalhar com frameworks como Jobs To Be Done, How Might We e Matriz CSD permite antecipar falhas graves e construir experiências que respeitam o usuário e o ecossistema do produto como um todo.
• O suporte ao usuário deve ser projetado como parte da experiência, não como contingência.

Construímos produtos digitais, mas tocamos vidas reais.

E, no fim, é essa responsabilidade que deve guiar cada decisão de design, produto e tecnologia.

Referências e leituras complementares

• Jakob Nielsen — 1994, “A teoria por trás das avaliações heurísticas”.
• Tony Ulwick — 2003, “Jobs to be done: o que é e qual abordagem utilizar?”.
• Interaction Design Foundation: “O que é How Might We?”.
• Livework, “Matriz CSD: o que é e como construir junto ao time de Produto”.
• MoSCoW, “Ferramentas de priorização para designers”.

Quando a experiência não funciona, pessoas da realidade sofrem was originally published in UX Collective