Les boutons non disponibles dans un assistant doivent-ils être désactivés ou masqués?
Sur un formulaire d'assistant, j'ai les boutons de navigation, d'enregistrement et d'annulation.
Actuellement, je désactive les boutons en fonction du contexte. Le bouton Enregistrer est activé lorsque l'utilisateur peut réellement enregistrer (c'est-à-dire la dernière page).
Le technicien QA me dit que les boutons doivent être cachés. Je ne veux pas faire ça; parce qu'ils sont alignés à droite, les boutons "précédent" et "suivant" changeraient de position et je ne peux pas imaginer que ce soit une bonne chose.
Alors, dois-je réellement cacher ces boutons? J'ai lu sur les sorciers mais je n'ai trouvé aucun endroit mentionnant cette situation particulière.
Modifier - Y compris un échantillon de la page que je mentionne.
Non, ils ne devraient pas être cachés, et pas seulement à cause de la cohérence, bien que ce soit important, mais aussi parce que si vous les cachez, vous cacherez ce que le système peut faire à l'utilisateur. L'utilisateur doit savoir que l'enregistrement est généralement disponible, même s'il est désactivé pour le moment (il existe donc certaines conditions que l'utilisateur doit respecter pour activer cette fonctionnalité).
Toutefois. Puisque vous avez mentionné que la position d'un bouton sera affectée par la présence d'autres, j'espère que la chaîne de boutons dont vous parlez ne ressemble pas à une plage d'opérations. La navigation doit être séparée des opérations (Enregistrer et annuler). Sinon, il est très facile de cliquer sur le mauvais bouton ou d'interrompre l'assistant avec de nombreuses informations remplies lorsque vous ne souhaitez que faire un pas en arrière.
Ainsi, non seulement ils doivent toujours être en surface, mais ils ne doivent pas non plus être regroupés par positionnement.
Bon exemple 
Mauvais exemple 
En tant qu'utilisateur, je préférerais le Next bouton pour passer à Save sur le dernier écran.
En dehors de cela, je préférerais désactiver la sauvegarde avec une info-bulle expliquant pourquoi elle est désactivée.
Bien qu'il soit possible d'avoir < Back et Next > boutons sur une ligne distincte, de sorte qu'ils ne bougent pas lorsqu'un nouveau bouton apparaît soudainement dans la boîte de dialogue suivante.
Sur la base des brefs détails initiaux que vous avez partagés ici, je recommande définitivement pas de masquer ces boutons, même s'ils ne sont pas immédiatement pertinents pour l'utilisateur dans la vue de l'assistant que vous envisagez.
Chaque fois que nous pouvons fournir aux utilisateurs des files d'attente contextuelles et visuelles qui ne distraient pas de l'action globale de l'objectif, mais qui la rehaussent réellement, nous devrions le faire. Je pense que ce cas s'applique certainement ici car il aidera à orienter et à préparer l'utilisateur à finaliser l'action de l'objectif bien avant le clic final. Après tout, l'assistant est inutile à moins que les utilisateurs ne le terminent, n'est-ce pas?
C'est ce que je partagerais avec le technicien QA, je suppose. Ou, vous pouvez leur demander sarcastiquement si ce sont ceux qui sont réellement embauchés pour concevoir UX, et emprunter la voie du designer mécontent! (Toujours un favori personnel;) Bonne chance!
La question que je lui poserais est
What are the particular downsides to designing it the way I suggested
Le changement des boutons précédent et suivant n'est jamais vraiment une bonne chose dans une série d'étapes. Le mot clé est la cohérence.
Definr définit la cohérence comme:
- Cohérence logique et conformité.
- Une uniformité ou un accord harmonieux entre les choses ou les parties.
Vous ne pouvez pas vraiment être cohérent si vous déplacez les boutons. Les utilisateurs ont également une idée de l'emplacement de ces boutons et cette idée est basée sur l'utilisation d'une tonne de systèmes au fil des ans.
Je vous suggère également de rechercher les meilleures pratiques pour les assistants avant de le concevoir (juste au cas où vous ne l'auriez pas fait).
Je vais aller dans l'autre sens et dire: Masquer les boutons inutiles. Gardez le ballonnement visuel le moins possible. Pour moi, un bouton désactivé signifie que je dois sélectionner une option pour l'activer. Un exemple de ceci est de cocher la case "J'ai lu et j'accepte le CLUF", qui doit souvent être cochée avant que le bouton Suivant ne soit disponible. Un autre exemple consiste à choisir ce que vous souhaitez installer, et lorsque rien n'est vérifié, le bouton Suivant sera souvent désactivé.
Dans ce cas, l'action d'activer le bouton n'est pas disponible sur un seul écran, mais l'utilisateur doit parcourir plusieurs écrans pour l'activer. À mon avis, cela signifie que le bouton Enregistrer ne devrait pas être sur chaque page.
L'option standard, utilisée dans la plupart des packages d'installation ou assistants, consiste à remplacer le bouton Suivant par Installer (ou dans ce cas, Enregistrer). Pour moi, c'est la meilleure option.
Cela entraînera également moins de confusion pour les clients, car ils n'auront pas à se soucier de ce que Save fait et signifie réellement. Si le bouton Enregistrer est disponible (même s'il est désactivé!) Sur chaque page, le bouton peut avoir plusieurs significations, comme "Enregistrer la progression dans cet Assistant". Étant donné que vous ne voulez pas de cette confusion, je vois la cacher ou utiliser la "norme de l'industrie" consistant à simplement avoir Back et Next, et à remplacer Next par Save sur le dernier écran. (Tout comme la première capture d'écran de la réponse de Zoe Kulsariyeva en passant)