Inspiring? Ummm...not so much. Think they are excited to get started using it? Probably not...you'll be lucky if it doesn't go right to the trash.
As Nathan and I discussed at Lotusphere, when we talk about the user experience, we're not just addressing the UI of an application, but all aspects of the user's interaction with it. This means the help file, bug reporting, community discussion, and yes...even the introductory e-mail. In fact, this e-mail can be one of the most important things you design. Let me explain.
With the cognitive overload that most users experience when looking at their inbox, your message needs to stand out and gain their interest. Kathy Sierra once talked about how companies get things backwards. They spend a lot of time and money making really cool, slick glossy brochures to sell a product and once you get it, you open the box to find a boring, black and white manual. This is somewhat analogous to the introductory e-mail. You may have impressed the application owner with your "mad skillz" and got them quite excited about the app, only to disappoint them when they see the mail you've sent to everyone in the company. How many times have you sent a link to a user and later heard something like "oh...I didn't know what I was supposed to do with that, so I just threw it away"? This is to be avoided if you hope to build a passionate user community around your application.
Unless you work in a very small environment, chances are that most of your application's audience will not see the actual application until the day of release. In fact, many of them may not even be aware of the initiative and your e-mail will be the very first contact they have with it. Thus, it's really important that the e-mail contain some key details. At a minimum, you should include:
* Name of the application
* A brief description
* Name of the application owner
* Instructions for getting started
Depending on your user audience and their skill level, your e-mail may need to include more details and step-by-step help, or you might be able to get by on just the basics. As with all of the things I talk about, it's up to you as the developer to make a judgement call to determine what is best for your given situation.
Here's an example from an application rollout I was involved with to give you a better idea of what I'm getting at:
Notice that some care was taken to build this e-mail. Attention was paid to the layout and some nice graphics were added to give it a more professional appearance. In this example, a new database was being deployed and a training session for the application was planned about a week out. It was desired to have a hands-on training session, so it was important that the end users have the database locally replicated to their laptops. In this scenario, they were well aware of the application and it's purpose, so this e-mail was intended to assist them with the process of creating the replica, setting up the bookmark, etc. It was divided into a series of easy to understand steps, so that even new users (of which there were several), could figure out what to do. We even performed some quick user testing on the e-mail and some small modifications to the text were made as a result of the tests.
The extra time it took to construct this e-mail was negligible when viewed as part of the overall project, However, the initial impression it gave to the future users was that this was a professional initiative. Post rollout feedback was very good and the ease of performing the initial setup by following the e-mail instructions was mentioned by several users.
When all is said and done, this is just another small step you can take to improve the user experience in your applications. It doesn't take much effort and may seem to be rather insignificant in the grand scheme of things, but remember that the little things can add up and you'd rather have them add up to a positive than a negative.
*A little reference to "Sky High"...a great Disney movie for the family.