出自UXGuide.net

帮助

Help

目录 1 这样的用户界面是否正确？ 2 Design concepts 2.1 An analogy for Help 2.2 Designing UI so that Help is unnecessary 2.3 Considering user motivation 2.4 Writing content for scanning 2.5 Creating content that matters 2.6 Writing compelling Help link text 3 Usage patterns 4 Guidelines 4.1 Entry points 4.2 Content 4.3 Icons 5 Text

“帮助系统”由多种类型的内容组成，用于在用户无法完成任务、想更清楚地理解某个概念、或需要比 UI 中可用的更多的技术支持时协助用户。

在本文中，我们将帮助视为对 UI 的辅助。UI 是主要的，因为那是用户首先尝试解决其问题的地方。他们只会在无法依赖 UI 完成任务时才会查阅帮助系统。

Windows® 帮助与支持首页，可通过开始菜单访问。

注：与风格和语气相关的设计规范请参考各自相应的章节。

这样的用户界面是否正确？

考虑下列问题以进行判断：

• 你的目标用户的积极性如何？他们寻找你程序的功能和成为中级甚至高级用户的积极性越高，他们愿意通过查阅帮助主题来寻求他们问题答案的意愿就越强烈。
• 你是否在使用帮助来修补不好的用户界面？你的 UI 越好，用户越是不需要寻求额外的帮助。如果你的程序拥有非常清晰、帮助性强的主 UI（例如不含行话的错误信息、编写良好的向导及没有二义性的对话框），你可能就根本不需要辅助的帮助系统。
• 你的程序是否比较简单？如果是，考虑将那些必须的辅助内容合并到主 UI 界面上。用户更愿意在执行复杂任务的程序中寻找额外的帮助。
• 你的应用程序是否是为了开发人员、IT 专业人员或其他软件专家而设计的？这些用户往往期望编程语言约定的参考帮助，以及关于功能技巧的深入的概念帮助。

Design concepts

If you decide to include Help in your program, integrate it into your overall design. The Help interface should be simple, efficient, and relevant; it should enable users to get help easily and then return to their task. Think of your Help system in terms of users' time: minimize disruption first by anticipating where they will encounter problems in your program, then solving those problems by incorporating fundamental assistance directly into your UI, and creating clear and consistent entry points into your more detailed Help.

Windows Vista® assistance was designed according to these principles. Here are some of the design changes to the Windows Vista Help user experience:

• More discoverable entry points to Help from the primary UI (especially new Help links from UI surfaces such as dialog boxes, error messages, and wizards). Help links take you directly to the pertinent topic in Help.
• A Help button icon is available in the upper-right corner of most Control Panel hub pages, as well as shell folders.
• Users can choose to get the most up-to-date Help content from Windows Online Help and Support when they're online.
• Help topics are now task-based rather than feature-focused, so that users can accomplish their tasks quickly and efficiently.
• Help topics are now largely based on known top user scenarios.
• Help topics have a more relaxed and informal tone, using real-world language.
• Help topics are designed for effective scanning, as users rarely read the content word-for-word.

An analogy for Help

To think in greater depth about designing your Help system, consider an analogy from everyday life. You are lost in an unfamiliar city. What do you do? Many would react like this:

1. Get oriented; look for landmarks, street signs (names and pointers to places).
2. Look for maps.
3. Finally, as a last resort, ask for directions or call a friend.

The design of the city's "interface" affects your need for assistance. Well-labeled streets, explicit directions (pointers to hospitals, airports, museums, and the post office), and clear landmarks such as prominent geographical features or buildings help you find your way.

You ask for help as a last resort. It's an indication that the city's "interface" has failed by being poorly designed and confusing. You are more likely to ask for help in place that has a specific label that suggests helpfulness. For example, you are more likely to ask for help in a place labeled "Directions" or "Information" than a general place like the City Hall—even though just about anyone at City Hall could give you directions.

