帮助 - UCD大社区

在帮助目标的上下文环境中显示帮助信息

novanewlife — 2009-03-13 09:38:16

在“产品说明书的最佳位置 ”一文中，我谈到了说明书放在物体的附近能够帮助人们方便地找到。在这篇文章中，我们来看类似的出现在软件产品帮助系统中的设计问题：在帮助目标的上下文环境中显示帮助信息。

比如说，当我们在填一张表格时，如果对于表格上的某些字段不理解，此时我们非常希望找到一个熟悉表格的人，当我们指着表格上的某个字段问他时，他能够向我们进行解释。

在Windows环境中，很多对话框右上角的问号按钮就是用于这个目的的。当用户对于对话框上的某个字段不了解时，可以先点一下这个按钮，然后在不理解的字段上点击一下，此时帮助信息就会以一个小弹出窗口的形式显示出来。用户在阅读帮助信息的时候仍然能够看到对话框的内容。

随着网络的普及，在一些网页的设计中具有类似的设计：每个字段的旁边会有一个很小的问号按钮。如果用户不理解这个字段的含义，他可以直接点击这个按钮，帮助信息就会在附近显示出来。

实际上，在上下文环境中显示帮助信息可以采取非常灵活的形式。以下是两个例子：

1. 对于配置文件中的各种参数的帮助信息

很多的软件具有 ini 或 xml 格式的配置文件，用户可以通过修改相应的参数来对软件的行为进行调整。当然，不是每个参数的含义都是那么容易理解的。你固然可以在软件的帮助文档中对每个参数的含义进行解释，不过用户在编辑该配置文件时仍需要首先打开帮助文件，然后在其中找到相关的参数。根据以上提到的设计思想，我们完全可以在这些配置文件中嵌入帮助信息，使得用户在编辑这些文件时可以直接看到帮助信息。具体的常见做法是，在帮助参数的上一行或下一行用注释的方式来对该参数的含义以及如何设置进行说明：

例如：

//file_format determine the format of the output file, it can one of the following values: xml, html, txt, word, excel

file_format=xml

2. 在自动生成的代码中以注释的方式告诉用户如何继续开发

现在很多的开发工具都能够帮助自动生成代码框架，然后程序员需要在这个生成的框架里填入真正的业务逻辑代码。此时，开发工具可以直接在生成的代码中以注释的方式告诉用户应该如何填入自己的逻辑。

例如，很多生成的框架代码都是生成了一个从基类集成的类，然后用户需要在生成的子类中重载的函数中编写自己的代码。在这种情况下，自动生成代码时可以在这些重载了的函数头或函数体内部以注释方式告诉用户应当如何重载这个函数，例如各个参数是什么含义，应当如何设置函数返回值。

相关话题：帮助源地址：http://blog.sina.com.cn/s/blog_4caba12a0100cjbq.html

“帮助”其实无处不在....

稻草 — 2008-08-01 12:21:06

UCDchina书友会第七期，南京聚会
本期话题：怎样设计“帮助”更有效？
下午早到了一会，出去走走，空气真好，建议各位坐在电脑前的"居室"们都出去走动走动。
与振之和家彦扯了一会，人陆续到场
15：00正式开场，这次书友会很热闹，有近20人，mm的队伍不断壮大....

也许是受到junchen先前blog的影响。产生了某种思维定式，大家的讨论基本是围绕着
> 文档型帮助
> 情景式帮助
> 演示型帮助

当然也有更多的延伸：
比如
> 交互型帮助: 在线机器人,在线客服等等；
> 贡献型帮助: 如百度知道,　网站调整最多的问题到首页等等。
......

每位同学说的都很有其道理，受益颇多...

下面谈谈自己的小感想，由于自身公司产品的原因，在谈及帮助的时候会更发散的将产品分成
> 传统型产品
> 创新型产品

涉及到的帮助更多的是一种无形的帮助。

