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

 

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

 

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

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

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

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

 

帮助的分类形式：

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

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

 

帮助的表现形式：

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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