Écran de connexion utilisateur WebApp
J'envisage actuellement des options pour un écran de connexion d'application web/intranet et cela semble être un bon endroit pour partager.
Il n'y a pas eu beaucoup de travail dans l'écran actuel depuis la création et il existe sous la forme liste déroulante/boîte de noms d'utilisateur (nom complet), champ de mot de passe et bouton de connexion. Les utilisateurs semblent à l'aise avec cela (ayant existé de cette façon pendant plusieurs années (ils peuvent être défavorables au changement)) mais avec le nombre d'entrées/d'utilisateurs approchant les 200, il faut peut-être reconsidérer.
J'ai observé que certains utilisateurs "luttaient" pour trouver leur nom d'utilisateur entre autres, bien que certains utilisateurs soient assez à l'aise avec la sélection du menu déroulant et la saisie. Le système est souvent utilisé dans un environnement de kiosque de fabrication et peut-être que la saisie devrait être minimale/minimisée.
Cet écran peut rester tel quel et j'ai beaucoup d'autres choses à développer (plus de fonctionnalités souhaitées à une priorité plus élevée) mais je me demande s'il existe de bonnes alternatives ou suggestions. Zone de texte de saisie semi-automatique?
Cette situation me laisse avec les questions suivantes:
- Existe-t-il des "modèles mentaux" pour les écrans de connexion?
- Existe-t-il d'autres options pour le nom d'utilisateur que la liste déroulante ou le champ de texte?
- Comment gérer la résistance au changement d'interface?
- Quelqu'un peut-il me diriger vers une bonne littérature sur les écrans de connexion/modèles mentaux?
Eh bien, comme pour un autre utilisateur, vous pourriez peut-être essayer de combiner le champ de texte avec le menu déroulant et la suggestion automatique.
Vous avez donc une zone de texte avec autosuggest et une flèche de drowdown à côté. Si vous cliquez sur la flèche, vous voyez tous les noms d'utilisateurs, si vous commencez à taper la liste sera réduite aux noms d'utilisateurs possibles.
si vous ne voulez pas ajouter de fonction pour garder l'utilisateur connecté, vous pouvez au moins vous souvenir du nom d'utilisateur.
Mais d'après mon expérience avec cette quantité de données, un champ de recherche/saisie est vraiment nécessaire.
Je pense que la meilleure façon de faire face à la résistance aux changements est de les amener légèrement. Les utilisateurs devraient avoir une liste déroulante comme ils le faisaient auparavant, mais j'espère qu'ils essaieront d'utiliser les nouvelles fonctionnalités et d'en profiter. Il peut également être utile d'afficher un avis "nouveau" au premier démarrage. Google fait cela, et il vous montre les nouvelles fonctionnalités, de cette façon, l'utilisateur obtient une explication et peut profiter des nouvelles fonctionnalités plutôt que de se laisser dérouter par elles.
En général, les modèles mentaux sont utilisés pour aider à décomposer des ensembles de tâches afin que les exigences relatives au processus puissent être rassemblées. Je n'en connais aucun qui fasse des recommandations spécifiques à l'interface utilisateur.
Il serait préférable d'utiliser un e-mail ou un identifiant d'employé pour les informations de connexion, ils sont uniques par rapport à un nom qui peut être partagé entre de nombreuses personnes. Celui-ci devrait être assez simple pour expliquer pourquoi ce changement est nécessaire.
Je ne recommande pas la saisie semi-automatique pour les écrans de connexion. Bien que cela ne donne pas vraiment accès à un compte à une autre personne, la perception que l'utilisateur accède à des informations privées laissées par d'autres utilisateurs pourrait avoir un effet négatif.
Si votre écran de connexion a de la place, que diriez-vous de les nettoyer? Fournissez une entrée de texte vide à côté de votre menu déroulant et fournissez un libellé comme: Type your username or select it from the menu, then click 'Login'. Après un an, retirez le menu déroulant ...
La suggestion de Lukas Oppermann d'utiliser un champ de texte de saisie semi-automatique est la réponse ... Je commenterais sous sa réponse, mais je n'ai pas assez de représentants faire cela. Pourrait ajouter que vous pouvez ajouter un test A/B pour voir avec l'option d'utiliser l'autre interface. J'ai du mal à croire que les gens voudraient une liste déroulante avec plus de 200 articles ... :-)
Je pense qu'il y a beaucoup de réponses sur ce qu'il faut mettre son temps pour la conception Je vais juste répondre sur la conception, vous devez utiliser la saisie semi-automatique ou le champ de texte quel que soit son, le lien suivant concerne uniquement la conception. il n'y a qu'une seule zone de texte, vous devez placer une autre zone de texte pour le mot de passe.
voir le design ici Voir le design
écran de démonstration de l'aperçu Jqtouch (voir uniquement en safari)
mais ce n'est pas l'écran de connexion, il suffit de voir l'écran mobile, vous pouvez ensuite l'ajuster à vos besoins.
Se connectent-ils toujours en tant qu'utilisateur/eux-mêmes spécifiques? S'il s'agit d'un site intranet, une sorte d'authentification unique est toujours préférée - c'est-à-dire que l'utilisateur ne se connecte pas du tout, mais le navigateur "abandonne" automatiquement les informations d'identification du système d'exploitation à la place - pour une connexion transparente expérience.
Dans un environnement de kiosque, je suppose que l'application elle-même est la seule limite de sécurité, pas le système d'exploitation? Y a-t-il une bonne raison d'afficher tous les noms d'utilisateur dans une liste ou par saisie semi-automatique? C'est-à-dire pourquoi la zone de texte vide la plus courante a été initialement rejetée? Je suppose qu'il y a une bonne raison ^^
Pour les connexions à faible sécurité, il suffit parfois d'utiliser un code PIN ou un mot de passe unique, sans aucun nom d'utilisateur. Les imprimantes à tirage utilisent généralement ce système. En tant que mordu de sécurité, je me moque de cela, mais cela semble bien fonctionner en raison du faible impact d'une violation. Des informations supplémentaires sur ce que fait le système et les implications sur la sécurité supérieure/inférieure et les utilisateurs finaux identifiables pourraient être utiles.