> 传统型产品：
在设计此类产品时更多的会去遵循用户的某种旧习惯，
比如windows播放器的使用习惯，qq的使用习惯等等。
因为这些都是用户熟悉的，可更好的切入，节约成本，高效。

> 创新型产品：
是创新的，肯定是用户没有见过或用过的产品
用户会带着某些疑问去使用。
1．使用你的产品能完成什么任务？(第一印象：你的产品是做什么的?)
2．如何完成 ( 怎么用？)
3．….

创新型的产品介绍如何做好？

1. 记得跟鸦总曾聊过，他推荐说,Apple的一系列的产品的视频宣传广告，其实本身就是在教你如何使用iphone、ipod…..
2. 淘宝最近的某电视广告，也是在告诉你，淘宝能做什么，怎么买东西，怎么保障利益……
3 .Tony前些时候也由sina某视频联系到了rss的普及性

当然形式不一定非得是视频，因为对成本以及规模当然也会有所限制.

用户在使用某产品，某功能时，大部分情况下还是会先用一下，而不是会去先看帮助。
如何更好的在用户使用过程中，良性的引导，去完成这个任务，达到目的。
相信是需要更多思考的.
换句话说：优秀的设计其实就是最好的帮助

__________________________________________________

可能太过于发散了
说说有趣的吧

在我们的生活中遇到困难时，更多的是还是会向周围的人寻找帮助.。
都说“有困难找警察。”
当然警察叔叔的精力也是有限的...

中国移动推出的12580，一按我帮您
其实是一种非常生活化的交互式帮助，
我刚刚打了一下，一段小广告后，就是人工服务，很直接，很有效。
当然别提恶搞的问题。
baidu ，sogou也同样推出了语音搜索服务。

也许某天在做产品的时候，会在某处放一按钮，“遇到问题了么? 点我吧”，当然这玩意得很智能

“帮助”其实无处不在....

相关话题：帮助源地址：http://www.v4uu.com/blog/article.asp?id=473

怎样设计“帮助”更有效

CC — 2008-07-30 00:16:29

今天参加UCD书友会时讨论的话题，满有意思的。只不过在讨论的时候，一直在接受信息，自己的想法倒是变地模糊起来，很难阐述。说到这里，觉得这个题目的设计也少许有点问题。我们在讨论“更”的时候，应该有变量和定量。今天讨论的太多变量，在那么多变量下，是无法说哪个“更有效”的，如果换个话题，如“怎么设计‘注册帮助’更有效”，大家讨论的基质一样，那我们的讨论可能也能够更有效。至少我不会开始变地模糊。

OK，说回帮助的话题，我简单整理下自己的思路。

产品及需要“帮助”的内容：

电子商务类：关键步骤当然在于“怎么选东西”，“怎么付费”，要帮助用户顺利地去走一个购买流程。

WEB 2.0类：不是很熟悉所谓的WEB 2.0，但总的说来，感觉上很像是用户从某种方面成为了雇员，因为是用户在无形中创造的内容。那么这个，就是要帮用户怎么去创造内容。

软件类：软件的范围很广了，初级地说，至少要帮助用户理解哪个东西是干什么用的。至于怎么去用，就属于技巧类的知识，不该出现在软件帮助中。

帮助的分类形式：

提示类帮助：比较被动接受信息。在过程中起到提示作用，好像旁边做了一个人，你做一个动作，他说一句这个怎么怎么。

归档类帮助：比较主动去寻找信息。主要在于建立一个“知识库”，帮助手册。让用户有地可寻。

帮助的表现形式：

文字：比较适合解释概念性问题。

图片：比较适合解释操作性问题。

视屏：同“图片”，比较适合解释操作性问题，及流程性问题。

用类似于“百度知道”的解决方案来设计“帮助”，有点混淆了我们要讨论的主旨。如果发生一个在百度知道上面有个人提问“怎么使用百度知道？”的情况，真的是有点让人失笑。我个人认为“百度知道”也是一个WEB 2.0产品，如果要搭建一个都是由用户上传问题，用户解答，那么势必也必须设计一个“帮助”，至少要让用户知道怎么去提问，怎么去回答。

