One of my favorite things as a product designer is identifying ways to make a user's experience delightful. And when an opportunity presents itself to add a little delight, particularly when the effort required is minimal, I get very excited. Such is the case when working on a feature which included the ability to send invites to users.
In this particular case, administrators would send invites to future users by entering their email address. A valid email address was the only required piece of information necessary before sending the invite. Once an invite was received by the user, they would click a link and register their account by entering their First Name, Last Name, Company, and Title.
One of the 4 Pillars of Enterprise Application Design is efficiency and there are many ways to improve product effeciency. Specificallly applicable to this scenario is not requiring a user to enter the same information twice and provide meaningful default values. With this feature being a part of an enterprise product, the users who would be sent invites are almost always corporate email addresses and follow a relatively standard practice of including both the first name and last name in the email address.
To verify this theory, I ran a query of our customers and found the following:
Over 70% of customers utilize email addresses that contain the first and last names and can be easily parsed programmatically. This would allow the first and last names to be derived for the vast majority of users using this specific feature. Support for email addresses can be parsed for the following:
Additionally, when copy and pasting email addresses from emails or address books, the copied format often contains the name which can be parsed as well. In this case, the provided name is used regardless of the email address format.
The derivation of names helps in two significant ways. The first benefit comes to the administrator who is entering email addresses. Once an email is entered a record is created which they will see in their system. While the user has not yet registered, the only information in the record would be the email address. This makes it difficult to parse who is who simply based on email address. By having a first and last name for each user, it is much clearer who a record belongs to. Secondly, once the invited user goes to register, for over 70% of users, the first name and last name would be defaulted in and the only new information necessary to enter would be their job title. Users would still have the option to edit or remove the name fields, but for the most part would be ready to move on without a second thought.
There is one aspect worth considering when taking this approach and that is how much the administrator will feel compelled to either fill out the first and last name if it is missing or appears incorrect. If the first and last name are presented as input fields, then the administrator may feel obligated to enter the values which in this scenario is unnecessary and completely optional. Is it then a matter of displaying messaging to make sure the administrator understands it is optional? And if the names are shown, but not editable, then that may be a point of frustration to the administrator.
The approach taken was to not present the derived names as text or inputs at the point of email entry. For the administrator in this step, the importance was on entering the email addresses of users and moving on. The complexity and possible confusion outweighed any benefit of the admin seeing the names at this stage. Once submitted, then the derived names would appear in the system and should the admin want to edit a user record at that point, they could... but any sense of obligation should be diminished greatly.
The resulting solution was to derive names from email after the emails were submitted, and only derive the names from email addresses which followed a very common and structured format such as to not create more work for anyone. Doing so benefited both the administrator by not having empty records and over 70% of invited users who would not have to enter information that already existed in the system.