When you ask for help, chances are you are frustrated and just want to get to your intended destination. You probably aren't in the mood to spend time taking a tour of the city or learning about its history. Further, your motivation depends on the importance of the task. If you are trying to find your hotel room, you will do whatever it takes. However, if your goal is to find a place of minor importance, most likely you will just give up after a modest effort.

All of these aspects of finding your way in real space correspond to how users typically find their way in the virtual space of your program. Seeking help beyond the primary UI is by its very nature disorienting; do your best to mitigate such an experience by well-designed UI and intelligent "street signs" to direct users to the answers they need.

Designing UI so that Help is unnecessary

Try to make Help unnecessary in the first place, by:

• Making common tasks easy to discover and perform.
• Providing clear main instructions.
• Providing clear, concise control labels that are goal- and task-oriented.
• Providing supplemental instructions and explanations where needed.
• Anticipating avoidable problems by using controls constrained to valid choices, providing suitable default values, handling all input formats, and preventing errors.
• Writing error messages that provide a clear solution or action for the user to take.
• Avoiding confusing UI designs, such as tasks with poor flow or using controls that are disabled for no apparent reason.
• Working with writers and editors early in the development cycle to create high-quality, consistent UI text throughout your program.

Users shouldn't have to go somewhere else to figure out how to use your UI. Add essential information directly into the primary UI, rather than forcing users out of their immediate context and into the Help pane. If important information exists only in a Help topic, there's a good chance that users won't see it. For information that is optional and more explanatory, use Help links from the primary UI to the relevant Help topic for supplemental assistance.

Considering user motivation

For most users, speed and efficiency are among the paramount virtues of good programs. Users want to get their work done. Generally, they are not interested in learning about the program and the technology for its own sake; their patience extends only insofar as that program serves their own interests and solves problems at hand.

Design your Help system to match your users' motivation. For example, consider a user who has strolled up to a kiosk at a museum. If she cannot figure out how to perform the task quickly, she is likely just to give up and walk away. She is unlikely to spend time using Help. Alternatively, a highly-motivated user has a higher tolerance for time spent researching your Help system for answers. A business user who must balance the books, for example, is probably willing to consult Help content to get the most out of that new accounting application.

Writing content for scanning

Write Help topics knowing that they will be scanned for specific information, not read word-for-word. Write concisely, getting to the point quickly, and providing information that users can act on.

• Write "how-to" topics using numbered steps in a consistent format so that users recognize they are getting procedural assistance.
• Write reference topics with ease-of-scanning in mind, using tables, for example, to present UI options or language syntax.
• Write conceptual topics that are logically organized by subheadings, so that the user can skip whole sections of lesser interest.

In all Help content, it is easier to scan bulleted lists than standard paragraph blocks of text; use bullet lists judiciously, though, not as a crutch for unorganized material.

Creating content that matters

Given that no Help system can anticipate every question that every user might have, focus most of the content on answering the top questions in the top scenarios for your target users. For example, effective searching and how to establish network connectivity (among other tasks) may be highly sought-after topics. Also, focus on tasks within your top user scenarios, rather than documenting a feature or technology exhaustively for its own sake.

Tip: Technical support is a good source for Help content. Help desks often keep records of frequently asked questions about particular programs or tasks that users are trying (and failing) to accomplish.

It isn't necessary to provide help for every feature in the UI. Quite often, unhelpful Help results from trying to create Help for everything. If the UI is well designed, most of these Help topics won't be very helpful; they will just restate the obvious.

If there is more than one way to perform a task, in most cases you can just document the most common way used by inexperienced users. Exceptions to this include accessibility considerations (documenting keyboard equivalents of mouse actions, for example), and platform considerations (documenting for the tablet form factor, for example, or for server environments in which the command line can substitute for the graphical user interface).

Remember that users often don't think of the problems they are encountering in exactly the same terms as you do. For example, users may find it strange to think of themselves as an "account." Be sure to design your search and indexing functionality, then, to account for likely terminology variations and synonyms.