结合帮助表现形式，也就是说，“文字帮助”帮助用户了解这个产品是干什么的，以及告诉用户某些规则。“图片帮助”或者“视屏帮助”就可以帮助用户顺利地走一个创造内容的过程。

“提示类帮助”和“归档类帮助”的相互结合，则变为了一个网站构架问题，那些分散在知识库外的TIPS如何于集中在知识库内的详细帮助相结合，表达内容统一，结构合理。

进一步上升到用户细分，如何判断哪些用户需要“提示类帮助”，如何判断用户需要的帮助内容，如何方便高级用户撤销“提示类帮助”。

或者再一步细化到网站界面，“提示类帮助”怎么出现，“归档类帮助”如何分类及设计帮助导航。

所以，几种结合，缺一不可。只是如何组合这些元素，则需要在产品需求上进行详细设计。

啊列…… 好像说了半天等于啥都没说…… 随便从哪个点延伸一下，举几个例子，没准又能出好多篇东西…… HOHO…… 真是篇概念性的随笔啊……

相关话题：帮助源地址：http://www.ccinfospace.com/?p=78

帮助的乌托邦

lytous — 2008-07-27 17:19:12

最近在学习几个CG新软件，按常规先看看帮助，刚好UCD团伙正在讨论这个问题，我也想说几句。有人说：“最好的产品设计就是没有帮助”，部分认同，但是那不一定是最好的产品，充其量可以算是简单有效的产品，就像我们不能说“最漂亮的衣服就是没有衣服”……. 有设计必然就会有问题，帮助的形式，特征，发展同样如此，我们慢慢来看：

首先，在我做一些分析之前，我要认同帮助的实用性和必要性，因为我估计下面的一些文字会引起软件和品牌捍卫者的不满，所以先拉个近乎：

1.为啥要帮助？
首先，你是一个一清二白的用户，你要使用某种工具，软件，服务之前，需要有一个概念的认识和功能的确定，帮助给你两个答案：a.该产品（这里的产品包括：网站，软件，手机，互联网服务等，以下统称产品）是干嘛的；b.如何使用该产品；

其次，详细了解产品的每个细节特征与结构，因为产品是多种功能的组合，正确的组合方式将有效提高使用效率；

最后，帮助本身是一本工具书手册，在遗忘产品功能点的时候给予提示，并且对产品版本负责。

2.帮助的真实含义
HELP的含义有“帮助，促进，办法”的意思，延伸开来，刚好是UCD设计思想中的一个阶段发展：提示 - 明确 - 反馈 - 改进 - 提升。

帮助分为有效的和无效的，有效帮助可以降低难度，节省时间，减少负担，提高效率；无效的帮助只能让人感到累赘，多余，无聊甚至讨厌。

比如：你看到一位女士想搬很重的东西上楼，你过去微笑并友好的表示要帮助她搬，这马上让你形象加分，而且很和谐（当然也有尴尬情况，我后面说）

或者：你在厕所里面，很多人一起方便，完事后，你对旁边的哥们说，来，我帮你冲洗。。。。。（当然，这很极端，但是实际上某种产品中出现的情况比这还糟）

因此，帮助的准确定义是： 在不影响被帮助者隐私和心理接受范围内，运用有效形式提供最多的服务，以协助被帮助者达到某个目标。

3.帮助的形式由什么决定？
形式由性质确定，网站的帮助有可能是一个交互式的指引页面，软件的帮助有可能是一个“智能精灵”，手机的帮助有可能仅仅是一个提示音，商场中的购物帮助有可能是一个真正的导购员。。。。。。

无论你采用何种形式，帮助必须在时间，地点，方式，载体，有效范围等诸多心理和生理因素的共同协调下完成。否则，“帮助”本身会演变成扯犊子，或者不靠谱，我不是在说相声，我们来看看实际情况中发生了什么。

