lei
Lei de Tesler
Toda aplicação tem uma quantidade inerente de complexidade irredutível. A única pergunta é: quem vai ter de lidar com ela — o usuário, quem faz a aplicação ou quem faz a plataforma?
A complexidade não some: decida se ela fica com você ou com quem usa.
O outro nome dela explica melhor: conservação da complexidade. Larry TeslerFormulou a lei da conservação da complexidade: ela não some, só muda de lado, do usuário para o desenvolvedor, ou o contrário.Uma referência neste trabalho:1984The law of conservation of complexityVer na bibliografia →, que trabalhou na Xerox PARC e na Apple, observou que todo sistema tem uma quantidade de complexidade que não pode ser eliminada, só transferida. Se o programa não faz, alguém faz. A pergunta que a lei coloca não é "como simplificar", é quem vai pagar esta conta, cada pessoa que usa, o time que constrói o produto, ou quem constrói a plataforma sobre a qual o produto é feito. Uma tela limpa demais costuma ser uma tela que empurrou o trabalho para o outro lado.
Por que aqui não há neurociência
O mecanismo biológico por trás do efeito, e o quanto dele foi de fato medido.
Tesler é um axioma de projeto sobre onde alocar complexidade, e não um fenômeno com assinatura mensurável: a complexidade inerente a uma tarefa não desaparece, então a única decisão real é quem paga por ela, o sistema ou quem usa. Não há efeito a explicar, logo não há mecanismo cerebral a apresentar. O que sustenta esta lei é a experiência acumulada de quem constrói sistemas.
Por que esta lei não presume corpo nenhum
Em quem isso foi medido, e o que muda quando o corpo do outro lado é outro.
A complexidade não some, e esta lei é sobre onde ela vai parar. Ela vale igual para qualquer pessoa. Quem acaba pagando a conta costuma ser quem tem menos repertório e menos tempo para gastar.
Como o design traduz
O que fazer com isso numa tela, sem transformar um achado em regra.
Como medir isso no seu produto
Num painel financeiro, exibir todos os cálculos na tela obriga a pessoa a carregar cada fórmula na cabeça e a decidir, linha a linha, o que importa. A alternativa é absorver a complexidade em algoritmos de suporte, mostrar os resultados-chave e oferecer a explicação sob demanda, para quem quiser conferir. O e-mail é o exemplo de todo dia: por mais que se redesenhe um cliente de e-mail, alguém tem de dizer para quem vai e o que está escrito. Essa parte não comprime, e é só o resto da tela que dá para tirar da frente.
Onde isso quebra
Onde a lei não vale, vale menos, ou vale ao contrário.
Absorver complexidade demais também quebra. Quando o sistema decide tudo, quem usa perde a capacidade de conferir e de corrigir, e passa a depender de um acerto que não consegue auditar.
Um caso
Um produto de verdade em que isto apareceu, com o que aconteceu e onde conferir.
As três caixas que seguravam US$ 894 milhões
S.D.N.Y. · decisão de 16/02/2021 (interface do Flexcube, Oracle) · Uso editorial
Em agosto de 2020 o Citibank queria pagar cerca de US$ 7,8 milhões de juros aos credores de um empréstimo da Revlon. No sistema usado pela operação, qualquer pagamento sai como transferência a menos que o operador suprima esse padrão, e para reter o principal era preciso marcar três campos de nome críptico. O operador marcou um. O revisor e o aprovador concordaram que bastava. A tela final avisava que os fundos sairiam do banco e perguntava se queria continuar, sem dizer quanto. Saíram US$ 893.944.008,52 além dos juros. A complexidade de não mandar o dinheiro ficou inteira com quem operava, e três pessoas experientes erraram do mesmo jeito, que é o que a lei prevê quando o sistema não absorve nada. A primeira decisão judicial, em 2021, deixou com os credores os cerca de US$ 500 milhões que eles se recusaram a devolver; a segunda instância reverteu em 2022 e o banco recuperou o dinheiro.
In re Citibank August 11, 2020 Wire Transfers, S.D.N.Y., 2021
Experimente
Uma peça para conferir no seu próprio corpo o que o texto acabou de afirmar.
Até onde dá para remover complexidade
A Lei de Tesler diz que todo sistema tem uma quantidade de complexidade que não dá para eliminar, e aqui quem faz o papel do sistema é a frase abaixo. Clique em qualquer palavra ou expressão para removê-la, e de novo para devolver. O semáforo ao lado diz se a frase ainda faz sentido, se perdeu informação, ou se parou de funcionar.
Faz sentido
A frase continua dizendo tudo o que dizia.
Agora segure o principal
A tela do caso, reduzida. Você quer pagar só os juros e reter o principal. Marque o que for preciso e confirme.
| Componente | Sobrescrever a instrução padrão |
|---|---|
| FRONT | |
| FUND | |
| PRINCIPAL |
Account used is Wire Account and Funds will be sent out of the bank. Do you want to continue?
Todo sistema tem um núcleo de complexidade que não pode ser eliminado, só deslocado. O que você tirou antes do vermelho não sumiu: passou a ser trabalho de quem lê.
Fontes
Enunciado citado de Tesler, 1984.
- TESLER, L. The law of conservation of complexity. c. 1984. Fonte
Leitura complementar: Tesler’s Law Laws of UX em inglês