email@example.com is best for users.
firstname.lastname@example.org provides much more variation and is easy to remember.
email@example.com buys you a lot more variation for a trade in memorability.
Any meaningful name variation can be added:
jj in place of
And complexity can be added progressively to avoid unnecessary fuss when possible.
The most important feature of this system:
The email ID is driven by personal info, not system codes.
Uniqueness isn't always easy to remember.
Learning names is a good thing.
Of all the possible solutions, I think real names are the best form of inter-personal organizational identification (which is essentially what an email address does for us). The first thing you learn about a person is their name and you probably shouldn't be contacting them if you don't know it. So we can agree real names are good, right?
On the other hand, a number (like a GUID) is far more programmatically scalable. You will never run out of IDs and it's not connected to any potentially transient facts about the person. But it's a useless thing for people to remember about other people.
What about a short system-generated number appended to a name? That's still something users don't need to know about another user. Maybe their office phone extension or mobile number? No one dials phone numbers these days!
So how do we allow people to use each others' names without running out of options?
Let's look at the conditions to be satisfied.
1. Reasonably unique
If you're a mega corporation, this is a challenge. Names alone may not provide enough unique variations.
I've seen companies try to get away with
f.m.last, but that doesn't really save humans any memory load and you're much more likely to run out of unique options.
For the average organization,
first.m.last is pretty solid. There are a lot of variations possible (even likely) in those three pieces of data. It is, however, possible to run out of such IDs. Let's come back to that after we've considered our other requirements.
2. Reliably constant
Names, while not set in stone, are relatively constant. And when they do change, the members of an organization should probably know that and learn it.
System generated numbers are extremely constant, but we already addressed why that's not worth the trouble to learn.
Location (as Benny mentioned) is worth considering, but an org might move or expand or consolidate offices and they may favor or at least dabble with a remote workforce. With those factors in mind, location can be difficult to rely on.
A name seems constant enough for these purposes.
3. Human learnable
A name isn't the easiest thing for everyone to learn, but it's a piece of data you should learn if you're going to communicate with another person. And within the set of names that are likely to occur, there are a lot of familiar patterns that make them more learnable than many other unique pieces of data.
A uniqueness safeguard
All in all, I feel pretty good about
first.m.last ... but it wouldn't hurt to have a fallback.
I've seen companies append an index like
first.m.last.2, but that's kind of demeaning, isn't it? And it's not particularly meaningful that a user is the second with that name.
Consider the condition under which you run out of options:
Someone already working in the org has claimed an ID for themselves.
A newbie comes on-board with the same
The newbie is not ready to change their name for the company's sake.
What's a hard piece of data that is likely to differentiate them in the system and among their co-workers?
An option I've considered (but never implemented) is the hiring year:
first.m.last.2015. You might have two people with the same name, but it's highly unlikely they were hired in the same year. And it's a number that's memorable and not a bad thing to learn about a co-worker. "Oh yeah, you just started last year ..." or "I forgot how long you've been here ...".
If you buy that logic, you now have to ask if the year should be appended to everyone's email. I find that option obnoxious, although more consistent and equitable. Personally, I'd take the risk and leave it off until I needed it.
This reply got way out of hand on me.