4.关于帮助的疑惑
* 这里列举一些常见的例子，或者我个人经历过的帮助的问题，供下面的建议解决方案参考，我不提及产品的名称，但是细心的朋友肯定都知道 *

a.很多软件产品中，“帮助”选项都是放在菜单最后的，无可厚非，但是为什么快捷键一般设置为F1呢？仅仅是因为windows这么做么？windows 做得更多，它还支持alt+h。。。如果按照键盘的布局来映射到屏幕，F12显然更准确。。。（这点上还需要更多讨论，但我坚持F1不是最好的）

b.我不清楚很多的产品里面，为什么“帮助”中还要加入关于，向导，更新，赞助，链接，甚至是广告；

c.满心欢喜的打开帮助，搜索栏中键入内容，最后得到的结果是“该项没有记录，未找到”，这就像上面的“搬东西”的例子，你过去帮助女士的同时发现那个东西自己也搬不动；

d.产品提供的搜索居然是文档内搜索，而不是基于互联网的；

e.某些产品的帮助提示，弹出的popup居然遮挡了1/3个屏幕；

f.没有给用户提供专家级模式（屏蔽帮助提示和无用信息）的选择；

g.帮助设计过于结构化，没有针对低，中，高级用户的自定义；

h.大部分产品的帮助无法卸载……同时帮助文件大得惊人（同样的情况出现在语言包中）

5.帮助的乌托邦
个人认为的“理想”帮助方案，仅供参考：

a.智能分析技术
系统自动记录你的操作方式（历史），将常用的功能默认为“熟悉型使用”，在帮助档案中将它们的位置向后调整，着重突出没有使用过或很少使用的功能；

b.搜索绑定
对搜索内容进行相关字段绑定，比如：你搜索“modeling”，自动绑定到建模方式的内容，并提供建模相关的工具解释和要点提示，而不是出现一个modeling的全文识别，让用户自己去区分；

c.即时提醒
这个功能现在只做到了status部分的提示和popup关键字提醒，出现错误和操作不清晰的提示却很少，这点上maya做得比较好，但是即时分析库不够强大；

d.人工服务
无论是什么产品，只要是商用环境下的，应该在计算机帮助方式以外，额外提供人工服务和技术支持。当然，前提是你购买的产品是正版；

e.语言
对应系统和平台语言，自动搜索语言包，并进行替换，同时留出用户自定义的空间；

f.组织性
帮助更多的不是依赖于打包的PDF，而是沟通交流的p2p互助方式，开放一个新闻组或者爱好者圈子，提供线上交流；

g.更新
拜托每次新产品发布的时候即时更新你们的帮助库文件和服务热线；

h.多媒体
21世纪了，我们的帮助系统是不是可以来点语音和视频结合的方式？PDF虽然详细，但始终不直观，而且太累。（已经有一些新兴的产品开始这么做）

先说这些，未必全面，仅作为自己从一个用户角度出发，希望拥有的帮助形式，如果产品的设计者们尽快达到这些可用性要求，用户将十分欣慰。

相关话题：帮助源地址：http://ucdchina.com/blog/?p=421

是否需要让用户“知其所以然”？

白鸦 — 2008-07-27 17:18:20

1、在证券公司的时候，因为设计的工作不忙，我一度论文撰写产品说明书的角色。
那个时候总是想要很明白的给阅读者讲清楚“我们这个地方是怎么设计的，为什么要这么设计，背后的逻辑是什么”，然后再给他们示例“应该怎么怎么做”。一个产品说明书写下来好几百页，自己都能看的晕过去。
我写的很累，那些操作员也很不爽我。因为他们需要跳过我很多的长篇大论，直接选择性的去看“应该怎么怎么做”。

2、隽辰说：“有效的沟通，就是有效的帮助”，我并不完全赞成。
我赞成他说的用户和设计者之间存在“心智差异”。这就像机器和人之间存在的差异一样。所以有了交互设计存在的价值。
但他说要“告诉用户，我是怎样以及为什么要这么设计”，我不赞成。因为很多设计可能逻辑很复杂，要讲清楚十分的难，我们不能要求用户和设计者的“心智”达到一致。只能要求设计者去更加接近用户的“心智”。

