[Ergo] un seul bouton pour inscription et connexion ?

Bonjour à tous,

Dans ma boite nous sommes actuellement confronté à un dilemme ergonomique.

Une refonte de notre header est en projet. Une des modifications demandées est de fusionner nos deux boutons "s'inscrire" et "se connecter" en un seul et unique bouton.

Il est vrai que cette pratique est de plus en plus à la mode depuis quelques temps.
Poussé par la multifonctionnalité des boutons de connexion/inscription des réseaux sociaux, beaucoup de sites ont fusionnés ces fonctionnalités.

Mais cela pose un questionnement d'ordre cognitif : est-ce cohérent de cliquer sur un bouton nommé "connexion" alors que l'on souhaite réaliser l'action de "s'inscrire" ? N'est-ce pas amoindrir l’expérience utilisateur au profit d'un simple gain de place ?

Certes il existe toujours la possibilité d'un label double du type "connexion/inscription", mais notre questionnement est surtout de nous demander l'impact d'un label simplifié du type "connexion".

En interne, les avis sont partagés.
Je me tourne donc vers vous pour élargir la réflexion.

Merci.

Sur un seul bouton, je pense en effet que c'est une mauvaise idée.

Un autre pratique, pour ne garder qu'un bouton, est d'avoir une page ou un formulaire scindé en deux :
« Vous êtes déjà inscrit ? Connectez-vous. »
« Vous n'avez pas de compte ? Inscrivez-vous ! »

Ce type d'écran est assez répandu en e-commerce par exemple, afin de permettre à un invité de remplir un panier d'achats et ne lui demander de se connecter qu'au début du processus de paiement.

Est-ce une piste qui peut vous aider ?

Bonjour @erwan21a

je travaille dans le web mais j'utilise également internet en tant que lambda. Lorsque j'arrive sur un site ou je dois me connecter pour accéder à ce que je veux , je cherche le bouton "s'inscrire" parce que je n'ai pas de compte et s'il n'y en a pas, je quitte le site car la plupart du temps, il faut chercher l'info dans les pages du site et je n'ai pas de temps pour cela...
ça c'est le côté "utilisateur".
Maintenant, du point de vue ergonomique, ben...ça l'est pas du tout !
Pour être "ergonomique" , tout ce qui appelle à une interaction dans une page web doit être conçu et mis en place de façon cognitive: on ne doit pas chercher un seul instant à quoi ça sert. Sinon ce n'est pas ergonomique !
Un bouton est là dans un but bien précis et l'utilisateur doit savoir immédiatement ce pour quoi il est fait. Donc si je veux me connecter, j'ai un bouton de connexion mais ça veut dire que quelque part et le plus souvent juste à côté, j'ai un lien pour m'inscrire / créer mon compte.
Voilà j'espère t'avoir aidé

Bon week-end

Bonjour,

Même avis que mes colocataires.
Dans un espace restreint, il est tout à fait possible de caser un espace de connexion clairement identifié, de placer un lien pour s'enregistrer juste en dessous, sans oublier le petit lien pour retrouver les coordonnées de connexion des plus étourdis.
Après, pour le gain de place, il s'agit de cosmétique; un mini-menu tab, un block coulissant, une fenêtre modale, les choix sont infinis

Tu dis ça parce que tu connais suffisament le fonctionnement du web pour savoir la différence entre se logger et s'inscrire.

Mais je connais pas mal d'utilisateurs lambda qui ne font pas vraiment cette différence, qui trouvent les procédures de login/inscription compliquées, ou pire, qui se barrent quand ils comprennent qu'ils doivent encore créer un compte pour utiliser un site. D'où le succès des connecteurs indirects via facebook, twitter, linkedin & co vu que tout le monde est sur facebook, et à tel point que j'ai déjà vu des sites où c'est plus facile de s'inscrire que de se connecter.

