Dans notre application téléphonique, lorsque nous avons des flux en plusieurs étapes, nous avons généralement une question par écran (sauf lorsqu'ils sont évidemment liés, c'est-à-dire la ville et l'État).
Récemment, les gens avec qui j'ai travaillé ont proposé qu'il soit préférable d'avoir plusieurs questions sur le même écran, car cela nécessitera moins d'étapes/écrans pour terminer la tâche. J'ai toujours été d'avis que dans une application, le modèle de question unique "me semblait" plus rapide, car je sens que je fais toujours des progrès.
Quelqu'un a-t-il fait des études sur le sujet? Règles de base?
Je n'ai pas d'études mais les pensées suivantes:
La division des questions sur plusieurs écrans n'est pas effectuée pour augmenter la vitesse ressentie pour remplir les informations. Il est fait pour ne pas submerger l'utilisateur avec trop d'informations.
Chaque fenêtre d'affichage ne doit héberger qu'une seule question/étape. Cela indique clairement à l'utilisateur qu'elle n'a pas à faire défiler vers le bas pour répondre à toutes les questions. Si vous n'avez qu'une seule question par écran, il n'y a qu'une seule direction à parcourir. Mais une question peut avoir plusieurs réponses. Vous avez fait l'exemple de la ville et de l'État. L'utilisateur doit donc remplir deux champs de saisie pour une question.
La règle générale serait donc: Combinez les champs de saisie en une seule question s'ils ont un sens. par exemple. demandez plutôt l'adresse plutôt que le nom, la rue, le code postal, la ville, etc. Cela contient beaucoup de champs de saisie mais pour l'utilisateur, il est clair qu'une adresse contient plusieurs champs de saisie. Si vous le faites, il y a moins d'étapes et cela peut sembler plus rapide que d'avoir beaucoup de questions.
Pour donner à l'utilisateur un sentiment d'orientation, vous devez définitivement donner un retour sur les progrès. Cela pourrait être par exemple étapes, barre de progression ou autre.
Imaginez que toutes vos questions soient posées sous une seule forme. Ont-ils des relations complexes comme des logiques d'activation/désactivation mutuelles ou différentes manières de procéder en fonction d'une réponse particulière? Si c'est le cas, votre approche actuelle permet de masquer la complexité du formulaire. De plus, si vous avez un appareil de taille d'écran limitée, votre approche évite les difficultés d'affichage des erreurs de défilement et de validation. Ou peut-être que chacune de vos pages de questions contient des conseils utiles, des promotions ou simplement de belles images qui rendent son utilisation plus facile et plus agréable. Je veux juste dire que cela dépend de votre application/produit/service et de son public.
Je n'ai pas trouvé de recherche spécifique sur la vitesse perçue pour une seule question, mais ce serait très contextuel et difficile à généraliser. La façon la plus simple de décider de cela pour votre domaine serait de créer un prototype avec les deux conceptions et de le tester sur les utilisateurs.
En attendant, je recommanderais de consulter article perspicace de Luke Wroblewski sur l'intégration des applications de partage de vélos . Il recadre la question de la vitesse perçue à l'obtention de la valeur fondamentale de l'utilisateur dès que possible.
Théorie:
Sur mobile, les choses peuvent fonctionner si vous maintenez parfum d'information , indiquez des progrès significatifs pour déclencher les utilisateurs besoin de terminer et restez assez court pour maintenir la motivation des utilisateurs.
Il y a trois concepts importants que j'utiliserais pour considérer si une seule question est la meilleure:
S'il y a plusieurs questions sur une seule page, cela peut sembler excessif et être perçu comme plus complexe qu'une question à la fois. Cependant, si le montant semble raisonnable et qu'ils sont connectés, il peut y avoir un coût d'interaction plus élevé en répondant à une question à la fois.
Jakob Nielsen souligne que la seule étape (une page) vs plusieurs étapes (divulgation par étapes) dépend également du contexte d'utilisation:
La divulgation par étapes est utile lorsque vous pouvez diviser une tâche en différentes étapes qui ont peu d'interaction. C'est problématique lorsque les étapes sont interdépendantes et que les utilisateurs doivent alterner entre elles.
dépend fortement de qui est votre utilisateur. Nous travaillons selon les directives GDS et c'est fortement une chose par page car nous voulons que les utilisateurs évitent les erreurs. Une chose par page se concentre sur une seule chose pour l'utilisateur, un bit de contenu à lire, une décision à prendre.
Si vous concevez pour des utilisateurs experts qui veulent faire la même chose encore et encore, rapidement, cette approche ne fonctionnera pas.