Between the primary UI and the Help system, though, terms should be very similar if not identical. Users can be confused when the Help system language doesn't correlate very closely to what they are seeing on the screen.

Writing compelling Help link text

When you link to a Help topic from your primary UI, be sure to write compelling Help link text. Clear and specific language inspires confidence. Users tend to believe that generic Help links (a button with the word "Help" or "Learn more" on it) will not lead to the right information without a significant investment of time.

If you do only five things...

1. Design your UI so that users don't need Help.
2. Make your Help helpful by focusing the content on the top questions in the top scenarios for your target users.
3. Present the Help content so that it is easy to scan.
4. Understand that you don't have to provide help for every feature in the UI.
5. Make the Help entry points discoverable and compelling.

Usage patterns

Different kinds of content serve different purposes.

Procedural Help Provides the steps for carrying out a task.	Procedural Help should focus on "how" information rather than "what" or "why." In this example, the Help topic describes how to use a feature of the Disk Cleanup utility, providing steps to follow in sequence.
Conceptual Help Provides background information, feature overviews, or processes.	Conceptual Help should provide "what" or "why" information beyond that needed to complete a task. In this example, the Help topic defines what the desktop is, and provides additional detail about what it contains and why users interact with it.
Reference Help Serves as an online reference book.	You can use reference Help to document a programming language or programming interfaces. In this example, the Help topic lists typographic conventions in use for this particular language or application, providing the information in an easy-to-scan table.

Guidelines

Entry points

• 应当链接到具体的、相关的帮助主题。不要链接到帮助首页、目录、搜索结果列表或只是链接到其他页的页面。避免链接到包含一大堆常见问题列表的页面，因为这会强迫用户搜索与其单击的链接相对应的内容。不链接到具体的帮助主题对于手头的任务来说没有帮助。绝不要链接到空白页。
• 不要为了保持统一而在每个窗口或页面上都放置帮助链接。在一处提供帮助链接并不意味着你需要在每处都提供它。
• Use Help links for dialog boxes, error messages, wizards, and property sheets. If the Help link applies to specific controls, place it under them, left-aligned. If the Help link applies to the entire window, place it at the bottom left corner of the window's content area.

In this example, the second Help link applies to a group of controls.

In this example, the Help link applies to the entire window.

• Use Help links instead of textual references to Help whenever technically possible.

Correct:

How can I repair disk errors?

Incorrect:

For more information about repairing disk errors, see Help and Support.

• Use a Help button with the Help icon for the hub pages of control panel items. Place it in the upper-right corner. These buttons don't have a label, but have a tooltip that reads Help.

A control panel item with a Help button.

• F1 Help is optional. F1 Help displays a window that contains contextual Help information.
• Programs with menu bars can have a Help menu category. For Help menu guidelines, see Menus.

In this example, the Windows Paint accessory has a Help menu category.

• For keyboard accessibility, provide tab stops for Help buttons and links.
• Help button and link behavior should be as follows: Help pane opens and a dedicated Help topic is displayed; the UI that invoked the Help pane should remain open to preserve the contextual experience.
• Don't use the following obsolete Help entry point styles. Although they have been used in the past, usability studies have determined that users tend to ignore them. Use links to specific Help topics instead.

Incorrect:

Don't use "Learn more" or "Learn more about..." links.

Incorrect:

Don't use generic Help buttons.

Incorrect:

Don't use context-sensitive Help buttons on the title bar.

Content

• Don't create obvious content. Help topics that repeat what is in the primary UI don't add value.
• Don't create content that the user can't act on in some way.
  • Exception: Some conceptual content delivers important background information without necessarily leading to user action.
• Avoid vague resolutions to problems. For example, "contact your system administrator" or "reinstall the application" tend to frustrate users.
  • Exception: Recommend contacting the system administrator if that is the only practical solution, and system administrators expect to be contacted for the problem.
