4 min de leitura ·

O que UX e tratamento de exceções tem a ver? TUDO!

Programadores costumam ver UX como algo para os "criativos", para os "designers". E quanto mais posicionados ao "back" eles estão, mais longe das preocupações dos usuários ele se vê. Mas será que ele está mesmo tão longe do usuário e das suas necessidades assim? É isso que eu quero discutir nesse texto. Conto com a opinião de vocês.

De início, precisamos entender que UX é sobre experiência do usuário. E uma das piores experiências que o usuário pode ter é aquela que acontece quando as nossas aplicações assumem um comportamento inesperado: da tela azul do Windows à alucinação do ChatGPT, passando pelas mensagens de erro de conexão, travamentos, maratonas da Netflix interrompidas pela falta de pagamento e até mesmo as mensagens de erro que os compiladores, runtimes e interpretadores lançam nos nossos consoles.

E aí chegamos num ponto interessante.

No contexto do uso de uma linguagem, API ou framework de programação, os usuários somos nós, programadores.

E assumindo isso, qual experiência nós estamos oferecendo aos nossos usuários?

No mundo do front-end, se tornou comum o design de telas de erro que se preocupam em informar o que houve e dar um caminho ao usuário. Desde a simplicidade da tela 404 do Tabnews até a forma descontraida da tela 404 da Netflix, ambas cumprem o seu papel, não se limitando apenas a lançar uma mensagem "erro 404" que obrigue o seu avô estudar protocolos HTTP para entender o que houve.

Mas quando os usuários são desenvolvedores, costumamos assumir que eles tem um nível técnico mais apurado, e por isso tendemos ser mais relaxados com essas soluções.

Veja, como exemplo, o que acontece quando você está utilizando VBA e se confunde quanto ao uso de comparações.

imgur

Se você cometesse um engano semelhante no Node, essa seria a mensagem:

Imgur

Repare que existem trade-offs aqui:

No Node, a escolha foi mostrar uma pilha de execução, que ajudaria o dev a entender qual foi o caminho do "erro" na aplicação. Uma mão na roda, pensando que a persona (essa palavra é importante) que utiliza o Node tem condições de fazer essa analise mais minunciosa;
No Excel, a escolha pela simplicidade também é orientada a persona que utiliza a ferramenta: alguém que pouco sabe de programação, provavelmente não sabe o que é uma pilha de execução, e inclusive agradece ao ver um link para a página de ajuda da Microsoft para salva-la.

Mas, será que não caberia ao console do Node exibir um link para a página de documentação da linguagem, pensando nos iniciantes na linguagem? E será que não caberia ao Excel exibir uma mensagem de erro mais clara do que um simples "Erro de sintaxe"? Será que o usuário do Excel sabe o que é "sintaxe", no contexto de programação?

Personas

Como disse, a palavra "persona" é importante aqui. Em UX, persona é a idealização do provavel usuário do produto - neste caso, a linguagem de programação.

A definição de personas costuma acontecer depois de muita pesquisa e contato com os possíveis usuários, mas se fossemos definir aqui, à revelia e de forma simplória, quem são as personas usuárias do Node e do VBA, poderiamos afirmar, entre outras coisas, que:

Persona usuária de NodeJS/Javascript
- Formadas em Ciências da Computação e afins
- Dedicam 100% do seu tempo em projetos que envolvem programação
- Criam aplicativos, APIs e outras soluções de grande porte
Persona usuária de Excel/VBA
- Sem formação em computação, no máximo fizeram algum curso rápido
- Utilizam as horas vagas para desenvolver soluções
- Automatizam relatórios e criam soluções de pequena complexidade

E o que temos a ver com isso? Tudo!

Enquanto, como usuários de linguagens de programação, temos poucas ações a fazer; já como programadores, somos nós quem desenhamos e disponibilizamos soluções aos usuários, sejam eles usuários finais ou outros colegas programadores. Quando estamos escrevendo, por exemplo, as nossas APIs, somos nós quem estamos escrevendo as mensagens de erro que serão consumidas por outros colegas programaodres. E como fazemos isso? de uma maneira clara, que facilita o entendimento sobre o que ocorreu ou não?

Pensando dessa forma, o simples fato de criarmos Exceptions mais claras já seria uma boa decisão de UX, centrada no usuário. Veja como a Exception abaixo já é auto informativa a partir do nome, e ainda oferece uma mensagem personalizada, ao contrario de simplismente lançarmos uma Exception genérica:

//Java
class FieldNameNullException extends Exception{
	public FieldNameNullException(String s){
		super(s);
	}
	public getMessage(){
		return this.message;
	}
}

Concluindo

O objetivo do texto foi trazer um pouco da "luz do UX" aos nossos códigos, reconhecendo e nos preocupando com os possíveis usuários das nossas soluções.

No mundo ideal, seria interessante conseguirmos falar com os nossos usuários e entender melhor quem são eles e em que contexto eles utilizarão as nossas soluções. Mas eu creio que a simples mudança de mindset, nos colocando no lugar do nosso usuário já seria benéfico para criarmos soluções mais bem desenhadas.

Lembrando que UX orientada ao usuário dev não se limita ao design de exceções e erros, mas também aos nomes de métodos, endpoints, escrita de documentação, dev rel, entre outras tantas possibilidades que precisamos considerar.