3、隽辰举例“在Google的帮助中心里面，每一项Q&A，最后都会有一句“以上信息对您有帮助吗？”用于统计和改进帮助的内容”。这是一个很好的例子，但这个例子并不是为了“让用户更加接近设计者的心智”，而恰恰是为了“让设计者更加了解和接近用户的心智，从而可以更准确直接的解决问题”。

4、首先我们必须说“用户使用一个产品的目的是什么？”。“解决问题”。对，是“解决问题”，并非“了解你的产品是如何设计的”。
从这个角度来说，我们首先需要做的是“帮助用户解决问题”，当他们出现问题有疑问的时候我们首先要说的是“应该怎么样”、“可以怎么样”，让他“知其然”。而非告诉他们“因为什么，又因为什么，所以你应该怎么样”。
往往我们只需要让他们“知其然”，无须“知其所以然”。

5、可以说“有效的沟通，就是有效的帮助”，但这并非最可取的帮助。也许正是因为很多设计者急于或者过于担心用户不能“知其所以然”，过于替用户着想，才会让我们经常看到很多产品上有类似的问题出现：
1>某网站不允许用户名重复，用户注册输入的用户名被占用时，提示：“因为我们将用户名作为唯一的身份标识，所以不允许用户帐户重复。您的输入的用户名已被占用，请重新设定”。
2>中移动经常给用户发送12580、139免费邮箱、冲值卡充值抽大奖等垃圾广告，投诉者要求取消这些垃圾短信时，客服说（大意）：“对不起先生，因为我们的客服中心和技术中心不在同一个部门，没有权限修改您的设置，你的如果希望不再接受我们中移动发给您的垃圾短信必须发短信SBYD到 10086才能取消。”
3>…

上面的例子都是让我很不爽的，因为过于啰嗦，我并没有时间和耐心去看/听那么多的解释，也没有兴趣去了解产品是怎么设计的。更需要的是“直接告诉我如何解决问题”。可以这样调整：
1>“用户名已被占用，请重新设定”
2>“对不起先生，如果您希望不再接受我们中移动发给您的垃圾短信，可以发短信SBYD到10086取消。”

6、呵呵，看到这里也许你会说“上面中移动那个问题，一般的投诉者都会继续问‘为什么你们不能直接给我取消？发的时候怎么可以直接给我发呢！’。那个时候客服不是还得再解释‘因为我们不是一个部门，没有权限’吗？”
没错，大部分投诉的人基本上都会继续去问。但这个时候再解释具体原因，去问的人就不会因为话多而烦，只可能因为原因是瞎编的而烦。（臭骂一顿说你不会发短信，他们其实他们可以直接给你取消了。）

7、所以，在有些时候我们只需要让用户“该怎么做”，无须让他们“为什么得这么做”；而当问题稍微复杂或者用户“更错成本”不低的时候，我们需要先让用户“知道为什么得这么做”，预备一套让用户“知道为什么得这么做”的方案。
但，就算需要让用户“知道为什么得这么做”也并非等于“告诉用户我们是怎么设计的”，更不等于一上来就直接告诉他“知道为什么得这么做”。因为用户可能永远都不需要知道怎么设计的，而且也也不一定能理解设计师的“心智逻辑”。

相关话题：帮助源地址：http://ucdchina.com/blog/?p=420

帮助是什么

JunChen — 2008-07-27 17:16:35

耶和华说：“看哪，他们成为一样的人民，都是一样的言语，如今既作起这事来，以后他们所作的事就没有不成就的了。我们下去，在那里变乱他们的口音，使他们的言语彼此不通”——创世纪 11:6-7

