Um livro bem diagramado, com uma bela capa e sobre um assunto que amo: como resistir?

Encontrei “Why we fail: Learning from Experience Design Failures” (tradução livre: “Porque falhamos: aprendendo com falhas de design de experiência”), de Victor Lombardi, com prefácio de ninguém menos que Don Norman.

O autor (até achei que fosse brasileiro pelo nome, mas não consegui descobrir) trabalha há mais de 30 anos no desenvolvimento de produtos digitais. Para escrever o livro ele fez uma extensa pesquisa e selecionou 10; quatro websites, dois serviços, um pacote de software, um sistema operacional e dois produtos baseados em hardware (acredito que seja software embarcado).

Gostei muito dos critérios: todos eram produtos inovadores (não tentavam copiar ou melhorar um concorrente) e não falharam por incompetência (o que é muito comum).

Logo no começo, Lombardi já deixa claro uma coisa importante: ele está considerando, nesse livro, somente as falhas de experiência dos clientes; ou seja, o produto falhou em proporcionar uma boa experiência.

Má experiência = design ruim?

Ok, mas a falha na experiência do cliente não é apenas um nome mais atual para design ruim? 

Ele explica que não: antes, quando os produtos eram mais simples, o mau design poderia explicar muitos fracassos. Mas uma vez que os produtos vão ficando cada vez mais complexos, o produto pode ter um bom design físico e funcionar perfeitamente bem (como um smartphone) e mesmo assim não é garantia de que o usuário vá gostar de usá-lo.

O motivo é que os novos produtos são complexos e multifacetados, e nossas experiências e interações são emocionais e subjetivas.

E será que a culpa dessas falhas seria designers mal treinados ou incompetentes? Victor diz que hoje em dia a resposta não é tão simples. 

Um produto pode ser amado por uma audiência e detestado por outra. Um aspecto da experiência que o designer acredita ser vital, como um website estar sempre disponível, não consegue bater um competidor que para várias vezes para manutenção. Ou dois produtos similares que produzem experiências parecidas, mas um deles falha por questões sociais ou culturais.

Ele conta uma experiência onde, em 2000, ele foi contratado por uma agência de design digital para criar o website de um portal que deveria revolucionar a pesquisa por informações financeiras; o público era formado por investidores de grandes empresas. No briefing, o cliente deixava bem claro que queria uma coisa com a cara de um terminal da Bloomberg (que é uma bolsa de valores americana); ou seja: várias telas com números coloridos em um fundo escuro e gráficos se mexendo o tempo todo.

O autor e a equipe sugeriram algo mais limpo e amigável (o fundo escuro dificultava a leitura), segundo as experiências anteriores com produtos semelhantes. Mas a grande verdade é que:

Nem a equipe de desenvolvimento e nem o cliente tinham feito pesquisa alguma para conhecer de fato a percepção do usuário.

Resultado? O cliente não gostou, trocou a equipe de desenvolvimento duas vezes e no final usou um software de prateleira. Fracasso absoluto.

Era um dos primeiros trabalhos do autor e ele ficou meio traumatizado, pois ninguém na empresa gostava de falar dos fracassos, de maneira que nunca tentaram entender a fundo o que de fato aconteceu. O jeito mais fácil, popular e convencional é maldizer o cliente, esse ignorante.

Ele começou a ver a história se repetir muitas vezes; projetos sendo cancelados, clientes insatisfeitos e usuários sendo sistematicamente ignorados, enquanto as agências faziam a egípcia. E pior: o povo concentrado em estudar os cases de sucesso para replicá-los, sempre evitando falar sobre as falhas e os fracassos.

VIÉS DA SOBREVIVÊNCIA

De início, olhar apenas para o que deu certo parece ser uma boa ideia, mas não é bem assim. Para ilustrar como essa abordagem pode ser perigosa, ele conta o clássico caso do avião de caça durante a guerra (já está batido, mas sempre tem alguém que ainda não ouviu).

Os aviões B-29 que voltavam do combate na segunda guerra, sempre tinham marcas de balas em partes específicas da fuselagem. A ideia da equipe era de reforçar essas áreas, já que eram mais visadas. Mas um matemático membro do time observou que, estatisticamente, eles só estavam tendo acesso a uma parte da amostra; a que sobrevivia e voltava. Ele não sabia onde os aviões que caíam estavam sendo atacados.

A conclusão foi que, provavelmente, os aviões perdidos eram baleados em outras partes da fuselagem e por isso caíam. E que os aviões sobreviventes eram justamente os atacados nas partes que eles estavam querendo reforçar. 

Conclusão: reforçando o resto do avião, e não as partes mais baleadas dos sobreviventes, aumentou a resistência das aeronaves. Talvez, se tivessem ignorado o que se chama de “viés da sobrevivência”, onde a gente só analisa o que teve sucesso, teriam jogado recursos preciosos fora, sem nenhuma melhoria.

Inclusive me lembro bem que muita gente usou essa falácia na época da pandemia, alegando que a gente estava contando apenas os mortos; não os sobreviventes. Ou seja, a gente precisa analisar o contexto com muito cuidado de uma maneira integral para poder evitar as falhas. As respostas para problemas complexos nunca são óbvias.

Ok, então o autor pergunta: por que precisamos de um livro falando sobre falhas de experiência, quando há tantos por aí? A resposta dele é uma pedrada: porque a maior parte desses livros é sobre DESIGN, não sobre EXPERIÊNCIA.

Aqui como ele mostra a diferença entre as falhas:

Falha de engenharia: quando o produto não funciona como o esperado, do ponto de vista físico.

