In this guest article, Intel Innovator, Peter O'Hanlon, explains the art of user engagement, from how to create it to how to measure it.
Introduction
In this article, we are going to look at User Engagement, or how our users react to the applications we provide and how engaging the user goes beyond the boundaries of our applications to their every interaction with you. Generally, when we see User Engagement talked about online, people are talking about it in the context of websites, but it is equally important for applications and mobile apps.
By the end of this article, we should reach a point where we can intelligently make decisions about how to measure how well we’re engaging with our users.
Definitions
Throughout this article, you’ll see references to application. We use this term to mean something the user uses, be it a website, an executable or a mobile app.
User Engagement Is not User Experience
Before we proceed any further in looking at what User Engagement (UE) means to us, it’s important to get a sense of how it fits into the whole idea of User Experience.
When we talk about User Experience (UX), we are talking about a superset of design and management features that indicate how useful an application is, what value it brings to us, and how easy it is to derive the value, as well as the aesthetics of the application, the workflow, and finally, the engagement of the application.
If UX is the superset, how do we define User Engagement (UE)? At a simplistic level, engagement refers to the “enjoyment” of the application experience, which should encourage appropriate repeated use. I put enjoyment in quotes there because this reflects the fact that UE is an emotional response. We want to engage our customers in a way that gives them a positive feeling, hence the enjoyment. We want our users to prefer to use us over the competition; so we want to give them a response that means that they associate good feelings with our application.
This leads us to an understanding that the “art” behind UE is measuring the likelihood that users will continue to come back at appropriate times as customers, and also to encourage others to become customers. Ultimately, this leads us to realize that UE ties in with the definition of engage that we see in sources such as the Cambridge dictionary:
It’s Bigger than the Application
It will probably not come as a surprise that UE doesn’t just stop at the application level. There are many factors that affect how our customers view our brand and these all affect how much they enjoy the experience.
While we may have a strong application, a user is unlikely to use it if there are pain points that get in the way of them using it. Unfortunately, these pain points tend to become accepted habits and when one application does it, others may follow them without thinking whether or not they bring any benefit.
There was a period of time where it was common for companies to require people to register to download pretty much anything. If we wanted a copy of the technical specifications, we had to sign up. Generally, this was required for marketing purposes; this provided the company with a readymade list of people who might be interested in our products and they could follow these potential leads later on.
The reality, of course, was that people made up email addresses because they didn’t want to have these follow up marketing requests. They might have been evaluating twenty or thirty products and they didn’t wish to be inundated with these follow up requests. The belief, from the company point of view, was that this process makes it easier to convert to sales.
What we saw was there was a barrier to engaging the user. By making it painful for the user to get at the information they wanted, a company was providing an experience that lessened the chance of signing someone up. There are ways, of course, to mitigate this negative experience; imagine how the user would feel if the act of signing up resulted in them being sent coupons (for instance) for unrelated products. While this might not translate into someone ultimately using your product, they are much more likely to have a positive impression of your application because you have shown that your processes are in place for the benefit of the customer.
Ultimately, we want to provide an experience and content that draws the user into our application. We want to minimize bounce where someone comes to our application, uses it once and moves on.
We touched on processes here because they can have such an impact on users. When something goes wrong and our users want our help, they are much more likely to have a positive experience if we have knowledgeable support staff available at that point. Queues or numerous phone menu options are likely to frustrate, and this leads to a lack of engagement.
Scenario
Imagine that you have a web-based email application and that you’ve spent a couple of hours typing a lengthy email message when your PC crashes. You’re going to be pretty unhappy that you’ve lost your work and that you are going to have to do this work all over again. Your experiences here are fairly negative at this point – the crash, while not the fault of the company that provides the email facility, means that your overall experience is unhappy.
Okay, you’ve rebooted your PC and gone back into your email editor, ready to start typing your email again. But wait, the email provider has thought things through and realized that crashes happen so the editor contains the email you were typing, minus a couple of edits because the crash happened between automatic saves. At this point, you are much more likely to have a favorable impression of the email provider. If none of the other email providers have this facility, you’re much more likely to come back to this one because you now experience a positive reaction.
Technically, this wasn’t too difficult for the email company to implement, but the impact a feature has on a user is quite major; a user is much more likely to assume that we have catered for other problem areas because we have shown here that we take care of the little details. More importantly, not only have we delighted our customer, we have potentially made someone an ambassador for our application as this makes them much more likely to recommend us to others.
The Importance of Recommendations
Recommendations play a big part in user engagement. An engaged user is much more likely to praise and recommend our application than a disinterested user. Recommendations can come from personal as well as professional sources, so we must treat every interaction with our users as a source for a positive experience.
How many times have we looked at a piece of software and then gone to see what others say about it? With the rise of video reviews on YouTube as well as numerous review sites, it’s all too easy for potential users to find out about us. We are far more likely to draw customers in if reviewers are engaged with us.
When we create an engaging experience, we are more likely to get users who will tell others about us. But that engagement doesn’t need to stop at the product level. Well defined UE strategies will often coincide with activities outside our sites. Engaging our customers might also mean providing engagement scenarios in social media outlets such as Facebook. Using social media is an effective way to get an understanding of what customers expect from our products and also providing feedback to them about upcoming changes, and gauging the impact before committing to actual development time.
Metrics
It’s appropriate, at this stage, to consider what decisions we need to make when we want to measure how our users are engaged with us. Is there a one size fits all solution to determining engagement, or is this something that we need a strategy to determine on our own?
It will probably not come as any surprise to realize that, just as our applications are our own, the criteria that we use to judge engagement are going to be our own as well. Determining engagement starts with defining what we consider useful metrics to track. For instance, Google Search can be considered to be engaging because it has a high rate of returning and new visitors, even though they don’t spend long there. If our application provides articles though, a high rate of returning and new visitors wouldn’t indicate an engaged user, if they left the application after 10 seconds – so we would be looking to consider the bounce rate here; how long we were retaining users. Again, the returning users might not be a useful metric on its own. We might decide that an engaged user is someone who has our application as part of their daily life, so “recency of use” is a relevant metric for us. The point is, there is no “one size fits all” set of metrics that we need to take into account. We need to choose our metrics based on what it is that our application does.
A simple example here might help. Suppose that we have a Christmas countdown tracker that starts on December 1st. Our metrics wouldn’t want to track the average number of users who use our application over the year. Instead, we would be much more likely to want to know the number of returning users from previous years, as well as the number of new users; we would also probably be interested in how often they returned to our tracker over the short period the application is relevant annually. While this might seem a trivial example, it does highlight that the choices of metric are important and that the purpose of the application is important.
Deciding on the metrics we want to track should take into account that user interactions may change over a period of time. The needs of a user may change over a period of time, so while they may engage in one part of our services for a certain period, over time this may shift so that they move away from using one application because it is too basic for them now, to using another of our applications because that offers a fuller feature set.
The way we track metrics largely depends on the type of application we are developing. If we are developing a website, then tools such as Google Analytics are an excellent resource. For mobile applications, we might want to use Facebook Analytics. Alternatively, we might want to roll out our own analytics services for our desktop applications. Whatever choice we make, we need to ensure that we have decided well beforehand what the appropriate metrics are for us.
For one application I launched, I decided that my user engagement criteria would be the average time a user spent in the application, against the number of active users. Beyond that, I wanted to track how the number of times users navigated around the application, and compared this to the number who stayed purely in the home screen. Finally, I was interested in seeing how many users would spend time customizing the application – tracked as the settings. These stats were fed back anonymized so I could aggregate them. In order to visualize the results, I developed a custom analytics application that allowed me to zoom in or expand out to visualize the data to as fine a degree as I need to. As this was a desktop application, I had the luxury of creating an application to do this but it is possible to get a similar level of detail from analytics sources such as Google and Wordpress.
Custom analytics tracking application usage from 2012 to date.
Conclusion
We have looked at what User Engagement is, and how it fits into the whole User Experience approach. We have also reached an understanding of what engagement with our users means, and how we should think about all the interactions we have with our users.
Finally, we have explored what goes into deciding which metrics to track and how other forms of interaction, such as social media sites, can work in our favor.