Concevoir pour l’erreur

Comment concevoir pour l’erreur ? Voici une question ô combien importante, mais que peu de sites web ou d'applications prennent réellement en compte.

Les humains ne sont pas à l'abri de faire des erreurs. En fait, se tromper, c'est être humain. Les systèmes doivent donc tenir compte des sources d'erreurs. Il doit y avoir un mécanisme de feedback qui permet à l'utilisateur d'avoir des informations sur la série d'actions à l'intérieur du système. Chaque fois qu'une erreur s'est produite, le feedback doit être concis et exploitable.

Je ne sais pas ce que j'ai fait. Il a ouvert un tas de pop-ups et a planté le programme. Je ne veux plus jamais l'utiliser à nouveau; c'est frustrant.

Ainsi, avant d'approfondir et de découvrir comment développer ou concevoir pour l'erreur, il est important de définir certains points. Que voulons-nous dire lorsque nous parlons d'erreur, qu'est ce qu'une erreur précisément ? Autre point important, quels facteurs contribuent aux erreurs ? Cette question revient à s'interroger sur ce qui poussent les utilisateurs à la faute.

Qu'est ce qu'une erreur ?

Les erreurs peuvent être divisées en deux grandes catégories: (1) les erreurs et (2) les maladresses.

La division se produit au niveau de l'intention : une personne manifeste son intention d'agir.

Si l'intention n'est pas appropriée, c'est une erreur. Si l'action n'est pas celle qui était prévue, il s'agit d'une maladresse.

D. Norman & C. Lewis, 1995, p. 686–697

De plus, on peut catégoriser les erreurs cognitives (erreurs) et non cognitives (maladresses). Les erreurs sont des erreurs dans le choix d'un objectif ou la spécification d'une méthode pour atteindre un objectif, tandis que les maladresses sont le résultat d'un échec dans la mise en œuvre d'une méthode prévue pour certaines actions.

Dans la conception, l'erreur peut concerner des actions à la fois en référence à l'utilisateur et au produit: le plan d'action qui génère des résultats inattendus. Du côté de l'utilisateur, des erreurs peuvent survenir à la suite de modalités d'actions cognitives et non cognitives. Nous nous intéressons à l'utilisateur final et à la manière dont le système doit réagir aux actions erronées de ce dernier.

Quels sont les facteurs contribuant aux erreurs ?

Généralement, les facteurs contributifs qui entraînent un événement d'erreur ne sont pas sans cause contingente. En d'autres termes, il y a une accumulation de facteurs contributifs qui conduisent à l'événement d'une erreur. De plus, il ne s'agit généralement pas de problèmes de processus mais de facteurs humains qui conduisent à des erreurs. Nous souhaitons segmenter ces facteurs du côté de l'utilisateur pour orienter la conception de produits centrés sur l'utilisateur.

Il existe deux dimensions que nous pouvons prendre en compte pour les événements qui provoquent des erreurs du côté de l'utilisateur.

• Seuil cognitif : il se rapporte à la quantité d'informations et au processus de décision présenté. Les extrêmes provoquent une surcharge cognitive qui peut être déroutante, frustrante et difficile pour les utilisateurs à manœuvrer leurs tâches.
• Seuil sensori-moteur : il se rapporte aux stimulants des signaux perceptuels et à la sphère des possibilités une action, précédée d'un moteur, peut avoir lieu (par exemple la chaîne de caractères est précédée de l'acte de taper). Les extrêmes peuvent provoquer une surcharge sensorielle qui se produit lorsque nous sommes confrontés à des indices de perception trompeurs tels que la graisse d'une police faite inutilement.

Les systèmes compliqués nécessitent une simplification et une organisation des contenus pour communiquer plus efficacement une série d'actions effectuées par l'utilisateur. Ne pas tenir compte des événements erronés dans de tels systèmes est une recette pour un désastre.