Falha de design: quando o produto até funciona, mas é tão ruim que as pessoas não querem usá-lo. É quando um desastre acontece e a gente chama de “erro humano”, quando na verdade o design induziu o usuário a isso.

Falha de experiência: o produto funciona e as pessoas podem usá-lo, mas usá-lo é uma experiência que ninguém deseja.

TENDO A EXPERIÊNCIA CERTA

Aqui o autor conta em detalhes sobre o lançamento do sistema de navegação, telemetria e entretenimento chamado iDrive, lançado pela BMW em 2002, no seu modelo ponta de série. 

Elegante, com a maioria das funções embutidas, sem muitos comandos, a maioria das funções era acessada por poucos botões que podiam ser apertados, girados ou puxados. Design simples, limpo, um verdadeiro sonho… que rapidamente se tornou um pesadelo! 

O público detestou ter que esperar que o Windows instalado no computador de bordo fizesse o seu boot cada vez que a ignição era acionada. Havia uma série de mensagens de alerta que precisavam ser reconhecidas antes de tudo começar a funcionar. Ninguém conseguiu entender a lógica por trás dos controles, o que deixou clientes irritadíssimos. Fora que toda vez que o sistema era atualizado, a pessoa tinha que levar o carro até a concessionária. Imagina!

Na verdade, os sistemas de telemetria e navegação em carros continuam ser um grande desafio. Mas em 2002 havia menos recursos e talvez mais expectativa. Como pontos positivos, pode-se dizer que eles acertaram em colocar os controles em lugares acessíveis ao motorista, prover feedbacks (botão ligado/desligado, função ativa/inativa) de maneira clara, inseriram controles dedicados para algumas funções, fizeram o software ser capaz de incorporar novas funcionalidades e os design era bonito e limpo.

Mas erraram terrivelmente em inserir controles não familiares, excesso de informação (constantemente o motorista tinha que olhar e fechar alguma janela de alerta no painel, obrigando-o a desviar a atenção da estrada), a maneira com que a informação foi organizada e agrupada não era intuitiva, alguns comandos tinham efeitos colaterais na configuração que não eram visíveis, siglas que não faziam o menor sentido, processamento muito lento, controles ineficientes e algumas redundâncias desnecessárias, enfim, um horror.

O resultado foi que, depois de tanto choro e gritaria, a empresa finalmente fez uma pesquisa de usabilidade com 500 usuários ao redor do mundo. A empresa fez algumas modificações e melhorou bastante coisa. Mesmo assim, nas publicações comparativas com os sistemas concorrentes, o iDrive ainda é considerado uma experiência ruim. 

O final da história? Entre 2002 e 2008, as vendas do modelo 7, que trazia o iDrive embutido, caíram para quase a metade e não se recuperaram até hoje. 

Porque deu tudo errado: o autor diagnostica que o sistema de software, fora da área tradicional de competência da empresa (automóveis), foi lançado com o conceito de que seria um avanço tecnológico, não uma experiência melhor para os clientes. Provavelmente não houve testes de usabilidade suficientes antes do lançamento, devido ao excesso de confiança da empresa.

Nesse capítulo ele fala também do caso Google Wave, uma plataforma colaborativa para criar documentos (tipo o avô do Google Drive que conhecemos hoje) e que também foi um grande fiasco por ser muito complexo; as pessoas não conseguiam entender como usá-lo.

Nos dois casos, o foco foi o avanço tecnológico, não a experiência do usuário. Erro bastante comum em startups, mas, como se pode ver, não raro em empresas grandes também.

OUTROS CASOS

O autor analisa detalhadamente outros casos famosos de falha, como o OpenID desenvolvida pelo Yahoo para facilitar o acesso de contas lembrando das senhas e usuários. Mas o negócio ficou complicado demais, mesmo para o público mais técnico para o qual foi desenhado e piorou ainda mais quando o público leigo começou a acessá-lo (afinal, a ideia era boa e útil; hoje é o que permite a gente se logar em um site usando a conta de uma rede social como o Facebook, por exemplo).

Todo o restante do livro vai nessa direção: o contexto, a história, o que deu errado, porque deu errado (as diferentes razões analisadas uma a uma) e as lições aprendidas.

CONCLUSÕES

Lombardi conclui a obra dizendo que a gente falha porque:

1. Experiência importa. 

2. Três fatos precisam ser reconhecidos:
   1. aceitar que erros acontecem
   2. compartilhar abertamente a informação é essencial
   3. reunir dados verificáveis é necessário para corrigir os erros

MAS ENTÃO, COMO EVITAR AS FALHAS?

O autor finalmente explica o método desenvolvido a partir desses estudos e que evita novas falhas semelhantes às apresentadas. 

É basicamente o esqueleto do método científico, que consiste em observar, formular uma hipótese, fazer experimentos e testes e, finalmente, interpretar os resultados. Só que adaptado ao desenvolvimento de novos produtos com foco na experiência. 

A versão adaptada ficaria assim:

1. Observar o contexto (negócio, tecnologia e usuários)
2. Desenvolver hipóteses
3. testar protótipos com usuários
4. medir e interpretar o resultados

Repetir quantas vezes for necessário.

Enfim, nada de novo, mas gostei do jeito que ele organiza a informação e analisa os casos. E no final ele indica alguns livros que estão na minha pilha esperando a vez.

Olha, para mim, penso que é uma referência importante para designers, desenvolvedores, UX designers, gerentes de produto e todo mundo envolvido na cadeia. É fácil de ler e muito agradável. Vai lá!

Infelizmente o livro ainda não foi lançado em português. Se quiser adquirir o original em inglês, é só clicar aqui.