A second trick restaurants use is to create a line out the door so that people think there is strong demand. This is also often artificial, making us think that many people are waiting to get in. Sometimes they merely create lines by not letting people sit down, making an excuse that the empty seats are “reserved”. Other times they simply don’t let people in. This is often practiced by nightclubs, who rely even more on mystique and exclusivity than restaurants do.

These techniques leverage powerful social behavior. When people are searching for a place to eat, they rely on the behavior of others to help them make their decision. They seek out signs of life…signs that other people are present and already doing something. If they are doing it, it must be worth it, we think. Given the choice between something that nobody has chosen to do and something that many people are doing, it is human nature to gravitate to what others are doing.

On the web, signs of life are extremely important, for several reasons.

• Too much choice
  One reason is the sheer amount of choice we face. As the web continues its torrid growth, we simply have too many web sites to sort through, too many places to buy products from, too many software providers to pick from.
• Black box of use
  Another reason signs of life are important is that web applications are like black boxes. Many applications, like Google Docs, for example, require a login to use. Because of this we simply can’t see what others are doing with the software. We can’t see if they’re using it well or not using it at all.

When sites leverage signs of life well, it provides welcome direction for folks trying to make a decision. A great example of signs of life is the Freshbooks home page, which contains an interface element called “Some of our happy users…”.

The happy users element does many things well. Most importantly, it is authentic. You immediately get the sense that these are real people who actually do like the product. The pictures are decent, but not airbrushed or overly produced. The quotes sound like real people, not infomercial-like. Subtle touches like using people from all over the world and including team size add to the sense that these people are just like you: the intended audience.

In addition to these testimonials, there are many other ways to leverage signs of life. I describe several more in Designing for the Social Web. But though leveraging signs of life in your design is powerful, it must be authentic. You can’t use stock photography and made-up quotes and expect people to react positively to them…people can smell fake a mile away.

While the Freshbooks people aren’t actually standing in line outside the door of a restaurant, they might as well be. They’re having the same effect: showing others there are people here using this software…acting as signs of life on what could otherwise be a desolate home page.

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.

Babycenter.com has a really great newsletter. Once you tell the site when you’re expecting, it sends you a weekly newsletter targeted at the specific stage of pregnancy you’re in. At 4.5 months, for example, it tells you that your baby weighs about 10.5 ounces and is 10 inches long. This information is timely and relevant…it knows exactly what stage you’re in and helps you deal with the stresses and questions at that point.

The key to babycenter’s ability to deliver a relevant newsletter is that they know your delivery date. Once they know that, they know *a lot* about what you’re going through, as pregnancy is a well-defined process that is mostly the same for everyone. Nine month cycle. Kid. Simple.

Can people designing products of all sorts take advantage of this lifecycle process? Yes, I think they can. One of the primary ideas in my new book, Designing for the Social Web is a similar kind of lifecycle, what I call the “Usage Lifecycle”. The usage lifecycle isn’t as clear cut as pregnancy is, but it recognizes that people go through a progression as they use software. They go from not knowing much at all (like parents early on in pregnancy) to feeling comfortable with the product (like, say, when parents become grandparents ) to finally being passionate users.

The Stages of the Usage Lifecycle

The stages of the lifecycle are straightforward and simple. You can dive into lots more depth as your application warrants, and you can add stages, but for the most part these five stages apply to almost all software.

• Unaware This isn’t so much a stage as it is a starting point. Most people are in this stage: completely unaware of your product.
• Interested These people are interested in your product, but are not yet users. They have lots of questions about how it works and what value it provides.
• First-time Use These people are using your software for the first time, a crucial moment in their progression.
• Regular Use These people are those who use your software regularly and perhaps pay for the privilege.
• Passionate Use These people are the ultimate goal: passionate users who spread their passion and build a community around your software

Note that each of these stages describes people, as opposed to a product or a market. It describes the different types of relationships people have with your software product. Have they used it yet? Have they even heard about it? What questions do they have?

Each of the stages are separated by hurdles. The hurdle between the “unaware” stage and the “interested” stage is “awareness”. At this stage what you need to do is make people aware of your product. How do you get people aware of what you’re doing? How do you get them interested and wanting to know more? How do you begin the conversation of what you do and carry that over into a meaningful relationship?

The lifecycle is particularly relevant to web-based software because the product is inextricable from the service. The product is the service. If a person has a question about what your software does, for example, you can literally build that answer into the software itself. One of my favorite examples at the moment is Tripit.com. Tripit’s design is great at moving people from the “interested” stage to the “first-time use” stage, getting people over the hurdle of “sign-up”.

One of the ways that Tripit does this is by clearly explaining exactly what their service is and does. While this may seem like an easy thing to do, it’s actually quite hard. To boil the essence of your software down into a handy 3-pane “how it works” graphic seems like child’s-play. But only the resulting graphic is simple. Creating the simple thing is the difficult part.

Another way that Tripit helps people get over the hurdle of sign-up is to make it super easy to sign up in the first place. They have a great feature that lets you simply forward them an email from a recent flight or hotel booking. They take that booking email and auto-create an account for you. No sign-up page to create an account. All you do is send an email.

One of the problems I’ve seen over and over (and I’ve been guilty of this myself) is to recognize the stages while talking to people face to face, answering their questions, but then failing to bake that knowledge into the interface itself. By formalizing this conversation with the usage lifecycle, you can begin to set up a process of describing each stage in-depth, and then creating screens with that exact same information placed right on your web site. Just like Tripit does.

The usage lifecycle isn’t a new idea. It’s very similar to what a good salesman does when they target customers. They find out where the person is in the purchase lifecycle, and then tailor their message to get people moving along toward purchase. They answer the same questions over and over, point out the same features and benefits over and over. The lifecycle for any particular product or service is remarkably stable…it’s only a matter of identifying the lifecycle and designing for it. What babycenter has done with pregnancy, we should all be able to do with the usage lifecycle of our software.

So that’s an introduction to the usage lifecycle. I’ll be blogging more about the lifecycle as I work through the sections of my book: Designing for the Social Web.

On that note, I thought I would start talking about my book Designing for the Social Web by sharing the first quote in it. It’s a quote from what is undoubtedly one of the top 5 pieces written by anybody on the subject of the Internet. It’s from Douglas Adams’ 1999 piece: How to Stop Worrying and Learn to Love the Internet

“During [the twentieth] century we have for the first time been dominated by non-interactive forms of entertainment: cinema, radio, recorded music and television. Before they came along all entertainment was interactive: theatre, music, sport—the performers and audience were there together, and even a respectfully silent audience exerted a powerful shaping presence on the unfolding of whatever drama they were there for. We didn’t need a special word for interactivity in the same way that we don’t (yet) need a special word for people with only one head.

I expect that history will show “normal” mainstream twentieth century media to be the aberration in all this. ‘Please, miss, you mean they could only just sit there and watch? They couldn’t do anything? Didn’t everybody feel terribly isolated or alienated or ignored?’

“Yes, child, that’s why they all went mad. Before the Restoration.”

“What was the Restoration again, please, miss?”

“The end of the twentieth century, child. When we started to get interactivity back.”

I put this quote at the beginning of the book because it completely rewires the way we think about the Web. It is a new technology, sure, but the primary power of it is to enable interactivity…a return to interactivity that we’ve been slowly eroding with other forms of technology. As we design web-based interactive systems, it’s nice to know that we’re not conjuring value out of thin air…we’re simply returning to tried and true forms of human communication.