vc6创建dll文件的步骤_创建真正有用的产品支持页面的6步骤计划

vc6创建dll文件的步骤

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.

可以很高兴地认为您的产品UX非常出色，以至于用户永远不需要任何帮助。 但是，直到每个用户都像您一样思考时，您的目标受众和用户才会有疑问。

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.

这个六点计划应该会有所帮助。 不仅如此，它还可以帮助您创建帮助信息，这些信息实际上可以帮助您确定产品UX所存在的问题，这些问题可以通过更好的设计得以改善(即使无法解决)。

Let’s see how.

让我们看看如何。

1.确定帮助页面的目的 (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.选择帮助页面将提供哪些用户操作 (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.

然而，很容易弄错这一点：决定创建一个FAQ页面并期望它可以满足用户的所有需求，或者只是列出电子邮件地址，并支付支持人员来回答可以更有效地回答的常见问题。一些常见问题。

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.确定每个用例中用户寻求帮助的要点 (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.

查看用户将在您的应用程序中执行的关键用例，页面流和操作，并列出他们将遇到的问题或在此过程中将面临的问题。 也许您已经在UX设计和开发过程中完成了此操作。 大。 重要的是要确定产品中需要帮助的地方，以及在这些时候有帮助的地方。

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.确定如何在每个断点提供帮助 (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.计划如何展示帮助，并创建和照顾它 (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.弄清楚如何判断它是否有效 (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.

它也不会给您提供可用于反馈以改进产品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.

您是否向产品用户提供自助服务？ 我很想听听您认为它在支持用户方面做得如何，以及您(和他们！)在评论中遇到的困难。

翻译自: https://www.sitepoint.com/6-step-plan-creating-genuinely-useful-product-support-pages/

vc6创建dll文件的步骤