我觉得有时候把概念扩大化对问题的理解并没有益处。比如说帮助，从广义的去讲，很有可能我们会把导航也说成是帮助，把整个网站都说成是帮助你也不能说它错。于是讨论导航的时候，会说：瞧，其实整个网站就是一个导航。（比如我之前写的“导航设计与信息架构”好像是陷入了这个怪圈）

所以我在写本文的时候，想搞清楚帮助到底是什么。如果连帮助是什么都不知道，那还谈什么设计有效的帮助呢？

因为在书友会之前我写了一篇关于帮助的文章，里面提到了编程语言的帮助手册。自然而然的去思考为何编程语言需要学习并且需要帮助手册呢？因为计算机的“语言”和人是不一样的，同时设计这个编程语言的人，和你的语言也不一样。所以就让我想到了文章开头的巴别塔的故事。

语言的差异，文字的差异，再延伸到文化、环境的差异。最后归结到对于设计影响最大的因素：心智模型。

忽然想到这个问题：如果你为自己设计一个产品，是否需帮助？不需要，因为你设计的就是你想的。

这个问题的答案让我震惊和兴奋。似乎终于抓住了什么。

我脑海中不断涌现出日常设计过程中用户提的问题：“为什么会这样…”、“为什么不是这样…”、“为什么不可以…”，我听到自己的声音默默地回答：“因为…”、“因为…”、“因为…”。

为什么我不写这个用户常问的问题：“怎样…”，因为他心里其实在问“为什么不可以…”。

原来帮助就是我告诉他们为什么。而这个为什么的存在，就是因为心智差异。

于是我得出了这样的结论：帮助是由于设计师与用户的心智差异而存在的一种沟通，因为心智差异不可避免，所以必然会有这样一种沟通。这种沟通，可以说是告诉用户，我是怎样以及为什么要这么设计。

我们不是要设计有效的帮助吗？因为帮助是一种沟通，所以设计有效的帮助等于进行有效的沟通。

余世维写过一本书叫做《有效沟通》，在里面可以学到很多东西。举一个例子：沟通的双向性。

在Google的帮助中心里面，每一项Q&A，最后都会有一句“以上信息对您有帮助吗？”用于统计和改进帮助的内容。这就是沟通的双向性。

融会贯通，一通百通。

文档、情景、演示，都是一种沟通形式。我还曾提到关于帮助的渠道问题，不就正是沟通的渠道吗？

有效的沟通，就是有效的帮助。

相关话题：帮助源地址：http://ucdchina.com/blog/?p=419

对帮助的三点想法

Tony — 2008-07-27 17:14:49

流氓帮助
罗永浩老师在说到暂*住*证的时候描述了这样一个情景：国家将收容制度更名叫做帮助制度。
警察在马路上抓住一个民工问：有没有暂住证？
民工说：没有。
警察：那跟我走一趟。
民工：哦不，我不用帮助。
警察：我～帮～你！

在很多的设计中，我们处处也能见到这样的“流氓帮助”、“强迫式帮助”。
记得当初office还是什么软件有个设计，在我刚刚要使用的时候，蹦出个“猴子”问：“你知道吗？XXXXXX。”不关闭就不让你继续！
犯这个错误的原因是设计师将所有需求理解成一样了，认为所有人在这里都有困难而需要帮助。在确定提供帮助之前最好先拆分需求。

首页是网站最大也是第一次帮助
不管抵达网站的哪个部分，首页都是用户对网站的第一印象：
1 主导航。看一个网站的主导航，用户将进一步了解这是什么类型的网站，有没有兴趣。
比如豆瓣9点，“二套”、“三套”“四套”…非常“CCTV”的导航，是个好创意，却是个烂设计，我至今没有记得每个套下面具体是什么类型的文章。这个导航对于新手来说呢？
很多网站都喜欢与众不同，个性化，但千万别高估了用户的理解力。

