web-dev-qa-db-fra.com

Case ou boutons "J'accepte"

Je conçois une application qui permet aux utilisateurs de s'inscrire s'ils acceptent les termes et conditions. Si l'utilisateur accepte les termes et conditions, le processus d'inscription réussira et l'utilisateur passe à l'écran suivant en tant qu'utilisateur enregistré, mais si l'utilisateur n'est pas d'accord, il continuera à utiliser l'application en tant qu'utilisateur invité. J'ai deux conceptions en tête:

  1. Une case à cocher et un bouton avec les étiquettes "J'accepte" et "Terminer" respectivement Checkbox
  2. Deux boutons avec les libellés "J'accepte" et "Je n'accepte pas" enter image description here

Lequel des modèles ci-dessus offrirait une meilleure expérience utilisateur? Ou existe-t-il d'autres meilleurs designs?.

usabilityusability-studyusability-engineering
14
PS86

Je suggère le bouton "J'accepte".

Nous savons tous que le bouton "I Agree" est juste un gros truc juridique que ni les développeurs ni l'utilisateur final ne se soucient vraiment.

En ayant la case à cocher, nous perdons le bouton "Je ne suis pas d'accord". Cela rend plus difficile et frustrant pour l'utilisateur final de quitter, ce qu'il devrait pouvoir faire facilement et à tout moment. Pour moi, c'est aussi un peu sommaire quand je dois confirmer deux fois (case à cocher et bouton).

Donc, avoir la case à cocher n'est qu'une étape supplémentaire et inutile, et l'absence du bouton "Je ne suis pas d'accord" entraîne des difficultés à quitter.

11
Evorlor

Ce n'est pas responsable sans objectifs UX

Commencez par commander vos objectifs UX avec le formulaire. Classez les éléments suivants:

  1. Minimiser le frottement UX/maximiser la commodité - Favorise les boutons puisque (a) l'interaction est en un clic; et (b) les boutons sont plus faciles à utiliser que les cases à cocher;
  2. Assurez-vous que les termes et conditions sont lus - Favorise la case à cocher car ils créent plus de friction/pause cognitive et forcent l'utilisateur à ne pas survoler l'interaction.

Si # 1 est plus important que # 2, alors allez avec des boutons. Si # 2 est plus important, optez pour les cases à cocher.

Si # 2 est extrêmement important, alors il existe d'autres approches nécessitant une affirmation positive de l'utilisateur (comme demander aux utilisateurs de taper I agree ou leur nom) mais cela a évidemment un coût croissant de # 1.

4
tohster

Cela dépend, sont leurs étapes précédentes et suivantes? Si oui et que vous avez plusieurs boutons suivants, la cohérence est préférable.

Si vous démarrez l'application, obtenez cet écran et ensuite l'application apparaît: le 2ème un - moins de clics, moins de réflexion.

0
Gustav

Voulez-vous que l'utilisateur lise vos termes et conditions?

Plus il doit faire d'étapes sur cette page, plus il peut lire et ne pas vous déranger avec des choses qui y sont écrites.

C'est pourquoi beaucoup de Termes et Accords vous obligent à faire défiler tout en bas avant de cliquer sur le bouton I Agree. Il vous protège parce que vous avez fait quelque chose pour vous assurer que l'utilisateur a passé tout le texte.

C'est pourquoi vous devriez choisir le premier à mon humble avis. Ou implémenter un autre mécanisme similaire comme décrit précédemment.

C'est ennuyeux pour l'utilisateur, mais nécessaire pour vous et une bonne pratique consiste à l'afficher SEULEMENT lorsqu'il est nouveau ou modifié.

0
Yohann V.

Dans de nombreux cas, la fonctionnalité "d'accord" se trouve à la fin d'un (long) formulaire. À mon humble avis, la vraie question serait, si avoir deux boutons de soumission est bon ou mauvais. Est-il judicieux pour l'utilisateur de soumettre un formulaire auquel il ne se conforme pas?

Techniquement, deux boutons sur un formulaire cela fonctionnerait - mais quelle serait la prochaine étape/la prochaine page que l'utilisateur verrait? Souhaitez-vous offrir la possibilité de revenir au formulaire pré-rempli au cas où quelqu'un soumettrait le formulaire via le bouton "mauvais"?

En ayant une case à cocher à la place, les utilisateurs peuvent toujours rester sur la page du formulaire, ce qui peut également être utile, en particulier lorsqu'il s'agit de formulaires plutôt complexes.

0
tillinberlin

Je ne sais pas s'il existe des raisons juridiques qui obligeraient l'utilisateur à reconnaître avoir lu les conditions générales, mais avec plusieurs clients, j'ai utilisé quelque chose comme "En soumettant vos informations de profil, vous acceptez nos Termes et conditions." Les termes et conditions seraient un lien qui s'ouvrirait dans une superposition si, Dieu nous en préserve, quelqu'un voulait les vérifier!

0
Tarek

L'idée que vous proposez semble excellente. Ça a l'air super!

Mais la question à se poser ici est que l'intention de fournir des T&C est d'obtenir une déclaration de l'utilisateur qu'il l'a lu, compris et donc qu'il signe le document (en cochant la case) et est prêt à prendre la prochaine étape.

En remplaçant la case à cocher par le bouton, vous supprimez le "sérieux" du fait que "l'utilisateur a lu les CGV et accepte de le respecter"

C'est le motif qu'il est conservé en bas pour que les utilisateurs défilent vers le bas, en supposant qu'ils lisent, puis le signent en vérifiant et en cliquant sur l'action suivante.

En fait, vous pouvez améliorer l'expérience utilisateur en vérifiant que, en combien de temps, l'utilisateur a cliqué sur le bouton par rapport au temps moyen nécessaire pour lire autant de contenu.

0
pzv

Ma suggestion personnelle serait:

  • Cochez la case avec une description et désactivez le bouton "Continuer"
  • Une fois que l'utilisateur a coché la case, activez le bouton Continuer

Assurez-vous également que vous n'enfreignez pas la loi. Vérifiez les exigences légales de votre pays concernant l'accord d'utilisation.

Par exemple, certains pays (comme l'Allemagne) exigent une approche qui offre aux utilisateurs la fonctionnalité d'activation (case à cocher décochée).

0
telvin