Como as Heurísticas de Nielsen poderiam ter salvado vidas nos anos 80

Tirando um pouco da poeira desse perfil para falar sobre um evento que fiquei sabendo que se correlaciona diretamente com uma falha de design "básica", sendo um dos piores bugs de software de todos os tempos: o "Malfunction 54".

Nos anos 80, com o advento do tratamento do câncer por radioterapia, alguns maquinários surgiram no mercado com esse propósito, sendo um destes o Therac-25 - uma máquina de radioterapia que confiava em controle via software, não hardware, para alternar entre modos de baixa e alta energia, permitindo tratar cânceres superficiais e profundos em apenas uma máquina, levando apenas 8 segundos para a troca, algo revolucionário e econômico para a época.

O problema era que, para alternar entre ambos os modos, era necessário a digitação de apenas uma letra - "x" para "modo Raio X" e "e" para o "modo Elétrons", não havendo mecanismos de confirmação - o mecanismo de confirmação era um ajuste via Hardware presente no modelo anterior, o Therac-20. A digitação muito rápida dos comandos, em menos do que os 8 segundos para finalização dos ajustes na máquina, levava o usuário à interface errada, onde apenas exibia-se a mensagem "Malfunction 54" e a opção de confirmar se desejava-se mesmo executar o tratamento mortífero - 10 a 20.000 rads, cerca de 100x a dose esperada e mais que o suficiente para matar um adulto.

De acordo com as Heurísticas de Nielsen, mensagens de erro devem ser claras e evitar o uso de código dado que pessoas sem conhecimento técnico podem se deparar com o erro e não saber o que fazer - afinal no caso estudado, os usuários eram técnicos hospitalares e não programadores, além de que reporta-se a ocorrência de várias janelas semelhantes durante a operação do software do Therac-25, o que não dava ao usuário a noção de gravidade do que estava por vir. Além disso, mensagens de erro devem indicar ao usuário como resolver o problema.

Outro princípio de Nielsen descreve que todo software deve conter em si sistemas de prevenção de erros. Se a máquina demoraria 8 segundos para alternar os modos, inputs não deveriam ser recebidos antes de 8 segundos para evitar a sobrecarga de dados que causava o bug, mas claramente não houve sequer o pensamento sobre o que poderia ocorrer, dado que não pensaram em transferir o block de transição que antes era hardware para software.

É isso crianças, criem mensagem de erro para os usuários que sejam claras e tenham um bom dia 🌟