Existe-t-il une raison pratique (pilotée par l'expérience utilisateur) pour laquelle les pages de connexion n'ont souvent pas d'en-têtes / pieds de page lorsque le reste du site en contient?
Je conçois un site Web avec un écran de connexion, j'ai donc cherché des exemples sur d'autres sites pour avoir une idée générale des tendances UX/UI dans la région (je suis principalement un développeur, pas un designer). J'ai remarqué que les sites qui ont des en-têtes/pieds de page semblent les perdre lorsque vous accédez à l'écran de connexion, et la seule chose que vous voyez est un simple formulaire de connexion, centré (dans 1 ou les deux axes), avec un simple logo d'entreprise .
Je me demande si c'est simplement un choix stylistique pour rester simple, ou si je manque une raison plus nuancée d'abandonner les en-têtes.
Est-il mauvais d'avoir des en-têtes/pieds de page sur la page de connexion?
Quelques exemples
www.Microsoft.ca -> a un en-tête en haut, mais l'écran de connexion est complètement différent et sans en-tête/pied de page
www.google.ca -> les liens supérieurs manquent lorsque vous cliquez sur Connexion
www.Amazon.ca -> encore une fois, la navigation supérieure manque complètement (je sorte de celui-ci, car leur en-tête est principalement basé sur la recherche, mais cela s'applique également à woot.com , qui a juste des catégories dans leur en-tête).
wwww.github.com -> un autre qui présente une page de connexion propre, bien que si vous essayez de créer un nouveau compte, les en-têtes reviennent
Un exemple de compteur stackoverflow.com , x.stackexchange.com -> contrairement à stackexchange.com , stackoverflow et ux.stackexchange.com conservent leurs en-têtes que vous vous connectiez ou vous inscriviez.
Il s'agit d'une tâche ciblée et de la clé pour accéder au contenu.
Certains choisissent d'afficher du contenu pour attirer l'utilisateur, mais réduire la charge cognitive est important pour une tâche ciblée.
Certains choisissent de masquer tout le contenu car il ne doit pas être affiché sans privilèges.
Si vous optez pour la première approche, la décision de réduire la charge cognitive dépendra de la réaction de vos utilisateurs.
- Est-ce qu'ils tombent parce qu'il y a trop de bruit?
- Viennent-ils plus souvent sur le site parce que le contenu les taquine?
Afin de minimiser le nombre de stimuli - au moment où moins d'informations nous parviennent, nous pouvons nous concentrer sur l'objectif.
Exactement la même chose avec, par exemple, des processus d'achat pour réduire le taux de saut de page pendant le processus.
C'est en corrélation avec la réduction de la charge mémoire:
- L'application a une structure claire
- "Reconnaissance sur rappel"
- Aide implicite
- Aides visuelles