Noms d'utilisateur, noms d'affichage, noms complets - comment intégrer
Dans l'application que je conçois, il n'y a actuellement que des noms d'affichage. Comme ils ne sont pas uniques, il peut être difficile de les distinguer. Dans cet esprit, les noms complets vont être mis en œuvre aux côtés des noms d'affichage. ET à des fins d'identité uniques, car certains e-mails peuvent avoir plusieurs comptes - des noms d'utilisateurs devront également être créés. Cela semble beaucoup demander lors de l'intégration.
Des suggestions/critiques?
Lors de la conception d'un système, commencez toujours par le strict minimum. Ne compliquez pas trop les processus qui peuvent être effectués efficacement avec des moyens simples.
Un e-mail unique et un mot de passe sont généralement le minimum dans la plupart des circonstances. Sans connaître aucun détail supplémentaire sur votre système, il est difficile de recommander autre chose que cela.
En supposant que votre "nom d'affichage" est vraiment un nom d'utilisateur, les noms d'utilisateur sont destinés à identifier de manière unique les utilisateurs, si vos noms d'utilisateur ne sont pas uniques, alors ils ne peuvent pas être fiables. Si les utilisateurs peuvent voir les noms d'utilisateur non uniques les uns des autres, où plusieurs utilisateurs ont exactement le même nom d'affichage, alors cela sera une source de confusion et conduira à une méfiance dans le système.
Les noms d'utilisateur sont généralement mis en œuvre lorsqu'une adresse e-mail n'est pas requise, il n'y a pas d'autre moyen d'identifier de manière unique un utilisateur ou lorsque vous ne souhaitez pas exposer les adresses e-mail de l'utilisateur à d'autres utilisateurs. Si aucune de ces situations ne s'applique, vous devez sérieusement remettre en question la valeur d'avoir un nom d'utilisateur/nom d'affichage.
Le prénom et le nom peuvent être utiles pour personnaliser davantage l'expérience de l'utilisateur, par exemple en affichant des messages comme "Bienvenue Jake sur votre tableau de bord", mais ne doivent pas être en tant qu'identifiant unique à eux seuls. Ouvrez simplement l'annuaire téléphonique et vous verrez ce que je veux dire.
Bien que permettre aux utilisateurs la possibilité d'avoir plusieurs comptes d'utilisateurs pointant vers la même adresse e-mail semble pratique, cela complique vraiment un peu plus tout ce qui concerne les utilisateurs: authentification, réinitialisation de leur mot de passe, mappage de toutes leurs données, ... y compris l'expérience utilisateur en tant que ils devraient gérer plusieurs identités.
Lors de l'embarquement, gardez-le aussi simple, rapide et facile pour l'utilisateur, afin d'augmenter les chances de réussite.
En bref, soufflez un KISS (Keep it simple idiot) pour l'utilisateur, et ils peuvent vous embrasser en retour.
Trois, c'est trop
Une configuration de compte attendue comprendra un nom d'utilisateur unique et le option pour inclure un nom complet. Le nom "d'affichage" peut être l'un de ces deux, mais pas un troisième.
Slack fait du bon travail avec ça aujourd'hui. Les utilisateurs peuvent définir une préférence personnelle par "équipe" pour afficher le nom d'utilisateur ou le vrai nom.
Le contexte de votre application peut aider à déterminer ce dont vous avez besoin, mais utilisez-en le moins possible. Le code back-end souffrira grandement à mesure que vous ajoutez plus de ces options d'identification et vos utilisateurs peuvent être confus entre les différences et se fatiguer rapidement lors de votre inscription.
Le but pratique d'un nom d'utilisateur est d'identifier de manière unique un utilisateur lorsque:
- l'utilisateur souhaite modifier ultérieurement son adresse e-mail
- l'utilisateur a besoin d'un certain niveau de confidentialité
Certaines applications peuvent se débrouiller entièrement avec juste une adresse e-mail et un mot de passe. Ce n'est que récemment qu'Amazon.com a ajouté un numéro de téléphone mobile comme identifiant de connexion possible. Dans le même ordre d'idées, vous pouvez même différer la demande du nom d'utilisateur lorsqu'il est réellement nécessaire (par exemple, pour la publication dans un avis sur un produit ou un forum).
Une autre option consiste à intégrer un système tiers comme Facebook ou OpenID, bien que cela puisse ou non convenir à votre produit.
La définition de toutes ces options et leur mise en œuvre nuisent à la création de votre application principale, car ces options d'identification sont sans aucun doute accessoires à votre produit principal (sauf dans les rares cas où votre produit est en fait un système de connexion).
Donc, pour l'amour du ciel, ne le faites pas trop.