• Avoid content that addresses highly unlikely user scenarios. Develop your main Help content for what you anticipate will be normal usage; note important exceptions to expected usage, but treat this content as a lower priority.
• Gather feedback from your users about how helpful your Help topics are. Allow users to rate individual topics. Conduct usability studies on your documentation to ascertain problems involving quality and discoverability of content.
  • Tip: User feedback is also a great way to generate more task-based content, focused on what users are actually doing with your program, as opposed to feature-based content, focused simply on a description of the technology.
• Provide multiple ways of accessing your content. A table of contents, an index, and a search mechanism are three of the most common methods of improving discoverability.
• If there is more than one way to perform a task, in most cases you can just document the most common way used by inexperienced users.

Icons

• Use the Help icon only for Explorer windows and the hub pages of control panel items. Don't use the Help icon with Help links.

Correct:

In this example, a Windows Explorer window uses a Help icon to provide access to Help.

Incorrect:

In this example, the Help icon on the lower-left is used incorrectly with a Help link.

Text

Help links

• Provide specific information about the content of the Help topic, using as much relevant, concise text as necessary. Users often ignore generic Help links. Make sure the results of the link are predictable—users shouldn't be surprised by the results.
  • Exception: You can use "More information" to supplement instructions that are directly in the UI, especially if providing specific information in the Help link leads to unnecessary repetition or makes the link less compelling.

Incorrect:

A strong password has at least six mixed-case letters, numbers, and symbols. What is a strong password?

Correct:

A strong password has at least six mixed-case letters, numbers, and symbols. More information

In the incorrect example, the Help link is repetitive. It asks a question that is really already answered.

• 尽可能将帮助内容所回答的主要问题用作帮助链接文本。不要使用“Learn more about（了解更多）”的措辞。

Incorrect:

Learn more about adding exceptions

Correct:

What are the risks of allowing exceptions?

How do I add exceptions?

In the correct examples, the link is phrased in terms of the primary question answered by the Help topic.

• If the most relevant information can be summarized succinctly, put the summary directly in the UI instead of using a Help link. However, you can use a Help link to provide supplemental information.

Incorrect:

Correct:

Better:

The correct example summarizes the Help information succinctly, greatly improving the likelihood that users will read it. The better example provides a Help link for more information on this complex subject.

• Phrase Help links to clearly indicate assistance. Help links should never read like action links.
• Use the entire Help link for the link text, not just the keywords.

Correct:

What are the risks of allowing exceptions?

Incorrect:

What are the risks of allowing exceptions?

In the correct example, the entire Help link sentence is used for the link text.

• • Exception: Help links to external Web sites should simply use the name of the site or page as the link. Any text introducing the name of the site need not be included in the link itself.
• Help links don't have to match Help topic headings exactly, but there should be a strong and obvious connection between the two. Design links and headings in pairs for this reason.

Correct:

How can I improve the performance of this feature? (link text)

Configuring this feature for optimal performance (topic heading)

Incorrect:

How can I improve the performance of this feature? (link text)

Complete overview of this feature (topic heading)

In the incorrect example, the Help topic heading substantially differs in scope from the Help link text, and could be disorienting.

• 如果帮助内容是在线的，应当在链接文本中表达清楚。这么做使链接的结果能够被预期到。

Correct:

For additional formats and tools, go to the Microsoft Web site.

Incorrect:

Where can I find additional formats and tools?

• 使用完整的句子。
• 除了问号以外，不要使用句末标点或省略号。
• Don't use ellipses for Help links or commands.

Help content

• Format UI elements using bold to make them easy to identify. This is especially useful for procedural Help topics, allowing users to scan through procedures and quickly see pertinent UI elements.
• Format captions using italic. This applies to tables, art, screenshots, and other graphic elements that benefit from brief textual explanation.
• Refer to Help simply as Help. Generally, don't use the phrase online Help unless you are in fact referring to content on your Web site.