Les messages d'erreur sont irritants. Les conséquences de l'erreur humaine vont d'une gêne mineure à une perte de productivité. C'est pour cette raison qu'il est important de concevoir pour l'erreur, et de prendre en compte les confusions potentielles. Par conséquent, les interfaces au travers desquelles le système est conçu doivent être réduites au minimum, car il ne faut pas supposer uniquement l'idéal, mais aussi les cas d'erreurs et leurs effets sur le système.

En programmation, nous avons cette notion de méthodes de gestion des erreurs qui incorporent brièvement le principe d'autonomie d'action et de feedback en quelque sorte qui peut atténuer la propagation de l'erreur dans le système. De même, les principes qui régissent la logique de conception des programmes s'appliquent également à d'autres domaines.

Comment concevoir pour l'erreur ?

Supposons que vous êtes sur le point de faire une transaction avec votre collègue d'un autre pays. Vous êtes au Laos tandis que votre ami aux États-Unis. Le taux de change entre un dollar américain et un kip laotien est de 1,00 $: 9 009,04 ₭. Supposons que vous ayez entré les chiffres dans le mauvais champ; au lieu de Kip laotien, vous avez entré les dollars américains. Imaginez à quel point cela pourrait être problématique si la transaction avait lieu sans feedback clair du système.

Certains systèmes aggravent le problème en le rendant facile à commettre des erreurs mais difficile ou impossible à découvrir ou à récupérer de celui-ci. Premièrement, nous devons comprendre les capacités et les limites de nos utilisateurs. Nos systèmes devraient également être responsables des maladresses et des erreurs. Le novice du produit est enclin à faire des erreurs - les instructions ne doivent pas être ambiguës et trop détaillées - tandis que les experts sont enclins à faire des maladresses - fournissent un mécanisme de feedback pour atténuer les effets des erreurs.

Afin de concevoir pour l'erreur, le psychologue cognitif Donald Norman a fourni les points clés suivants :

• Comprendre les causes d'erreur et développer pour minimiser ces causes.
• Faites des contrôles de sensibilité. L'action passe-t-elle le test du «bon sens» ? Y a-t-il une anomalie dans le modèle de comportement effectué dans une telle tâche ?
• Permettre d'inverser des actions - de les «annuler» - ou de rendre plus difficile de faire ce qui ne peut pas être inversé.
• Aider les utilisateurs à découvrir plus facilement les erreurs qui se produisent et à les corriger plus facilement.
• Ne pas traiter l'action comme une erreur. Il est préférable de plutôt essayer d'aider la personne à terminer l'action correctement. Considérez l'action comme une approximation de ce qui est souhaité.

Signaler les erreurs

Les concepteurs de système doivent respecter les principes suivants lorsqu'ils tentent d'informer l'utilisateur qu'une erreur s'est produite.

1. Le message d'erreur doit être facile à remarquer et à comprendre.
2. Le ou les champs en erreur doivent être faciles à localiser.
3. Les utilisateurs ne devraient pas avoir à mémoriser les instructions pour corriger l'erreur.

Références :

• Baecker, RM (éd.). (2014). Lectures en interaction homme-machine: vers l'an 2000 . Elsevier.
• Norman, D. (2013). Le design du quotidien: édition révisée et augmentée.
• AIGA San Francisco (2017). Conception d'erreurs. Consulté sur: http://aigasf.org/designing-for-errors-key-takeaways/
• Juge Cooke, McMahon CA, North MR (2003) Sources d'erreur dans le processus de conception. Dans: Gogu G., Coutellier D., Chedmail P., Ray P. (éds) Récentes avancées dans la conception et la fabrication intégrées en génie mécanique. Springer, Dordrecht.
• Krause , R. (2019). Comment signaler des erreurs dans les formulaires: 10 directives de conception.

Librement traduit de l'article Designing for error - Icone : Head by Komkrit Noenpoempisut from the Noun Project