Rapidement, un exemple de site où c'est plus simple de s'inscrire que de se connecter: ogame.fr, un jeu en ligne très connu. ON a le formulaire d'inscription sous le nez dès l'ouverture de la page, mais pour se connecter il faut cliquer sur login, donc ergonomiquement on a besoin d'un clic de plus. Je ne sais pas si j'ai raison dans ma théorie et si c'est vraiment fait exprès pour les gros noobs ou bien s'ils font ça pour des raisons purement marketing, mais fondamentalement je trouve ça plutôt idiot dans la mesure où en principe on ne s'inscrit qu'une fois et ensuite on se connecte une, deux, ou des dizaines de fois par jour.


Un compromis peut-être, ce serait de n'afficher initialement aucun bouton; après saisie du nom d'utilisateur / adresse e-mail, si un compte existe afficher un bouton connexion, et sinon afficher un bouton s'inscrire. Par contre ça donne un petit indice aux pirates, qui peuvent savoir si tel adresse ou tel nom existe ou pas.

Ten a écrit :
Sur un seul bouton, je pense en effet que c'est une mauvaise idée.

Un autre pratique, pour ne garder qu'un bouton, est d'avoir une page ou un formulaire scindé en deux :
« Vous êtes déjà inscrit ? Connectez-vous. »
« Vous n'avez pas de compte ? Inscrivez-vous ! »

Ce type d'écran est assez répandu en e-commerce par exemple, afin de permettre à un invité de remplir un panier d'achats et ne lui demander de se connecter qu'au début du processus de paiement.

Est-ce une piste qui peut vous aider ?

Nous avons déjà un formulaire de ce type sous la main, que nous utilisons sur d'autres endroit du site.

La problématique est sur le(s) bouton(s) dans le header qui ouvre(ent) ce formulaire.
Actuellement nous avons deux boutons :
- connexion
- inscription
Nous répondons donc aux deux possibilités de besoin des utilisateurs sur le sujet.
S'il n'y a qu'un seul bouton, un seul label devra alors répondre à ces deux questionnements.

Personnellement, j'ai un doute sur cette pratique d'un point de vue cognitif.

________________________________________________________


Pour les autres :

Globalement, nous avons l'air du même avis. C'est à dire très septique sur cette nouvelle pratique.
Une petite illustration de la chose avec le site de Spotify :



Un seul bouton est présent.
L'utilisateur ayant déjà un compte devra cliquer sur ce bouton "Se connecter".
L'utilisateur n'ayant pas encore de compte devrai aussi cliquer sur ce bouton "Se connecter".

Apparaitra ensuite une popin multi-usage :

Hello,

C'est une très bonne question, très intéressante et même peut-être à même de forger (soyons dingos dans nos têtes) les interfaces de connexion du futur ! (ok j'exagère, un peu)

Je pense que si ta web-app ou ton site à de l'envergure et du budget, tu peux tout à fait lancer un test A/B pour voir si ça marche ou pas, et je serais ravi de lire ton compte-rendu de l'opération ici. Vraiment. Ça peut-être un gros BINGO ou un fiasco, pas grave, c'était juste un test A/B sur deux semaines.

Si à l'inverse vous devez convertir rapidos et donc miser sur ce qui marche aujourd'hui et non sur ce qui marchera (peut-être) demain en ergonomie, je te conseille de rester prudent et de t'en tenir à la bonne vieille méthode efficace, efficiente, accessible des deux boutons séparés, ils ont fait leurs preuves.

À toi de voir et si tu tente le coup, reviens nous faire un topo par ici

Salut audrasjb

La difficulté d'un test A/B, c'est aussi de bien l'analyser...
Modifié par erwan21a (16 Sep 2014 - 16:41)

On va pas se mentir, meme si on essaye toujours de faire le plus accessible possible, quand on a pas une réponse claire et precise d'implementation ni de temps a passer a faire des tests, on aurait tendance a faire au mieux et a caller un aria-hidden true histoire de se donner bonne conscience.

sarakhan a écrit :
caller un aria-hidden true histoire de se donner bonne conscience.

C'est quoi un aria-hidden true?

