Technical writers and product managers alike would love it if the quality of a product’s user assistance—that is, its manuals and online Help—were a major factor in customers’ deciding whether to purchase the product. But, while user assistance does have a positive impact on product acceptance and user satisfaction, it does not usually play a major role in influencing someone’s decision to buy a product. Typically, lack of usability and bad documentation are aftermarket issues. By the time users encounter difficulties using a product or its documentation, it is too late—they have already bought the product.
But there is one dramatic exception to this general rule: when you provide a demo version of an application as part of your sales and promotion strategy, its documentation can influence customers’ decision to purchase the product.
Demo software changes the rules. Customers purchase your product only after it has proven its usefulness. Usability barriers in demos often cause customers to decide not to purchase—after all, their commitment to your product is minimal at that point. Plus, product reviewers often use demos to evaluate products. They rate your product based on how well the demo performs for them. A poor review can discourage many potential customers from even trying your demo, let alone purchasing your product. In both of these scenarios, your product’s user assistance can affect how successful a user or reviewer is in getting your product to work for them, in the critical window during which they’re making their judgment about your product.
Champion Advertisement
Continue Reading…
Optimizing User Assistance for the Demo Experience
You might think: We have great documentation. I’m glad to include it—as is—in our demo. But have you optimized your user assistance to support a demo experience? In this column, I’ll examine how a demo experience differs from the other use-case scenarios user assistance developers typically try to support. Although user assistance for demos might have a lot in common with your usual documentation and training materials, you will see that it has unique requirements you should accommodate to increase your demo’s sales efficiency and help your company close deals.
This column is not about putting benefits-oriented marketing copy in user documentation—those messages have already gotten a customer to download your demo. It’s about supporting user adoption by following principles of innovation diffusion.
Everett Rogers [1] identified the following characteristics of innovations that affect a user’s decision to accept an innovation—in this case, the product for which you’ve provided a demo:
relative advantage—how the innovation is better than what the user does now
compatibility—how well the innovation fits in with what the user can already do
trialability—how easily the user can experiment with the innovation
observability—the extent to which the innovation is visible to others
When creating user assistance that supports a demo, you should be constantly mindful of these characteristics and reinforce them whenever possible.
Here is a useful formula to help you create user assistance that optimizes the effectiveness of a demo and make the sale:
Identify the core value proposition of the product.
Envision the simplest experience that would demonstrate that value.
Help the user create that experience around his or her problem or data.
Identify and highlight any market differentiators in that experience.
This approach enables you to develop user assistance that provides a focused, successful experience and makes users confident your product can solve their problems—in ways that make them perceive your product as easy to use.
Identifying the Core Value Proposition
Is mail merge a useful feature in a word processor? You bet it is! Is it why someone buys a word processor? Probably not. The core value of a word processor is its ability to let you create content, edit it, save it, and print it—or email it. If it can’t do these things, it doesn’t matter what else it can do. So product managers must exercise some restraint and focus on their product’s core value proposition.
Don’t just provide exhaustive documentation for your whole product and hope users will discover your product’s value on their own. For example, if I were trying to sell a word processor by providing a demo, the last thing I’d want users stumbling upon would be mail merge. But, most of the time, it is impractical to create a demo with a reduced set of features. Anyway, users might get the wrong impression—thinking the demo provides a complete set of features and is missing some features they need. So to reduce the risk of users getting lost in the forest and being distracted by all the trees, a better solution is to provide documentation that shows a clear path through the forest and points out the more interesting trees along the way.
Envisioning the Simplest Experience
The best way to make something look easy is to actually make it easy. In Agile software development, there is the principle of just barely good enough. No release should include effort, detail, or cost beyond what it takes to get to the next level. This is a good principle for demos as well. What is the least a user would have to do to understand the value of your product? Figure that out, then provide user assistance to guide them through that experience.
For example, let’s say your product is a vulnerability scanner that can detect potential security weaknesses on a customer’s network. It includes an array of scanning templates—any one of which the customer could modify to meet his or her needs—and also has a reporting module that can produce results in a number of customizable formats. What’s the minimum experience a customer would need to conclude, Hey, I need one of these—coupled with the feeling I could do this. Probably no more than setting up a simple scan that shows the customer a lot of vulnerabilities exist on their network. You can achieve this with a basic scan template and a simple HTML report the customer can review immediately on his or her computer screen. Voila! There is your simplest experience.
What about modifying a scan template or adding the customer’s own logo to a report? These would be nice to mention, for sure, but it is not necessary that the customer should go through all that effort—or encounter the potential risk of failure. So those tasks shouldn’t be part of the demo experience and, therefore, shouldn’t be featured in your demo’s user assistance.
Getting Customer Context into Your Demo
One way to overcome resistance to innovation is to let users have a safe place to play with your product. You already have a good start on achieving safety, because you’ve envisioned the simplest things customers can do. The best sandboxes, however, let users bring their own data or problems into the product experience.
Your product might have existing tutorials that help users understand the product features. But most tutorials are about somebody else’s problems or use somebody else’s data. For example, in a spreadsheet application. I can follow a tutorial that lets me set up a sales report for company XYZ. The only problem is: once I’ve finished, all I have is a sales report for company XYZ. But what I really want is a budget for my department. The more a demo can leverage a customer’s actual problems or actual data, the better.
Going back to the vulnerability scanner example, it would have a limited positive effect if a customer could scan a test group of devices the vendor made accessible over the Internet. But the impact would be much greater if a customer could scan real devices on their own network. Tutorials generally do not provide that level of context. Instead, they try to prepare people to use your product on a full-scale project by first having them do some little exercises with test data. User assistance that supports demos can help customers identify strategies for using an application to solve their real-world problems, so they can see how the product works in their own context.
As another example, a demo for a Help authoring tool should not limit users to working with some sample topics about an artificial topic—such as “The Care and Feeding of Bats.” Instead, it should let users create a cluster of production Help topics they could actually use if they decide to buy the tool at the end of the demo cycle. Imagine the impact if they’d already been able to create some actual Help topics and could just link them to the prototype of their software. This sure beats “The Care and Feeding of Bats.”
To enhance the safety of the sandbox, a demo’s user assistance needs to explain how to undo or get rid of things, as well as how to create them. In learning mode, users are more willing to experiment if they know they can eliminate their mistakes. User assistance for a demo needs to make it clear users can do this and clearly tell them how.
Identify the Market Differentiators
No matter how good a product is, to make sales, it has to be better than what a customer already has or could get from another company. The challenge is making sure the features that differentiate your product are part of the simplified, core-value user experience you’ve designed into your demo’s user assistance—without adding undue complexity. One pattern is to show the simple, then describe the complex. Going back to our vulnerability scanner example, you could have a customer do a simple scan, using a basic template, then point out that there are more complex templates that the customer can modify, if needed.
Distributing User Assistance for Demos
Once you’ve created user assistance that provides an optimal product demo experience for your customers, you can distribute it in a number of ways. For example, you could write a Getting Started Guide that uses the principles I’ve described in this column. Many users like to dabble with a product to get a general understanding of it before diving into it full bore. So even people who have already bought your product can benefit from user assistance that ensures simple, successful experiences, focusing on your product’s core values.
Alternatively, you can create documentation specifically for your demo, which a user downloads along with the demo software. Make sure this documentation refers to the full documentation set, and make that available online as well.
Conclusion
If they try it, they will buy it is an empty slogan—unless you have designed the try-it user experience to show the value of your product and help users to be successful using it. Create the simplest demo experience that proves the core value of your product, let customers experience it in their own context, and describe its more complex implications or implementations. Use your product’s user assistance to guide customers to success through a focused demo experience.
A better slogan: If customers understand our product’s value and experience its usability, then they will buy.
Note
[1] Rogers, Everett M. Diffusion of Innovations. New York: Free Press, 1983.
In his role as User Experience Architect for IBM Security, Mike’s professional focus is on designing usable user interfaces that accommodate the user as learner. Previously, as User Assistance Architect at IBM, Mike identified tools, methods, and standards for integrating the content and delivery of user assistance, including documentation, Help, elearning, and training. He was formerly Lead UX Designer for CheckFree Corporation, where he instituted their User Experience Research and Design Center. Mike has a PhD in Instructional Technology from the University of Georgia and a Masters in Technical and Professional Communication from Southern Polytechnic State University. He is a Fellow with the Society for Technical Communication and a Certified Performance Technologist through the International Society for Performance Improvement. Read More
