More on the Usage Lifecycle: Lifecycle Messaging

A great example of the Usage Lifecycle in practice.

The other day I wrote about the idea that people go through a progression as they use your software, what I call the Usage Lifecycle. I described how Tripit.com was doing a good job at getting people over the hurdle of Sign-up with several really nice features on their site.

Here’s an example of a design team doing a good job of getting over a different hurdle, the hurdle of Return Visits.

Half.com founder Josh Kopelman wrote a great post on what he calls lifecycle messaging. He wonders why this technique isn’t used more:

“I’m surprised how little pro-active messaging/communication most Internet companies do. And if they do send me an email, it tends to be a generic weekly promotional email that they send to all users. One thing that I learned at half.com is the importance of lifecycle messaging — in which you deliver different messages to different users based on where they are in their lifecycle.”

Josh gives several examples of how they used lifecycle messaging at half.com. They paid very close attention to new users, in particular, sending them emails at very specific times in order to keep their attention and time their next action. They found out that two weeks is very important in the lifecycle of book readers:

“The average fiction book is read within two weeks of purchase. So if you purchased a John Grisham book for $8.75 on Half.com, chances are that you will finish it within 14 days. We decided to implement an auto-email that was sent 17 days after purchase that said “Want your $8.75 back, click here to list your Grisham book for sale”. We found that the open (and conversion) rate of that email was amazing — and it greatly added to our ability to “turn” the same book multiple times.”

This is fascinating in its simplicity. Once you know the day that someone receives a book, you know a lot more about them…they’ll probably read that book within two weeks and will be ready to get rid of it after that. And it doesn’t have to be email-based, either. It could be something embedded right into the dashboard of users that changes based on some metric, say how many times the person has logged in.

As some readers pointed out, the usage lifecycle isn’t a novel idea. Some industries have been using lifecycle messaging for a long time. Take, for example, this insightful post by Andrew Chen (both Josh and Andrew are excellent bloggers), who writes about how the casino industry in particular is fond of the lifestyle framework.

Why, then, are web applications so far behind? I think it may have to do with how we’ve approached web apps. For a long time we treated web applications as products, akin to physical products that are produced and used. We also treated them as publications in a way. But web apps are more like services delivered over time, or perhaps more descriptively tools that talk back.

So the overall value of the usage lifecycle is to really dig into the steps it takes for someone to become a passionate user of your software. The crazy thing is that you probably already have the information you need, but just aren’t surfacing it in your interface design. The important thing to remember is that people don’t become passionate overnight or without cause.

And, for the folks who asked why I organized my book around the usage lifecycle? Well, that’s easy. I tried to identify the problems that designers and developers were having over and over and write a book to help address them. The problems I kept seeing became the hurdles in the usage lifecycle: Gaining Awareness, Getting people to Sign-up, Coaxing Return Visits, and Eliciting Emotional Attachment. I’ll be writing more and more about these things over the coming weeks.

Now that I’ve fleshed out the usage lifecycle and lived with the idea for a year and I’m starting to get feedback from folks reading the book, I’m confident that these are indeed core challenges that many folks are dealing with. They aren’t easy, but they’re not black magic either. We simply need a framework that puts them in perspective. That’s what I’ve tried to do with the usage lifecycle.