What is the best experience for generating unique usernames?

Question

We are building a social network and as part of user onboarding, we want to assign each user a unique username

The only currently defined use case for the username is the profile URL, i.e. if your username is gajus, then your profile is accessible through foo.xyz/@gajus. Because of this requirement, we chose to force usernames that are URL safe.

We are currently considering 4 ways of assigning usernames:

Username as entered by username

This delegates responsibility of finding unique & available username to the end user.

As username concept is not a center-piece of our social network, we do not want to make it part of sign up flow. We want the initial username to be generated for user.

Not an option.

Do not assign usernames

Refer to user profiles by their numeric ID until user picks a username (foo.xyz/@123).

We believe this makes the profile URLs feel lacking personality and it removes the guarantee that every user has a unique username (which is useful for simplifying the system design).

Generating a unique username using name + random ID

The next alternative we are considering is simply deriving user's username from their first name and last name (user already makes this information public) and adding a random ID to the end, i.e.

• If user's first name is Gajus and
• their last name is Kuizinas,
• their username is gajus_kuizinas_dk1f,

where "dk1f" is a random ID.

(Logic for ensuring that the generated username is unique is outside of the scope of the question.)

This is the most simple to implement and easy to predict option.

Generating a unique username from components of supplied data + random ID as a fallback

Once again, user supplies their name as part of onboarding and consent to it being public. We therefore can attempt to assign user a "friendly" username, i.e. the kind of username that people would want to have in a professional network, e.g.

• gajus_kuizinas
• gkuizinas
• gajusk
• and other combinations we think of

falling back to gajus_dk1f (where "dk1f" is random ID).

The only downside of the latter implementation is that it adds unpredictability, i.e. if two users sign up and look at each others URLs, they might follow a different pattern, causing confusion about how the usernames were chosen.

Which of these provides the best user experience?

Answer 1

It is very impressive to have all the options before hand.

In my opinion, your third option (Generating a unique username using name + random ID) is the best to go with having following advantages:

1. At some extent, enables user to have personalized user name. It is better than numbers only.
2. As you already said - Less complex logic to generate. Cost effective.
3. You may allow user alter that later to customized one as we see in linkedin profiles.
4. Supplied data User names sometimes seems funny as we see in gaming apps (PubG n all). For social networking websites, it will be very selective process to choose Supplied Data. And I don't think team should invest more for non username centric app.

I will suggest to keep first name + random id to make user name length not too lengthy.

Thanks.

Answer 2

I think there is another option, which I used to see more often but doesn't seem to be as popular now (for technical or practical reasons), and that is to assign users a unique ID that is used for backend purposes, but allow the user too chosen their own name (i.e. nickname) that is used when communicating with other people.

That way, it allows for people to have similar or same names, but retain unique IDs so that it doesn't force people to choose unique names but can still own their own identities.

Answer 3

Don't make this complicated.

First, tell the user what the rules are for user names - like what characters are allowed and what are not.

Second, if they enter one, check and tell them if it's already taken.

Assuming it's unique and follows naming convention, then the user has their unique username with out much complication.

Again, don't make this overly complex. The idea of a unique user name (with a few restrictions on characters) is not a burden for the user.

Answer 4

To reiterate:

• Users do not log in with this username, instead using an email address or another form of identification that they will easily remember
• This username is used only for vanity URLs which will be shared by users within the network

It seems unlikely that users will try to enter these urls themselves, instead relying on search or the link itself to direct them to other user's profile pages. In a world of excessive tab usage, mobile devices, and short urls, the likelihood that anyone will even notice the url seems negligible.

Assuming the above is true, I'd generate a unique ID, and leave it at that. Your database should already have a unique key for each user, so there should be no possibility of duplicates. If names are used, there's always the possibility that the user's name may change, putting unnecessary burden on the user to update the url.

If the stakeholders are dead set on having vanity IDs, you could also append the user-selected name after the unique key - ie site.co/123456/jane_swenson. This would negate any need for unique urls, and allow the url to automatically reflect the user's name as it appears in their profile.

Answer 5

First, I think it would be more sensible to define the profile page URL using a numeric ID rather than the username. The numeric ID is unique to each account, but not necessarily the username.

A username is a simple and personal copy, but it is rarely used in a URL (unless your intent or your product's personality is such that the Profile Page will be often shared with others). - In fact, your users will most likely never remember their IDs and that will not affect their experiences.

On the other hand, does the username have to be relevant to the real name? Unless there is something special about your product (for example, a real-name is required on an immigration website), reconsider the "real Name + Random ID" solution.

My personal opinion is to allow the same username to appear in your product. I don't think this is fatal to social (I mean the need for social). If you're worried that a female user might confuse a man with another “Finn” after a night of talking to him, that means your product is still there is room to improve in other ways - please keep in mind that the behavior of the mutual attraction in the social network is based on each person's intrinsic characteristics, rather than a "username".

Answer 6

To begin with

How personal is a name you didn't choose in the first place? Even when it is made up from your real name, it was not your choice that it consists of your real name. What if someone don't want it to be too personal? And what is too personal? Someone might want to choose not to mention the surname in the username, others may want a complete different name as part of their online personality opposed to their real life personality. It all depends on the kind of social network that you're building, but did you think of this as well?

The requirements

• personal/relatable
• unique
• url-safe

To generate unique "personal" usernames, the question remains: what is too personal? I believe it's fine to use the first name with something else. It can indeed be the surname, but do users consent? Personally I think that is not a great idea but the first letter of it should be fine. And what more do you know about the user at that stage? Is using the year of birth an option? Can you create something like "john_1983_1" or "john_w_1983_1" with the last "1" as a way to keep usernames consistent and unique. Or maybe it can be just the year they do sign up: "john_w_2020_1". It is easy to remember and unique, even a bit personal. But it isn't necessarily url safe. When the first name contains special characters like "björn_2020_1", it becomes "bj%C3%B6rn_2020_1" when made url safe. You can choose to just use "bjorn_2020_1" but that would mean altering someones name.

Conclusion

You can't meet all of the requirements. A unique ID is the most reliable option you have, or let users create their own url-safe username when the personal aspect of it is more important.