When design teams focus on the Usage Lifecycle, they take an approach similar to what a great salesperson would do. When a salesperson approaches a customer, they first find out where the person is in the sales process and what their ultimate goal is. When you think about your application as something someone is using or purchasing, it’s very similar to a sales cycle.
At each stage of the Usage Lifecycle, users have very different needs and questions. Can you talk about these differences?
When most people first come to your application, they are unaware of what you have to offer them. It isn’t so much a stage, as a starting point. Most people are in this stage: completely unaware of your product.
Each of the stages are separated by hurdles. The hurdle between the “Unaware” stage and the “Interested” stage is “Awareness”. When people are in the Interested stage, they have a unique set of questions. For example, they ask: How does this product relate to what I’m currently using? Will this product or service fit my needs? How does it compare with other products and services on the market?
Most startups need to focus on solving the challenges in the Interested Stage. The problems they need to iron out are Awareness problems. Startups must help users learn about the application, gain confidence, and get users started most effectively. In this stage, I recommend that teams focus on messaging and emphasize the value proposition of the application.
Typically, once users start interacting with the application, most of these initial concerns disappear and now they are Users of the application. As Regular Users, their concerns are now completely different. They are using the product to accomplish a task and fulfill their end goals. When they use the application, they have a different mindset. At this stage, teams need to focus on helping users accomplish their goals and move beyond just making people aware of the product’s features and benefits.
For me, this level of distinction is incredibly valuable. I’m more and more convinced this is where to focus: where users are in their lifecycle and environment. If you can understand this about people, you can help users more effectively.
(Here’s a full summary I’ve written on the Usage Lifecycle.)
What are the best practices you recommend design teams use to first start getting users engaged in a product?
There are a lot of small and effective strategies design teams can use. If your team knows ahead of time when you’ll be launching, I recommend having a beta phase or set up an invitation list to tell people about what you’re doing.
For example, at Performable, we asked prospects to give us their email address to contact them when we launched. When we offered this option, thousands of people signed up. This is a simple thing, but a lot of startups don’t do it.
Another great tactic is message testing. With message testing, teams design two or more home pages (or landing pages) for their application and see what message resonates better with visitors. Once traffic starts arriving at the page, you can easily quickly see which message variations convert the best. Conversion can be different things depending on your business goals, such as users giving you email, signing up for a beta, or signing up for the product.
This technique helps companies find out whether their value proposition is being communicated effectively with visitors. In almost all cases it can be strengthened. In some cases the initial message is the wrong one, such as focusing on a benefit that just doesn’t resonate with the target audience. There is a lot of action in the testing space right now and I’m excited to be a part of it.
A common problem with many applications is that people sign up and then never consistently use it. How can designers combat this problem?
Yes, I see this happen all the time. I call this phenomenon the “Getting Started” problem. This is when people sign up or register for your application and then don’t know what to do next.
To solve this problem, I often recommend that clients pre-populate the initial application page with content. For example, if you have an application that allows people to make a widget, it’s very powerful tactic to pre-populate with a widget already made. People are far more engaged when they get to see how the application works instead of starting with a blank canvas.
With the Usage Lifecycle, most of the solutions are relatively small solutions, but taken together, it really adds to a positive experience if you’ve gotten each step right. With your application, you can’t just have one cool thing happen with your product. It’s the sum total of interactions that make up a successful user experience.
How can design teams create passionate fans of their product?
This is a question I often get from marketing teams. They will often try and add social features to create passionate users. They’ll say, “Let’s offer more sharing buttons or more opportunities to share.” However, while putting a social feature in the interface may result in users completing the interaction more frequently, that’s not the right way to create passionate users.
The best approach is to make users good at something. For example, imagine you are tasked with designing an email marketing software, such as Mail Chimp, Emma, Constant Contact, or Campaign Monitor. The best way to get users passionate about these types of applications is to make them better at their jobs as email marketers.
This really has to do with focusing on the experience users have when they interact with your product and working on getting users good at what the application does. The best design teams focus on a single activity set and ensure that the product successfully supports these activities and makes them simple to do. Once people are good at using the product, they’ll talk about it and share with others. This will also be more authentic. Campaign Monitor is a great example of a relatively small team doing great things by teaching their users how to be better email marketers.
So, the best teams move beyond just thinking about what social features to add to their product. In your writings, you’ve said it’s really more about the personal value of what people are doing. How did you first come to that realization?
Many years ago, I had a conversation with a designer who was building an application for runners. At the time, tagging and folksonomies were the trend and I was really excited about the topic.
The running application enabled users to enter their running time. I’m not much of a runner myself but I was really excited by the social opportunities around sharing running data and the competition it would engender. Knowing that many people thrive on competing with others, I thought there was huge potential there.
But the designer of the app was adamant that I was missing the forest for the trees. He wasn’t all that excited about the social possibilities. While the application would let users share their running time online with others, social influence isn’t the real motivation for serious runners. The people in that market valued their own improvement much more than seeing what others were up to. While sharing was a nice side effect, the most important thing to runners was to see if they were faster than the day before.
This was an eye opener for me, as I suddenly saw this same mistake applied over and over in social software projects. For users, personal value comes first, it precedes social value almost all the time. I call this the Del.icio.us Lesson, named after the popular bookmarking site. With Del.icio.us, people were tagging articles and sharing with groups and there was a tremendous focus on the social aspect of it all. But most people didn’t use Delicious to share stuff with others. They primarily used it for bookmarking stuff for themselves so they could read later.