Ce principe de conception exige que tous les aspects négatifs possibles soient rendus explicites. Si des aspects négatifs ne sont pas rendus explicites, alors des utilisateurs seront négativement étonnés tôt ou tard.
Exemples :
Mettez cela en perspective avec la SécuritéParObscurité et la PratiqueTrompeuse.
La description ci-dessus en fait partie, mais elle n'est pas assez basique pour saisir ce que signifie EviterIllusion. La SécuritéDouce est construit sur la confiance. EviterIllusion ne consiste pas à ne pas donner de la fausse confiance non méritée. En citant la SécuritéDouce, "Un système faible de sécurité peut être pire que pas de sécurité du tout, parce qu'il peut apaiser les utilisateurs dans une confiance sans garantie. Les NomUtilisateur sans mots de passe peuvent être plus sûrs qu'avec, parce que chacun saura qu'ils sont forgeables." Peut-être que cela peut être récapitulé en "Ne construisez pas de barrières en papier. Si vous faites en sorte qu'il semble que vous ayez une sécurité inattaquable, les gens se comporteront plus lâchement parce qu'ils feront confiance dans le fait que la sécurité rattrapera tous les problèmes. Cependant, si elle n'est pas inattaquable, quand la sécurité est fissurée, les personnes ne seront pas préparées à traiter la situation. Elles ne pourraient même pas se rendre compte qu'il y a une situation à traiter.
Un autre problème avec la sécurité semblant "inattaquable" est qu'elle semble attirer des attaquants et des vandales recherchant un défi (qui est probable, étant donné que la meilleure défense contre cela est d'attendre jusqu'à ce qu'ils s'ennuient et s'en aillent... ce qui les met dans une humeur pour rechercher un autre défi). Peut-être avez-vous vraiment une sécurité inattaquable, mais vous pouvez-vous vous permettre d'avoir votre force quotidienne vidangée parce que les attaquants et les vandales sondent et examinent votre sécurité ?
Mettez cela en perspective avec : CroireMaisVérifier et TolérerAmbiguïté?.