Quem quiser entender mais sobre UX, recomendo sempre o livro "Design Centrado no Usuário" de Travis Lowdermilk. Quem tiver outras recomendações de conteúdo ou mais pinceladas sobre o assunto, aguardo nos comentários.

maniero

1 ano atrás

Huuum... vamos ver.

De fato precisa informar o usuário o que está acontecendo. Não tem que dar detalhes, não tem que encher ele de informação que ele não vai ler e vai clicar em qualquer coisa para sumir aquilo, e não pode vazar informação que pode prejudicar a segurança. Embora em frontend web meio que tanto faz, é tudo inseguro mesmo, se você mandar informação que não deve não é a exceão que vai atrapalhar.

Mas aqui começo falar que não é questão de exceção, é de ter um indicador de erro. Erro recuperável tem que informar o usuário e pedir para ele ajudar a resulver. Erro irrecuperável você informa que fez merda e não deixa piorar. Não deve fazer outras coisa, a não ser que faça muito sentido (não é fácil).

Fora falha de design geral, só tem esses dois tipos de erro, falha pontual de acordo com a infra, da comunicação ou entrada de dados (recuperável) ou erro do programador ou falha generalizada de ambiente (irrecupaerável). Não tente recuperar o irrecuperável. Pode só logar e tentar terminar sem ficar feio. Depois arruma o erro.

Vou passar bem rápido, quando se usa linguagens de script está pedinndo para dar problema na cara do usuário. Precisa testar absurdamente mais que um linguagem mais robusta. Isso deveria pesar muito na escolha, mas as pessoas não fazem assim, elas preferem coisas mais subjetivas para decidir.

Ter ferremantas que ajudam o usuário é correlato, não é o erro/exceção. parte disso foi falado aí.

É claro que achar a mensagem certa é importante. Mas o que eu queria dizer é que potencialmente isso nada tem a ver com exceção. UX do usuário final não costuma ser bom mostrar a exceção. para o programador também pode ser não seja melhor mostrar só a exceção (depende).

Na verdade aqui vou entrar na minha parte favorita: jogar pedra na exceção :D. Uma pena que algumas linguagens criaram isso errado nos anos 90 e um pouco mais, e que bom que as mais modernas abandonaram iso. Pena que algumas culturas abusam de exceções, outras nem tanto. Eu até ach oque deve seguir a cultura vigente. Mas entende oque é mais certo e o que não é. Eu não vou entrar em todos os detalhes aqui.

Exceção é para algo excepcional. O ideal seria só erro irrecuperável (que você nem tanta recuperar, o que é um erro comum que fazem por aí). Em algumas tecnologias faz sentido ter exceções para erros recuperáveis que não deveriam ocorrer, mas você não tem controle, ou seja, não deixam de ser excepcionais. Em tecnologias mais novas até esses erros nãoaõ são considerados excepcionais.

Quando algo é esperado, se a entrada de dados está errada, se pode acontecer algo, aquilo não é exceção. E é um erro conceitual alguém tentar fazer assim. Funciona, mas não é bom.

Exceção é um mecanismo todo errado é deveria ser abolido ou minimizado. Como não dá em certos cenários, devemos usar com mais cuidado e ter estratégias certas. Você pode fazer tudo que a exceção entrega sem ela, só será de um jeito diferente. E o maior problema é que tentaram fazer o mecanismo atender necessidades diferentes.

O correto é ter um mecanismo usando result pattern (recuperável) e um mecanismo de fail fast (até poderia ser uma exceção que não deve ser capturada, mas ser usada só para isto).

Curiosamente que as API do OS ou da web não usam exceções :D E como não quase tudo é falha pontual usam result pattern.

No Brasil há mais gosto por exceção por causa de alguns influenciadores. Algumas técnicas adotadas por modinha pregam mais exceção, mais um motivo para não gostar delas.

Faça o que sua equipe faz, o que sua tecnologia tem cultura de fazer. Mas aprenda que não é certo.

Vou falar mais disso daqui um tempo em blog/canal.

Claro não importa o que faça, precisa dar boas mensagens para o usuário final ou o programador.

Observou? Faz sentido para você?

Espero ter ajudado. Em geral estou à disposição na plataforma (sem abusos :D)

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

obrunoanastacio

Autor

1 ano atrás

Não encher a tela do usuário de informação que ele não saberá ou não precisará consumir já está implicito (ou deveria estar) em qualquer estratégia de UX, e isso não é diferente quando vc precisa decidir o que comunicar na sua mensagem de erro.

"Não falar demais", dando detalhes que ajudam muito mais a vida do ladrão do que do usuário também é outra situação que deveria ser implicita (embora eu tenha presenciado nesta semana uma mensagem de erro em uma dessas maquininhas de cartão de crédito que deveria deixar qualquer Cyberseg de cabelos em pé rsrsr). Ux e segurança sempre estão de lados opostos do cabo de guerra. 2FA é um saco pra experiência do usuário, mas tira só pra vc ver a merd@ que acontece, não é verdade?

Tirando do caminho essas situações acima e as confusões que fazemos com exceções (o que já da um tópico por si), a intenção do texto é cutucar o dev no sentido de que ele sempre estará mais próximo do usuário do que ele acha (ou gostaria de) estar.