Caso real: o app que quebrou na pandemia

Quando o sistema não estava pronto para o mundo real

Em 2020, eu trabalhava com uma empresa de investimentos. Até então, o app tinha uma base de usuários estável, algumas centenas de milhares de pessoas que já investiam e conheciam o produto. Tudo funcionava. O design atendia o fluxo normal, os servidores seguravam o volume, e o suporte dava conta.

Então veio a pandemia. E com ela, uma onda que ninguém previu.

Com as pessoas trancadas em casa, muita gente que nunca tinha investido começou a se interessar por mercado financeiro. O app viu sua base de usuários crescer dez vezes em poucos meses. Dez vezes. De repente, um sistema projetado para um volume específico estava recebendo uma enxurrada de acessos simultâneos.

E o que aconteceu? O sistema começou a quebrar. Telas travavam no meio de operações. Cotações não carregavam. Ordens de compra e venda ficavam presas em loading infinito. E o pior de tudo: o app não tinha estados de erro projetados. Quando algo falhava, o usuário via uma tela branca, um ícone genérico de erro, ou simplesmente nada. Nenhuma mensagem dizendo o que havia acontecido. Nenhuma orientação sobre o que fazer a seguir.

Imagine a situação do usuário: uma pessoa que acabou de colocar dinheiro para investir pela primeira vez na vida, cheia de insegurança, e a tela simplesmente trava. Sem mensagem. Sem explicação. O dinheiro saiu da conta? A compra foi feita? O app está fora do ar ou é o meu celular? O nível de ansiedade era enorme, e o design não fazia absolutamente nada para acolher essa pessoa.

O que eu aprendi com isso

Aquela experiência me ensinou algo que carrego até hoje: projetar para o cenário feliz é a parte fácil. A parte difícil, e a mais importante, é projetar para quando as coisas dão errado.

Isso significa:

• Projetar estados de erro : cada fluxo precisa de uma tela para quando a operação falha. Não uma tela genérica, mas uma que diga o que aconteceu e o que o usuário pode fazer.
• Pensar em UX Writing para falha : a mensagem de erro é tão importante quanto o botão de ação. "Algo deu errado" não ajuda ninguém. "Não conseguimos processar sua ordem neste momento. Tente novamente em alguns minutos ou entre em contato com o suporte." Isso sim acolhe.
• Considerar cenários extremos : o que acontece se 10 vezes mais pessoas usarem o produto ao mesmo tempo? O que acontece se a conexão cair no meio de uma operação? O que acontece se o servidor demorar 30 segundos para responder?
• Trabalhar o loading como parte do design : skeleton screens, spinners com mensagem, progress bars. O feedback visual durante a espera reduz drasticamente a ansiedade do usuário.

E o mais importante: eu aprendi que o designer precisa estar na mesa quando o time técnico discute escalabilidade e performance. Porque quando o sistema falha, é a experiência que o usuário vive. E a experiência é responsabilidade do design.

Depois daquela crise, redesenhamos todos os fluxos críticos com estados de erro dedicados, mensagens claras e fallbacks visuais. O app melhorou, não porque o código ficou mais rápido, mas porque o design passou a acolher o usuário mesmo quando a tecnologia falhava.