Un «message d'erreur» doit-il s'afficher avant ou après l'interaction avec l'utilisateur?
Dans une application Web, nous avons une fonctionnalité qui permet aux utilisateurs de reprogrammer un rendez-vous qu'ils ont déjà réservé, en cliquant sur un appel à l'action/un lien sur leur page de résumé.
Cependant, il existe certaines règles commerciales à ce sujet - nous n'autorisons pas les utilisateurs à replanifier le rendez-vous la veille de leur rendez-vous existant après 12h00, nous devons donc informer l'utilisateur qu'il ne peut pas modifier son rendez-vous.
Je vois 3 options pour gérer les messages d'erreur dans ce contexte:
- Lorsque l'utilisateur clique sur le lien, affiche un message d'erreur
- risque de décevoir l'utilisateur, car il s'attendait à pouvoir changer le rendez-vous et maintenant il ne peut pas
- Afficher le message d'erreur lors du chargement de la page, afin que l'utilisateur sache qu'il ne peut pas modifier le rendez-vous et désactiver le lien
- risque de déranger l'utilisateur, car nous lui montrons un message d'erreur anticipant un voyage qu'il n'avait pas prévu de faire
- Masquer le lien lorsque les règles métier sont respectées (c'est-à-dire après la date limite de midi) et que l'utilisateur ne peut rien faire *
- l'utilisateur peut être frustré de ne pas pouvoir changer de rendez-vous et ne dispose d'aucune information pour le guider
Quelle approche, 1, 2 ou 3 (ou autre chose?) Est la meilleure expérience utilisateur?
Je penche vers l'option 2, mais afficher un "message d'erreur" lorsque seule une partie des utilisateurs se rendrait sur la page semble un peu contre-intuitif.
En tant que principe général, je considère toujours les messages d'erreur comme une conception/interface utilisateur inférieure, ce qui dans la plupart des cas peut et doit être évité. Si l'interaction utilisateur déclenche un message d'erreur, pourquoi l'interface utilisateur permettrait-elle aux utilisateurs l'option en premier lieu?
Exemples:
- message d'erreur "le mot de passe n'est pas assez bon" -> mieux: indicateur en direct pour signaler la force du mot de passe
- message d'erreur "nom d'utilisateur pris" -> mieux: indicateur en direct pour signaler la disponibilité
- message d'erreur "veuillez remplir le champ obligatoire x" -> mieux: désactiver le bouton d'enregistrement jusqu'à ce que tous les champs obligatoires soient remplis (et indiquer clairement quels sont les champs obligatoires)
Dans votre cas, je préférerais une variante de l'option 3, mais avec une icône info/survol en ligne. Quelque chose comme ça:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Pour attraper le scénario (peut-être exotique) des utilisateurs allant à la page avec le bouton, puis attendez x fois, puis essayez de reprogrammer, vous pouvez toujours conserver une validation avec un message d'erreur derrière le bouton.
Afficher un notification et éventuellement une erreur.
Gardez votre interface cohérente et affichez le lien. Vous pouvez simplement le désactiver et afficher une notification. Ce ne sera pas ennuyeux si c'est amical et informatif. Au contraire, cela rendrait service à vos utilisateurs! Il ne crée pas d'attentes trompeuses avec un lien de travail ou de la confusion en masquant le lien tout d'un coup.
Si quelqu'un n'a pas encore rechargé la page et voit le lien activé, affichez une erreur lorsqu'il est cliqué. Cela peut ne pas se produire souvent mais fera une meilleure expérience quand cela se produira.
Je ne pense pas que vous devriez jamais présenter un message d'erreur jusqu'à ce que l'utilisateur en déclenche un.
Par exemple, je déteste quand les sites déclenchent une erreur de validation pour un champ obligatoire sur lequel j'ai cliqué ou tabulé, mais je n'ai pas encore entré de valeur non valide.
Ainsi, dans votre cas, je n'afficherais une note/un avertissement/un message d'erreur que si l'utilisateur tentait de choisir une date/heure antérieure à un seuil donné.
De plus, j'ai toujours préféré fournir une interface utilisateur qui aide l'utilisateur en restreignant les options qui pourraient les coincer dans une condition d'erreur. Par exemple, si vous choisissez une date pour un événement futur, le contrôle du champ de date/calendrier ne devrait même pas permettre la sélection de dates avant aujourd'hui.
J'opterais pour l'option 2, mais sans afficher le message explicitement. Il suffit de désactiver le lien et de placer le message d'information dans son attribut title, afin que l'utilisateur le voie lors du survol du lien. De cette façon, seuls ceux qui souhaitaient annuler un rendez-vous recevraient l'information.
De plus, vous pouvez placer ? signe avec une mise en forme "désactivée" similaire, qui peut contenir le même message dans son title, conduit à une page avec une explication des réglementations commerciales, ou les deux.
Je pense que la réponse 2 est la meilleure option, mais elle a besoin de quelques ajustements mineurs. Avec un message d'erreur, incluez les informations sur comment et quand vous pouvez reprogrammer le rendez-vous. Pour que l'utilisateur se sente à l'aise avec le flux de changement de rendez-vous.
La façon la plus appropriée à mon avis devrait être de désactiver le bouton de replanification et un message informatif déjà écrit à côté ou en dessous du bouton de replanification indiquant à l'utilisateur que le rendez-vous ne peut pas être reprogrammé car le temps restant dans son rendez-vous est inférieur à 24 heures, ou quel que soit le condition s'applique.
Donc, si c'est la règle commerciale, il est évident de suivre, mais en considérant le VOYAGE DE L'UTILISATEUR, voici ce que vous pouvez faire:
Première approche - Montrez-leur le lien de changement de rendez-vous, car je crois que nous leur donnons la flexibilité avec cette fonctionnalité.
Réaction de l'utilisateur - L'utilisateur a vu le lien, il est éduqué et satisfait de le savoir jusqu'à présent.
Deuxième approche - Permettez-leur de cliquer et d'avancer afin qu'ils prennent conscience de cette fonctionnalité et des mêmes souvenirs; Parce que parfois, ce sera le bon moment où ils seront autorisés à reprogrammer la même chose.
Réaction de l'utilisateur - L'utilisateur a expérimenté la fonctionnalité et est content.
Troisième approche - Permettez-leur de cliquer mais affichez et un message d'erreur afin qu'ils soient également éduqués avec la LIMITATION, je répète avec LIMITATION des fonctionnalités, évidemment il/elle pourrait être déçu mais je suppose une règle commerciale appropriée la justification pourrait l'aider à se calmer.
Assurez-vous que toute l'éducation, qu'elle soit positive ou négative, est fournie avec un modal, où l'utilisateur peut lire le contenu en plein centre de l'écran et l'accepter avec le bouton OK.
C'est ce que je pense qui pourrait bien fonctionner, mais vous êtes toujours le meilleur juge.