2 内容。将用户最感兴趣的内容以“干货”的形式呈现出来，越直接、越纯粹越好。
我们经常能看到有些网站在首页有简短的“使用教程”。或者文字，或者图示，或者视频。与其教用户怎么用，还不如先告诉用户使用之后能得到什么。优秀的内容（信息）是对用户最直接的引导和帮助。
不管是传统的门户，还是BBS，虽然他们的内容产生的机制是不一样的(编辑产生和用户产生)，但对于用户来说，他们不关心内容产生的过程，而是内容好还是不好。

不要瞧不起“帮助页面”
很多设计师有个可爱的幻觉：你看，用户用手机，MP3都不用帮助就能快速上手，根本不用任何“帮助”。所以就认为有一个“帮助中心”就是不优秀的设计。虽然都是设计，但这个例子举得不是非常地恰当，鼠标的操作屏幕是二维+单纯视觉效果，而物理介质产品的设计是三维+身体各种知觉效果，得到的反馈都是不一样的，不适合类比。
百度知道不就是中文互联网中的“帮助中心”吗？再看看百度的帮助页面和google的帮助页面，很显然，他们的产品都以实用、简洁著称，你使用的过程中不需要读它们也能用起来，那么我们来看看帮助页面的作用吧：

1 在北京的讨论中，有个朋友说到，帮助页面就好像“字典”，需要帮助的人自己会去查，干扰最小。对于中级用户往高级用户转化有很大的帮助。
2 帮助页面能让用户得到一个网站功能和服务的全貌展示，如果你没有看过百度的帮助，去看完之后一定会有收获的。
3 官方的一种解释，标准答案。
4 很多的概念和高级操作不得不放到帮助页面中去。谁打开photoshop不需要任何帮助自动上手的？photoshop软件设计不合理吗？
5 提供给一些特殊的用户。看看百度帮助中心最下方的内容，很多人都很关心SEO，觉得很神秘，如果仔细去读完“百度与站长”，相信对SEO会有新的认识。

设计师应该尽量让用户少去找帮助页面，这没有错，但帮助页面的设计，是你整个产品“帮助体系”不可或缺的一部分，需要认真对待。

相关话题：帮助源地址：http://ucdchina.com/blog/?p=416

你的用户需要什么样的帮助？

Angela — 2008-07-27 17:13:05

前几天我一个朋友突然问我：“怎么删掉iPod里存的歌曲啊？”据我所知，他买了iPod已经有半年多了，所以这时候冒出这样的问题让我很惊讶：“难道半年了你都没有删过歌吗？”他毫不为奇地说：“我刚刚才想要删歌，以前一直用得好好的。”

终其一生，有些用户可能永远用不到一些产品的功能，也永远不知道有这些功能的存在。这样的用户，我们称为新手用户──或许称为“新手状态”更准确。

与之相反的，是一些对产品功能、以及功能之间的规则甚至是运作原理都了然于胸的用户，这些用户闭着眼睛也知道点了“下一步”会弹出什么样的对话窗，有什么办法让能系统自动处理事情。这样的用户，我们称为专家用户──嗯，我还是倾向于称其为一种状态：“专家状态”。

那么，在新手和专家之间，还有一种状态，它介于前两者之间，具体表现就是，用户对自己经常用的功能很熟悉，但不一定了解规则；知道还有哪些功能，但如果不是需要的话，基本上想不起要用它们。同时，明明知道有更便捷的方法，仍然固执地用自己的方式来处理事情。这种状态，称为“中间状态”。

这就是交互设计大师Alan Cooper对从技术层面对用户下的定义。同时，另一个定义是，一般情况下，绝大多数用户都处于“中间状态”。

为什么一开始要啰嗦大家都知道的结论？因为只有知道你的用户是什么状态，你才能知道提供什么样的帮助才是最有效的。盲目提供帮助，要么是隔靴搔痒，要么是填鸭式教育。

本期书友会的话题是“如何有效地设计帮助？”──我参加了北京的讨论，基本上大家的观点很相似：

第一、用户不会主动去寻找帮助，只有在遇到问题时才会需要帮助；
第二、好的设计能在一定程度上减少寻求帮助的机率。

