Conception de formulaire à plusieurs colonnes
J'aimerais avoir vos commentaires sur une situation à laquelle je fais face avec mes parties prenantes en ce qui concerne la conception d'un formulaire Web particulier. Je suis nouveau dans mon rôle de concepteur UX et j'espère apprendre des gens expérimentés ici.
Actuellement, nous avons un formulaire long que nous ne pouvons pas diviser en plusieurs pages. C'est une solution que j'ai proposée à la partie prenante, mais malheureusement, elle n'a pas décollé.
Je suis allé avec une conception de champ de formulaire multi-colonnes. Je suis conscient que les formulaires à plusieurs colonnes sont mauvais en termes de lisibilité et, si possible, nous devons nous en tenir à un formulaire à une seule colonne (ce qui n'est pas possible en raison de la longueur du formulaire et que nous ne pouvons pas les diviser en plusieurs pages). J'accepte ces risques - au moins dans la première itération du produit jusqu'à ce que nous obtenions plus de commentaires des utilisateurs à ce sujet, mais pour l'instant, supposons ce qui suit:
- Nous avons une conception de formulaire à plusieurs colonnes.
- Chaque ligne du formulaire aura au plus 3-4 champs de formulaire.
- Le formulaire entier est placé dans un modal (encore une fois, c'est quelque chose dont nous ne pouvons pas nous éloigner en raison de contraintes techniques)
Actuellement, notre formulaire ressemble à quelque chose comme ci-dessous (informations masquées):
L'un des principaux problèmes de nos parties prenantes était le suivant:
- Pour les listes déroulantes et les calendriers, où il y a normalement un indicateur visuel (c'est-à-dire une flèche pointant vers le bas, une icône de calendrier) accompagnant le champ: si nous l'étirons complètement à 100% de la largeur modale, les utilisateurs peuvent ne pas savoir que le champ est un liste déroulante ou un calendrier.
- Il a été suggéré d'éviter les champs qui s'étendent à 90% de largeur modale et de le garder court (par exemple, voir le champ nationalité dans la capture d'écran, la suggestion est de le garder à la même longueur que le sexe, le prénom, etc.)
Mes réflexions à ce sujet sont:
- Il s'agit d'une application de bureau et les gens la consultent sur un écran de taille normale. Ils pourront voir dans leur vision périphérique que les champs (qui sont actuellement étirés à 90% de largeur modale) sont en fait une liste déroulante ou un calendrier.
- Je suppose que les gens cliquent normalement sur la "valeur actuellement active/par défaut" dans la liste déroulante ou la date dans le champ de date, et ils n'amènent pas leur curseur jusqu'aux bords du champ où la "flèche vers le bas" (dans la liste déroulante) ou "icône de calendrier" (dans le champ de date) sont à cliquer; par conséquent, il est acceptable d'étirer les champs à 90% de largeur modale.
Malheureusement, en raison de la nature du projet, nous ne sommes pas en mesure d'exécuter des tests d'utilisabilité avant le lancement du produit ... Ce sont des contraintes très réelles auxquelles nous sommes confrontés en tant que concepteurs UX dans l'organisation dans laquelle nous nous trouvons, et nous aimerions exploiter dans les expériences d'autres designers pour des conseils.
Quelques suggestions:
- Effectuez un regroupement logique des champs de formulaire et affichez-les dans des groupes réductibles. De cette façon, le formulaire ne semblera pas encombré à première vue car seul le premier groupe s'affichera comme développé. L'utilisateur peut développer d'autres groupes et définir les propriétés requises.
Étirer le champ à 100% de largeur n'est pas une bonne expérience. Chaque type de contrôle (zone d'édition déroulante, stepper, etc.) doit avoir une largeur définie, sauf s'il est nécessaire de le modifier. Nous pouvons laisser un espace vide s'il n'y a pas de champ à afficher adjacent au champ Nationalité dans l'image jointe.
Alignez les contrôles afin de trouver plus facilement le champ requis.
Quelques liens à visiter pour apprendre les directives du formulaire, au cas où vous ne les auriez pas déjà consultés:
https://msdn.Microsoft.com/en-us/library/windows/apps/jj839734.aspxhttps://uxplanet.org/designing-more-efficient-forms-- structure-inputs-labels-and-actions-e3a47007114fhttps://www.nngroup.com/articles/web-form-design/