User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
In the app I'm designing there are currently only display names. Since these are not unique, it can be hard to distinguish. With this in mind, full names are going to be implemented alongside display names. AND for unique identity purposes as some e-mails might have multiple accounts - usernames are also going to need to be created. This seems like a lot to ask for during the onboarding.
Any suggestions/criticism?
When designing a system, always start with the bare minimum. Do not overcomplicate any process that can be done effectively with simple means.
A unique email and a password is generally the minimum in most circumstances. Without knowing any additional details about your system it is hard to recommend anything more than this.
Assuming your "display name" is really a user name, user names are meant to uniquely identify users, if your user names are not unique, then they cannot be trusted. If users can see each other's non-unique user names, where multiple users have exactly the same display name, then this will be a source of confusion and lead to a mistrust in the system.
Usernames are generally implemented when either an email address is not required, there is not another means of uniquely identifying a user, or when you do not want to expose user's email addresses to other users. If none of these situations apply, then you should seriously question the value of having a username / display name.
First and Last name can be useful to further personalize the experience for the user, such as showing messages like "Welcome Jake to your dashboard," but should not be as a unique identifier on their own. Just crack open the phone book and you'll see what I mean.
Although allowing users the option to have multiple user accounts pointing to the same email address seems convenient, it really just over complicates everything related to users: authentication, resetting their password, mapping of all of their data, ... including the user experience as they would have to manage multiple identities.
During on boarding keep it as simple, fast and easy for the user to do, to increase the chances that they will get through it successfully.
In short, blow a KISS (Keep it simple silly) for the user, and they may kiss you back.
An expected account set up will include a unique user name and the option to include a full name. The "display" name could be either of these two, but not a third.
Slack does a good job with this today. Users can set a personal preference per "team" to display user name or real name.
The context of your application may help determine what you need, but use as few of these as possible. The back-end code will suffer greatly as you add more of these identification options and your users may be left confused between the differences and quickly fatigue during your registration.
The practical purpose of a username is to uniquely identify a user when:
Some applications can fully get by with just an email address and password. Not until recently did amazon.com add a mobile number as a possible sign-in credential. In the same vein, you can even defer the request for the username when it's actually needed (say, for posting in product review or forum).
Another option is to integrate with a third-party system like Facebook or OpenID, though that may or may not suit your product.
Figuring out all these options and implementing them detracts from building your core application, as these identification options are undoubtedly ancillary to your core product (unless it's the rare case your product is actually a login system).
So for heaven's sake, don't over engineer it.