我个人也同意这些结论，但是想结合用户状态补充一下：用户最需要帮助的时候是从非用户向新手、从新手向中间状态、从中间状态向专家转化的时候。

对于一个第一次使用产品的“全新”用户，你需要做的是用最明确的方式把产品最关键的功能展示出来。IPod的包装盒里，有一张和真机一模一样的卡片，一样的界面、一样的大小，然后在卡片上用文字标明哪个键是播放，哪个键是下一首。这几乎是一个指导初次使用者上手的最佳帮助例子。

而对于一个新手，他们最需要的是植入到操作过程中的小提示，以帮助了解下一步有可能出现的状况，这种帮助形式现在已经应用得越来越普遍了，我觉得可以称之为“情景帮助”。与此同时，帮助还应该有意识地强化产品的概念模型或运作模式。之前我那个朋友的例子，在大半年的使用过程中，他显然没有明白 iPod和iTunes之间的运作模式，也许Apple应该考虑一下将iPod和iTune之间的通讯改为双向同步：P。

从用户角度来看，以上两个状态都是暂时的。也就是说，从非用户到新手，从新手再到中间用户，这种转化很快。因而对帮助的要求就是：直观、准确。直观意味着尽量少使用文字，多使用图示；准确意味着在正确的时候给出最关键的帮助。过多的文字和复杂的描述，只会把用户吓跑。“展示20%，让用户自己找到剩下的80%”，虽然有点夸张，但这个思路我是非常赞同的。

那么产品强大的功能什么时候展示给用户最合适呢？我认为是在用户使用产品一段时间并形成操作习惯以后。比如在Excel中，当你连续在几个单元输入文字后，它会问：“你似乎在管理一个列表，需要使用管理器吗？”，然后紧接着一个按钮提示你可以“了解更多”关于列表管理器的用法。就这样，一个长期处于 “中间状态”的用户，在不断被引导去探索产品的过程中，变成了一个专家用户：）。

中间状态应该是用户和产品之间相对比较稳定的状态，这时候提供给用户的帮助，可以采用更加“啰嗦”的形式，较多的文字、详细的解释甚至示例、检索……这正是展现产品内在魅力的大好时候。

不管用户处在哪种状态，帮助都应该以一种“润物细无声”的方式默默地支持用户：只在需要时出现，绝不打扰正常的工作流程。

现在互联网应用越来越多，有些在软件或硬件设计中常用的方式可能不适用（比如纸制的真机卡片），功能实现起来可能需要更高的代价（比如记录用户操作）……因而我们不得不做出很多妥协。对于这种情况，我有一个简单的原则：了解你要设计的那个界面（页面）的用户比例。当然这个原则是建立在“每一个页面都是一个任务点”的基础上的。满足了这个基础，你就可以分析这个页面的主要使用者是一群处于哪种状态的人，重点去考虑这类人所需要的帮助。

举一个通用的例子：注册和登录。我常常看到有的网站为了省事，把注册登录做到一个页面里，其实注册和登录很明显是针对两类不同的用户群，不管是从用户还是网站的角度，对它们都有着截然不同的需求。

从用户来讲，使用注册的都是新用户，他们需要在第一时间了解“为什么需要注册，注册有什么好处，网站的特点是什么”，功能上你需要告诉他“账号和密码命名规则，某些注册项的作用”等等；而使用登录的都是老用户，他们需要了解的是“最近有什么新活动、增加了什么新功能、发布了哪些新信息”等等。

从网站来讲，注册页面极有可能是“着陆页”，国外有文献称为Landing page，那么这个页面需要延续上一个页面的信息；另一方面，对于注册和登录的数据也需要分别记录，两个页面分开，能为统计分析节省不少的工作量。

UCD的核心就在于，不管你做什么决定，首先考虑的是用户需求。帮助也是同样，针对不同的需求提供不同的帮助，不但能解决问题，还能避免引来更多的麻烦。这是一个“贴心”的产品设计师应该具有的意识。

相关话题：帮助源地址：http://ucdchina.com/blog/?p=413