Table des matières:
Vidéo: BAD USER INTERFACE / UI EXPERIENCE (Novembre 2024)
Les gens font des erreurs, ce qui explique pourquoi l'interface utilisateur et la conception de logiciels sont si critiques. Il suffit de demander à la Hawaii Emergency Management Agency (HEMA), qui a accidentellement envoyé un faux message de menace de missile balistique entrant aux résidents et aux touristes plus tôt ce mois-ci, les exhortant à se mettre à l’abri.
Plus tard, l'agence a admis qu'un employé avait appuyé sur le mauvais bouton lors du test du système d'alerte de missile, en partie parce que le logiciel mal conçu n'avait aucune protection contre les fausses alarmes.
Aidez un utilisateur
L'incident a incité la FCC (Federal Communications Commission) à lancer une enquête.
"Sur la base des informations que nous avons collectées jusqu'à présent, il semble que le gouvernement d'Hawaï n'ait pas mis en place de contrôle de sécurité ou de contrôle de processus raisonnable pour empêcher la transmission d'une fausse alerte", a déclaré le président de la FCC, Ajit Pai, dans un communiqué. "Les autorités fédérales, nationales et locales de tout le pays doivent travailler ensemble pour identifier les vulnérabilités aux fausses alertes et faire le nécessaire pour les résoudre. Nous devons également veiller à ce que des corrections soient apportées immédiatement en cas de fausse alerte.""
Selon le Washington Post, la seule option entre un test du système et l'envoi d'une vraie alerte au missile était un menu déroulant.
Une bonne interface utilisateur (UI) repose sur l’isolation de fonctions ayant des objectifs différents. Lorsque vous souhaitez séparer un test interne et une commande qui envoie un message critique à des centaines de milliers de personnes, vous devez intégrer des repères visuels. Cela peut être aussi simple que d'utiliser des boutons séparés ou de changer le thème de couleur de l'interface utilisateur lorsque les utilisateurs entrent en mode alerte. Une autre meilleure pratique peut être d'utiliser un "Êtes-vous sûr?" invite avant d'exécuter une commande.
Le système d'alerte de missiles d'Hawaï ne contenait aucune de ces caractéristiques.
Pas de chemin pour corriger les erreurs
HEMA a utilisé les alertes d'urgence sans fil (WEA), un système de sécurité publique qui envoie des alertes à tous les appareils mobiles d'une zone désignée. C’est un moyen efficace d’atteindre de nombreuses personnes très rapidement, mais les WEA se limitent à de courts messages texte. Ils ne peuvent pas contenir d'images, de numéros de téléphone cliquables ni de liens vers des sources en ligne. Les destinataires sont laissés pour approfondir l'examen de l'avertissement.
Ce qui a aggravé l’incident d’Hawaii, c’est que le système n’a pas pu publier de corrections. comme le rapporte la Poste , la Federal Emergency Management Agency (FEMA) donne à la HEMA "la permission permanente… d'utiliser des systèmes d'alerte civile pour envoyer l'alerte au missile - mais pas d'envoyer une alerte ultérieure de fausse alerte".
De toute évidence, l'équipe de conception n'avait pas pensé qu'un opérateur pouvait appuyer sur le mauvais bouton. HEMA a publié un tweet de mise à jour environ 13 minutes après l'envoi de l'alerte initiale, mais le message n'a pas été envoyé à autant de personnes que WEA. 38 minutes se sont écoulées avant l'envoi d'un deuxième message WEA, informant tout le monde qu'il n'y avait "PAS de menace antimissile".
"Une partie du problème était qu'il était trop facile, pour quiconque, de faire une telle erreur, a déclaré un porte-parole de HEMA à la poste . Il a également déclaré que l'agence avait suspendu les exercices et ajouté des garanties au système, y compris une invite à confirmer l'intention de l'opérateur avant l'envoi d'une alarme.
L’incident d’Hawaï rappelle que des erreurs de conception aussi minimes que le choix des mauvais éléments de l’UI et le non-respect de fonctionnalités simples peuvent avoir de vastes répercussions. Cela souligne les responsabilités cruciales des développeurs et des ingénieurs en logiciels à mesure que les logiciels deviennent omniprésents.
Quant à l'employé qui a commis l'erreur, il ne sera pas viré, selon le porte-parole de HEMA. Ce n'est que juste. Lorsque le logiciel échoue lamentablement, les développeurs, et non les utilisateurs, doivent être tenus pour responsables.