Dois-je préférer la «prévention la plus précoce» aux «flux de travail flexibles»?
Intro
J'ai une spécification qui mentionne explicitement 4 (sic!) Fenêtres modales interdépendantes pour un cas d'utilisation assez simple. Cela semble être le résultat de la façon de penser à l'ancienne, c'est-à-dire "définissons les exigences comme comment exactement les choses devraient fonctionner" au lieu de "définissons la définition du problème en termes plus larges". En d'autres termes, problème classique "COMMENT" vs "QUOI".
Voici les exigences et mes réflexions. Veuillez examiner, fournir des commentaires, faire vos propres recommandations.
Exigences d'origine
Créer un nouveau lot - Ouvre une boîte de dialogue qui permet aux utilisateurs de saisir l'ID et la description du lot, de sélectionner la date de fin de la période de paie dans une liste déroulante ... et de sélectionner le service de distribution dans une liste déroulante ...
L'identifiant du lot, la date de fin de la période de paie et le service de distribution sont requis ..., les utilisateurs peuvent sélectionner "Créer" ou "Annuler"
- Si l'utilisateur crée un lot avec le même ID qu'un autre lot dans cette période de paie et ce service de distribution, affichez le message "Cet ID de lot existe déjà pour cette période de paie, veuillez entrer une valeur différente"
- Si l'utilisateur crée le nouveau lot, une autre fenêtre contextuelle s'affichera demandant "Voulez-vous ouvrir le nouveau lot maintenant". La sélection de "Oui" remplira les paramètres de recherche avec les valeurs du lot et ouvrira le lot, la sélection de "Non" fermera les fenêtres contextuelles et permettra à l'utilisateur de rester sur le même écran
- Si l'utilisateur sélectionne "Oui" et qu'il y a des transactions non enregistrées, affichez l'invite "Voulez-vous enregistrer les modifications avant d'ouvrir ce lot?" et avoir un bouton Oui, Non et Annuler
Simplifiez UX
Je pense qu'un meilleur UX aura une fenêtre modale unique au lieu de plusieurs.
Il y aura une fenêtre modale pour entrer les informations de base du lot. Cela reste tel qu'il est décrit dans la section "Créer un nouveau lot".
La fenêtre "Cet ID de lot existe déjà" est supprimée. Il peut y avoir une notification d'erreur de validation à côté du bouton "Créer" qui s'affiche en cas d'échec de la création d'un lot.
La fenêtre "Voulez-vous enregistrer les modifications" est supprimée. Cela peut être réalisé en désactivant les mécanismes de création de lots tant qu'il y a des changements sur la page que nous ne voulons pas perdre. En d'autres termes, je souhaite que l'utilisateur enregistre sa précieuse entrée avant d'essayer de créer un nouveau lot.
La fenêtre "Voulez-vous ouvrir le nouveau lot maintenant" est supprimée. Il y aura un bouton supplémentaire "Ouvrir le lot créé" à côté de "Créer" et "Annuler". Le bouton n'est affiché/activé qu'après une création de lot réussie.
Cela réduira donc le nombre de modaux de 4 à un, et le flux complexe sera remplacé par un liner (plus simple). Cela me facilitera les choses, car les systèmes complexes sont difficiles à construire et à entretenir. Je ne veux cependant pas trop simplifier le système, c'est-à-dire au prix de l'UX "optimal"/"idéal".
Question
Ma façon de penser est-elle la voie à suivre dans cette situation?
Dois-je simplifier l'UX en empêchant certains scénarios en premier lieu au lieu de réagir à leurs conséquences?
Est-ce une mauvaise chose que le workflow soit moins flexible (plus linéaire) dans ce cas?
P.S. Je suis un développeur de pile complète qui possède pas possède un diplôme en conception ou des principes de conception solides/principes UX. Par conséquent, la plupart de mes opinions et décisions sont motivées par la simplicité du système.
P.P.S. J'ai essayé de rechercher des questions similaires, mais je n'y étais pas trop bon. @Moderators, faites-moi savoir si des parties de ma question violent les règles et je les mettrai à jour ou même les supprimerai.
Votre idée de supprimer les modaux semble être la bonne façon de procéder - jusqu'à l'étape trois. Désactiver la fonctionnalité de base simplement parce que nous voulons supprimer un modal me semble assez exagéré et gênerait de nombreux utilisateurs. Ils essaient de créer un nouveau lot après avoir modifié d'autres informations, mais le bouton est absent ou désactivé. Comment sauraient-ils qu'ils doivent enregistrer leurs modifications pour faire réapparaître ce bouton?
Je vous suggère de garder le bouton "Créer un nouveau lot" disponible même s'il y a des modifications non enregistrées. Enregistrez-les automatiquement ou demandez à l'utilisateur s'il souhaite le faire avant d'en créer un nouveau. J'ouvrirais même le nouveau lot pour eux par défaut. S'il y a quelque chose que les utilisateurs veulent généralement faire dans le lot après l'avoir créé, ils voudront probablement le faire tout de suite.
Bien sûr, les conseils ci-dessus peuvent ne pas avoir de sens si le flux de travail et l'architecture du système sont différents de ce que je suppose. Vous voudrez peut-être concocter quelques maquettes d'interface utilisateur et faire des recherches sur les utilisateurs pour savoir ce qu'ils s'attendent à ce qu'ils se produisent lorsqu'ils interagissent avec votre système.