Sunday, February 18, 2007

You Only Get One Chance To Make A First Impression

Scenario: It's the day of the big application rollout. You've spent countless hours designing one of the best apps you've ever built. Not only have you written some great backend code, but you've worked hard to construct an awesome UI that you're sure will win the users over. The business process owner has asked you to inform the user community of the availability of the new program. You have your trusty admin sidekick (sorry..."hero support*") tweak the ACL and you're in business...the app is live! You click the 'Send' button on your e-mail message and off it goes around the country, perhaps around the world. Your colleagues start receiving the message and open it up, only to be greeted by the following:

Inspiring? Ummm...not so much. Think they are excited to get started using it? Probably'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.


Elf said...

I'm sorry, but I couldn't disagree more.

If there's one thing that will sure make me ignore an email is making it look like a brochure, not to mention an email filled with html and/or images (wich my security filters will remove anyway).

The text in an email should be able to give a brief descprition about what it's about. If it's very important that people visit the database you can either post a message on your intranet's news page and make it look like a brochure, or you make use of the users closest management (or even a higher level management) and have them announce it.

Most of the times I make a new notesbase, it's usually requested by certain users anyway, and they know when it's ready to be used and they start using it when I announce it in any of the ways mentioned above.

Maria Helm said...

@1 - Your security filters shouldn't remove html/images sent from other users on your Notes server. That's complication, not security, IMO.

While I do agree that the email looks more professional (and therefore, I think I will be trying this method), I have to wonder if it really would improve user cooperation or not. My experience has been that the more words you put in the email, the more likely the user will pick up the phone and ask you what they're supposed to do - if they even respond at all. Additionally, some users won't read the email and click the link no matter what the email says, unless their manager asks them if they have done it.

A lot of this depends on the corporate culture, though.

I do have to ask:
1. How did you make the rounded shapes that number the sections.
2. How much time did it take you to design such a handsome email?

Stephen Hood said...

Have to agree with you Chris. If you show that you put time, spit and polish into something people will generally be more receptive.

Especially if you continue to do it as your standard behavior. Over time it has an effect that creates greater respect for the application/initiatives etc.

If you just throw it "over the wall " people figure if they don't care about it why should I?

Ed Brill said...

Man, Chris, that is slick. If I worked for Linde, I am pretty sure I'd be clicking that button and opening my new application in moments. They probably have no idea how good they have it :-)

Elf said...

@maria helm: I work in a corporation where we share notesbases, but we are in different domains and networks and email clients. So an internal email like this would still be interpretated as an external email by the mail server. And it should be.

While I have picked up several tips from Chris and I subscribe to this blog because I find it a very good one, I have to say that this is a case where the desire to make a fancy design has surpassed the usefulness.

Now, making that email in to the help or about page in the notesbase would have been brilliant, but making an email like that to solve the problem with indifference from the users is not a very good solution, imo. As you say, it depends on the corporate culture, and if I worked in a culture where I had to almost make flash animations to get people to care about important infrastructure systems, I would think we had bigger problems.

Chris Hart said...

Very nice Chris. I'm definitely closer to the first example, but I might give this a try.

Elf, while I empathize with your position that html and graphics in email is just wrong, you have consider the audience. For an application like this, the audience is going to be a lot of people who appreciate the look of a graphics-heavy email, and not as many IT purists.

Ashwin said...

I agree with you Chris.. This is an awesome idea although it would take a lot of time to actually build the email. Also, most of the time its the application owner or the functional folks who send out the roll out email, so it kinda depends on what they would want too! Anyways, I'm surely gonna try this out.


Sally said...

Many times, I get users who need their "hands held" when rolling out an application. This email is much more useful than an everyday ordinary "Here is your database link" email message. A typical end user who wants to know about the application that they are using would find the descriptive email VERY useful. This will also save time (and a lot of phone calls) in the long run in explaining how the application works to the users. Great info Chris!

Bruce Elgort said...


I like your approach. First off I am sure the users know that it pertains to "their" company and won't think that it is sometime of "spam". The way you used the "1" and "2" is wonderful. I know that my users would love to see something like this. Thank for you for this inspiring blog post.

Gregg Eldred said...

Chris, this approach kicks a$$. Very, very nice. And one that I will start to advocate. Great post!

Chris Blatnick said...

Hi Everyone...thanks for the great discussion and comments, both for and against!

@Elf - Indeed, often the culture of a company will dictate whether an idea like this is useful or can succeed, but I think you go a little too far stating that you might have bigger problems if it takes a mail like this to get people interested. Many times, the problems inherent in talking about UI design, usability and the like with technical people is that they don't understand the unique challenges of being a user. Users are often overloaded with e-mail as it is, and the introduction of a new app that they didn't expect was coming needs some foundation behind it. I agree that this is unnecessary overhead if all of the intended users know it is coming, but we don't always have this luxury. Certainly in my case, when I am rolling out applications that will be used on a international basis, the number of users that know about an application in advance of its rollout is small.

In addition, in my experience, images in mails are certainly not a bad thing. From the psychological standpoint, a mail like this one has much more impact than just plain text. Our brains are wired to respond more favorably to a aesthetically pleasing design, so I suggest using this fact to your advantage. In any case, I realize this approach won't work for everyone everywhere, which is why I always say that this stuff is a balancing act and that you have to make the decision that is right for your environment. I do encourage people to try some of these ideas, though, since they can lead to some powerful realizations about your corporate culture. Even if you are of the mindset that images in e-mail are completely evil, I still advocate including the key details in the e-mail rather than just throwing a link at them. :-)

@Maria - There's nothing special about the rounded shapes unfortunately. I just designed them in my graphics editor and pasted them in. The entire e-mail is formatted with standard rich text, laid out with tables and images, but no HTML. It really didn't take long to design the e-mail...probably less than half an hour.

Anonymous said...


Your blog has been very inspiring. I am going to try out this approach when I roll out my next application and see what kind of feedback I get :)

Keep em coming !

Dan Soares

Mike Kinder said...

I agree with Chris, but I would like to make a small point. The "email" Chris put together could have easily been the "About" or "Using" document of the database. Once designed and ready, Chris could have just opened that element from the help menu, and used the Forward Action, and it would be sent as an email. Remove the "Forwarding header" of course. Then it serves two purposes. As long as all of the images are a part of the "About" or "Using" document it should work great.