A 6-Step Plan for Creating Genuinely Useful Product Support Pages

Key Takeaways

• A well-designed product support page is not only a tool for addressing user queries but also a valuable resource for identifying and rectifying UX issues. Start by determining the purpose of your help pages, whether it’s a platform for peer-to-peer help, a direct line to support staff, or a self-help resource.
• Carefully consider which user actions will be served by your help pages and identify the points in each use case where a user will seek help. Plan how you’ll present your help, ensuring it’s easily accessible, logically categorized, and maintained regularly. Different user problems may well be best solved by different content formats.
• Measure the effectiveness of your support pages through more than just “Was this information helpful?” ratings. Use analytics to track user behavior, conduct surveys, and use click-tracking tools to understand which pages and parts of pages are working and which need tweaking. This data can be instrumental in improving both your help site and product UX.

It’d be nice to think that your product UX is so exceptional that users won’t ever need any help with it. But until every user thinks exactly like you do, your target audience and users will have questions.

How will you answer them?

This six-point plan should help. Not only that, it will help you create help information that actually helps you identify problems with your product UX – problems you can ameliorate, if not solve, with better design.

Let’s see how.

1. Determine the purpose of your help pages

Working out what you want your help pages to do is a pretty obvious first step. Depending on your product, audience, and support strategy, your online help pages’ purpose may vary:

• Is it a place where users can help each other?
• Will it let users contact your support staff direct? In real time?
• Is it a place where users can access self-help?

You’ll likely already have an idea of what purpose, or purposes, you want the pages to serve, but it’s good to put it into words up-front, before you begin to consider help formats or technologies.

2. Choose which user actions will be served by your help pages

This is an important point, one that directly reflects your overall support strategy.

Yet it’s easy to get this bit wrong: to decide you’ll create an FAQ page and expect it to do everything users need, or to simply list an email address, and pay support staff to answer common questions that could more effectively be answered with some FAQs.

So think this through. What kinds of questions, if any, will be addressed on your help pages? Which user actions will you provide self-help for? And what will be the next step or steps for users who can’t resolve their issues on your help pages?

One point here: it’s easy to start thinking that all users will just contact support if you list a phone number or email address, so why bother with help pages?

But in my experience (and probably yours), a majority of users do want to self-help. This can be great for your support strategy, if you take the time to work out where the breaking points are, and how far you actually want your self-help content to go.

3. Identify the points in each use case where a user will seek help

Now it’s time to go a bit deeper and look at actual use cases you’ve used to develop your product.

Look through the key use cases, page flows and actions users will pursue within your app, and make a list of the questions they’ll have, or problems they’ll face along the way. Perhaps you’ve already done this as part of the UX design and dev process. Great. The important thing is to identify where in your product help is needed, and what will be helpful at those points.

By the end of this task, you should have a fairly solid list of information you want to make available to users through self-help pages. Ideally, you’ll also be able to group that content into logical, user-centric categories.

4. Decide how you’ll make help available at each break point

When users get stuck, how will they access your self-help content? There’s no point spending time creating it if users can’t find it when they need to.

So think about how you’ll make it available in each use case. There are plenty of options, from the good old ‘Help’ link, through to in-app tooltips and tours. What suits your users’ needs best?

Also important: how will you keep answering that question as you add new features that require support?

5. Plan how you’ll present your help, and create and look after it

The answer to the question of presentation will depend on your users’ preferences.

Will you explain solutions through text and images? Videos? Tours? Forums? Will you offer help in downloadable formats? In different languages? Does it need to be printable? (Scoff all you like, but users of the site I work on are pretty big on the old Print icon.)

Note that different user problems may well be best solved by different content formats. When it comes to help, one size doesn’t usually fit all – and if it does now, it may not for long (assuming your userbase is growing, and you aim to take on new markets).

Next, decide who’s going to put the help information together and be responsible for its maintenance. How will you time the addition of help content around new feature releases? Who will test the content you develop, both now and in the future, for accuracy and usability? What systems or technologies will you use to store and present it?

A tip here: plan ahead. Try to anticipate the structure and scope you’ll need to allow for new content that supports your growing product (and userbase). The information you’ve gathered through this process should give you some insights to help you do that.

It’s not a bad idea to throw those ideas for future self-help into your plan, so that you can be ready (that is, not need to restructure the whole thing) when the time comes.

6. Work out how you’ll tell if it’s working

Believe me, those “Was this information helpful?” ratings you see at the bottom of help pages are useless if you actually want to know if your help is doing its job. A yes or no answer tells you nothing about what works and what doesn’t on your help site.

Nor will it give you insights that you can use to feed back into improving your product UX.

So what does?

To begin with, you’ll probably have pretty simple metrics. For example, what proportion of your product’s users wind up on your help site? How often are people accessing the site? How long do they stay? What are your most commonly visited pages? Is your live support team mysteriously dealing with questions that are amply answered in your online help?

Some kind of analytics are obviously needed to answer these questions; but go further if you can. Consider user surveys if you track users across your help pages, or if you can survey users who contact your live support. Use click-tracking tools to see which pages, and parts of pages, are working, and which need tweaking.

Believe me, you’ll be surprised by what you learn.

What’s your plan?

Obviously, how far you go with any of these steps will depend on the nature of your product, your userbase, and your business.

If you’re just starting, you may be able to jot down the plan as a one-pager. If your product’s more complex or more mature, you might go further – right to the point where you develop a detailed content strategy, with measurable goals, around your help pages.

Whatever you do, don’t overlook self-help as you develop your support strategy. A handful of FAQs probably isn’t going to cut it for many users, or many products.

Do you offer self-help to users of your product? I’d love to hear how well you think it does to support users, and what you (and they!) struggle with in the comments.

Frequently Asked Questions (FAQs) about Creating Useful Product Support Pages