Salut,

PapyJP a écrit :
C'est quoi un aria-hidden true?

aria-hidden est un attribut qui permet d'indiquer si le contenu de l'élément qui en est doté doit être masqué aux lecteurs d'écran (avec la valeur "true") ou pas (avec la valeur "false", qui est la valeur par défaut).

sarakhan a écrit :
quand on a pas une réponse claire et precise d'implementation ni de temps a passer a faire des tests, on aurait tendance a faire au mieux et a caller un aria-hidden true histoire de se donner bonne conscience.

Je ne crois pas que ce se soit une bonne idée d'utiliser aria-hidden="true" comme tu le préconises…

Victor BRITO a écrit :
Salut,

aria-hidden est un attribut qui permet d'indiquer si le contenu de l'élément qui en est doté doit être masqué aux lecteurs d'écran (avec la valeur "true") ou pas (avec la valeur "false", qui est la valeur par défaut).

Je ne crois pas que ce se soit une bonne idée d'utiliser aria-hidden="true" comme tu le préconises…

C'est fou ce qu'on invente en quelques années! Pour cacher un élément j'en suis toujours à display:none; ce qui ne à pas très bien quand il faut afficher à nouveau. Reste à regarder dans les tableaux d'implementation quel navigateur supporte quoi.
En ce qui concerne la question de base, si j'ai bien compris il s'agit d'une appli privée utilisée au sein d'une entreprise. Dans ce cas les gens s'inscrivent une fois dans leur vie et se connectent tous les jours. Un seul bouton "Connexion" me semble parfaitement correct, car même la première fois les gens ne veulent pas s'inscrire, ils veulent se connecter et pour cela il leur sera demandé de s'inscrire en cours de processus.
Personnellement je fais inscrire les personnes autorises par le webmaster, mais nous sommes peu nombreux, ce serait différent si nous étions quelques milliers.

"sarakhan" a écrit :
On va pas se mentir, meme si on essaye toujours de faire le plus accessible possible, quand on a pas une réponse claire et precise d'implementation ni de temps a passer a faire des tests, on aurait tendance a faire au mieux et a caller un aria-hidden true histoire de se donner bonne conscience.

J'adore , c'est piquant surtout dans un espace consacré à l'accessibilité. Puisqu'on veut pas se faire chier à juste rendre accessible (je dis bien juste car personne ne demande à rendre plus accessible hein...) alors on va rendre le truc totalement inaccessible aux technos d'assistance via aria-hidden à true... une position de champion ! Je cherche toujours comment cette idée peut permettre de se donner bonne conscience (vraiment je vois pas et je ne comprends pas ). Autant ne rien faire du tout, le truc sera potentiellement tout pourri en terme d'accessibilité mais au moins ça laisse une légère et infime chance à l'utilisateur de pouvoir en faire quelque chose...

Enfin, l'utilisateur n'est pas là pour la charité. Cela fait un utilisateur en moins pouvant utiliser/bénéficier/s'abonner au service. Le grand perdant ne sera pas forcément l'utilisateur...

Romain

JE ne voudrais pas troller sur aria-hidden, mais c'est un attribut très dangereux à n'utiliser que dans des cas très spécifiques.

C'est comme l'ensemble d'ARIA en fait: on peut faire une superbe application avec une accessibilité exceptionnelle, mais on peut aussi très rapidement faire une catastrophe qui est moins accessible que si on na'vait pas du tout utilisé ARIA.

Bonjour tout le monde...

Pour recentrer le sujet sur la question..

pour ma part, je suis pour 2 accès bien distinct.
Mais d'un autre côté, windows (par exemple) n'a jamais vraiment choqué personne en demandant de cliquer sur le bouton "démarrer" pour arrêter l'ordinateur...

Je dirai que si c'est un problème de place c'est que l'ergo est peut être mal pensée au départ et il faudrait revoir la disposition car je pense que 2 mots bien concret bien distincts seront toujours plus clairs pour madame michu