A parte de um software deve comportar-se como os utilizadores esperam que se comporte e, portanto, não surpreeender os utilizadores
Este é um princípio a ser seguido na relação do utilizador com uma parte do software. A parte pode ser algo pequeno como um método, pode ser uma API, pode ser uma UI, pode ser um sistema de aplicações, regras de negócios… enfim, pode ser qualquer parte do software. O utilizador é o ser humano que vai interagir com essa parte.
O Princípio da Mínima Surpresa afirma que:
A parte de um software deve comportar-se como os utilizadores esperam que se comporte e, portanto, não surpreeender os utilizadores
Aqui o ponto complexo é "comportar-se como esperam". É necessário saber e compreender qual o comportamento que o utilizador espera. Saber esta informação é mais profundo e complexo do que parece.
A primeira coisa que voce precisa lembrar é:
É muito comum ouvir justificações como "se fosse eu a usar, eu gostaria que…". O uso deste conceito de que o criador é também um utilizador é uma falácia e não vai levar a bons resultados.
Para obter bons resultados é preciso duas coisas
Grupos de Foco - Conversar com os utilizadores reais e compreender qual o comportamente que eles esperam
Benchmarking - Observar como os utilizadores reais utilizam um software similar, entender o que eles gostam e não gostam, e emitar o comportamente desse software nas partes que eles gostam e fazer diferente nas que não gostam.
Padrões da Indústria - Utilizar padrões já conhecidos da industria e que frequentemente são utilizados
Quando o software sendo desenvolvido é totalmente novo e não ha concorrentes no mercado é necessário recorrer a grupos de foco. Grupos que pessoas que dão a sua opinião sobre como o software faz mais sentido ser utilizado. É um processo de várias iterações, indo e voltando, até que se chega num consenso.
Durante este processo iterativo, a base são alguns padrões já conhecidos da indústria. Por exemplo, é sabido que porporções de aproximadamente iguais à proporção dourada são mais agradáveis à vista. Então devemos começar com esse padrão e depois iterar conforma o feedback do grupo.
Para software que compete com outros, é sempre bom dar uma olhada na concorrência e ver o que os utilizadores gostam e não gostam no outro software. Isto, junto aos padrões de indústria nos dá uma base para começar.
O software pode ser novo e tentar discomper o status quo. Pode existir uma surpresa no sentido do software realizar algo que o usuário não esperava, e isso ser bom: uma boa surpresa, mas o inverso não é bom. O Príncipio da Mínima Surpresa se refere implicitamente à "má surpresa", não se refere à boa surpresa.
Na essência o Príncipio da Mínima Surpresa é sobre não fustrar as expectativas do utilizador. Se este principio não for respeitado o usuário dirá que o software é complexo e complicado de usar. O modelo mental que o usuário criou usando outros softwares, não se aplica aqui e isso fustra o utilizador.
O software não é palpável. Não é sequer o código que o compõe. O software é um modelo mental partilhado entre o utilizador e o computador.
Cada software precisa de uma metáfora adquada ao seu trabalho. Por exemplo, um software de cliente de e-mail funciona com base na metáfora de caixa de entrada e caixa de saída que era comum nos escritórios quando esse tipo de software foi inventado. Software de cáculos como o excel é baseado na metáfora de linhas e colunas que formam células: ou seja, tabelas. Contadores e pessoas de finanças estavam habituadas a trabalhar com tabelas antes do software existir. Softwares de registro usam a metáfora do formulário. Um conjunto de campos que precisam ser preenchidos, tal qual seriam os formulários em papel na época. Software de música e video usa a metáfora da lista (playlist) que já era comum mesmo nos tempos da fitacassete e os comandos de interação são os mesmos usados nesses aparelhos populares.
Cada software tem que ter e seguir uma metáfora correspondente à sua área de atuação. Ele pode melhorar a metáfora, mas o que o Príncipio da Mínima Surpresa significa é que não pode ir contra ela. Tentar criar um sistema de tocar música usando formulários ou caixa de entrada/sáida não vai fazer sentido e vai supreender o usuário pela negativa.
O Príncipio da Mínima Surpresa surgiu em 1967, no projeto PL/I - uma linguagam de programação publicada pela IBM em 1966. Acontecia que em PL/I o cálculo 25 + 1/3 ou a sua contrparte 1/3 + 25 não resultada no esperado 25.33333333333, e sim, no supreendente valor 5.33333333333.
O Príncipio da Mínima Surpresa - então chamado Lei da Mínima Surpresa - foi primeiramente posto por escrito em 1972 dizendo o seguinte:
Como o foco orignal eram as linguagens de programação e as API, se fala de "como a sua sintaxe sugere". Seria muito estranho que um método chamado "soma", fizesse uma multiplicação. O ponto é que ao ler uma certa sintaxe "soma" isso cria um modelo mental no utilizador - neste caso, o programador - que o leva a usar o construto como uma soma. Quando ele descobre que o comportamento não é esse, se dá a surpresa. A má surpresa.
Podemos ler no texto as partes essenciais
A parte deve seguir o modelo mental proposto.
A parte deve seguir convenções anteriomente estabecidas. Violações devem ser excecionais e mínimas.
O designer deve ajustar as escolhas ao modelo mental do utilizador, não o inverso.