是否需要让用户“知其所以然”？
1、在证券公司的时候，因为设计的工作不忙，我一度论文撰写产品说明书的角色。
那个时候总是想要很明白的给阅读者讲清楚“我们这个地方是怎么设计的，为什么要这么设计，背后的逻辑是什么”，然后再给他们示例“应该怎么怎么做”。一个产品说明书写下来好几百页，自己都能看的晕过去。
我写的很累，那些操作员也很不爽我。因为他们需要跳过我很多的长篇大论，直接选择性的去看“应该怎么怎么做”。
2、隽辰说：“有效的沟通，就是有效的帮助”，我并不完全赞成。
我赞成他说的用户和设计者之间存在“心智差异”。这就像机器和人之间存在的差异一样。所以有了交互设计存在的价值。
但他说要“告诉用户，我是怎样以及为什么要这么设计”，我不赞成。因为很多设计可能逻辑很复杂，要讲清楚十分的难，我们不能要求用户和设计者的“心智”达到一致。只能要求设计者去更加接近用户的“心智”。
3、隽辰举例“在Google的帮助中心里面，每一项Q&A，最后都会有一句“以上信息对您有帮助吗？”用于统计和改进帮助的内容”。这是一个很好的例子，但这个例子并不是为了“让用户更加接近设计者的心智”，而恰恰是为了“让设计者更加了解和接近用户的心智，从而可以更准确直接的解决问题”。
4、首先我们必须说“用户使用一个产品的目的是什么？”。“解决问题”。对，是“解决问题”，并非“了解你的产品是如何设计的”。
从这个角度来说，我们首先需要做的是“帮助用户解决问题”，当他们出现问题有疑问的时候我们首先要说的是“应该怎么样”、“可以怎么样”，让他“知其然”。而非告诉他们“因为什么，又因为什么，所以你应该怎么样”。
往往我们只需要让他们“知其然”，无须“知其所以然”。
5、可以说“有效的沟通，就是有效的帮助”，但这并非最可取的帮助。也许正是因为很多设计者急于或者过于担心用户不能“知其所以然”，过于替用户着想，才会让我们经常看到很多产品上有类似的问题出现：
1>某网站不允许用户名重复，用户注册输入的用户名被占用时，提示：“因为我们将用户名作为唯一的身份标识，所以不允许用户帐户重复。您的输入的用户名已被占用，请重新设定”。
2>中移动经常给用户发送12580、139免费邮箱、冲值卡充值抽大奖等垃圾广告，投诉者要求取消这些垃圾短信时，客服说（大意）：“对不起先生，因为我们的客服中心和技术中心不在同一个部门，没有权限修改您的设置，你的如果希望不再接受我们中移动发给您的垃圾短信必须发短信SBYD到10086才能取消。”
3>…
上面的例子都是让我很不爽的，因为过于啰嗦，我并没有时间和耐心去看/听那么多的解释，也没有兴趣去了解产品是怎么设计的。更需要的是“直接告诉我如何解决问题”。可以这样调整：
1>“用户名已被占用，请重新设定”
2>“对不起先生，如果您希望不再接受我们中移动发给您的垃圾短信，可以发短信SBYD到10086取消。”
6、呵呵，看到这里也许你会说“上面中移动那个问题，一般的投诉者都会继续问‘为什么你们不能直接给我取消？发的时候怎么可以直接给我发呢！’。 那个时候客服不是还得再解释‘因为我们不是一个部门，没有权限’吗？”
没错，大部分投诉的人基本上都会继续去问。 但这个时候再解释具体原因，去问的人就不会因为话多而烦，只可能因为原因是瞎编的而烦。（臭骂一顿说你不会发短信，他们其实他们可以直接给你取消了。）
7、所以，在有些时候我们只需要让用户“该怎么做”，无须让他们“为什么得这么做”；而当问题稍微复杂或者用户“更错成本”不低的时候，我们需要先让用户“知道为什么得这么做”，预备一套让用户“知道为什么得这么做”的方案。
但，就算需要让用户“知道为什么得这么做”也并非等于“告诉用户我们是怎么设计的”，更不等于一上来就直接告诉他“知道为什么得这么做”。因为用户可能永远都不需要知道怎么设计的，而且也也不一定能理解设计师的“心智逻辑”。
4月 11th, 2008 at 13:02
帮助是为用户而写 用户就是大众 大众需要的是 1\怎么用 出了问题 2\怎么办
使用流程 一般问题足以
设计理念 设计要求… 似乎不管大众的关系
需要长篇大论?
4月 11th, 2008 at 13:04
易懂、简洁、教会用户会使用是根本~~~
4月 11th, 2008 at 15:02
收藏至20ju.com
4月 11th, 2008 at 15:16
对于用户心理的研究与揣摩是我们做产品设计的人一个长期的课题。白鸦这种分析问题的方法层次分明，很令人敬佩，值得学习！
4月 11th, 2008 at 16:25
哈哈，非常精辟，浅显易懂，白鸦的做法我也亲身试过，客户直接翻到最后一页，，前面十几页完全浪费，，结果后来过了很久，我自己再来看，真的太复杂了，自己看自己的东西都看晕了。看了不到两页，就想直接翻到最后一页了
4月 11th, 2008 at 16:43
很受启发。现在写的交互看来是考虑得太多了，太啰嗦了。
其实发生异常时，使用者知道出现异常了，就不管了——先放下一阵，然后再来。异常的细节是给维护人看的。
是这样吗？
4月 12th, 2008 at 14:35
用户主要是使用设计者提供的功能,而不是需要设计者提供怎么做出这个功能的
犹如国外玩具商,在设计一款新的产品时都会选择一群儿童进行评价而不需要招集一些设计师来作出评价.关键在于,产品是给用户用的,是给儿童用的,而不是设计师自己用的.
4月 12th, 2008 at 15:19
有些时候说明的东西越多，用户越是迷糊，不如选其中的重点，让用户可以正常使用就ok了。
4月 13th, 2008 at 9:05
嗯 白鸦这种思维和junchen刚好有点相反，我比较赞同。
应该是设计师反过来接近用户的心智，了解用户的想法，因为理论上大部分用户是不会去关心设计师为什么要这样设计的，而是第一感觉：这样设计我使用起来得不到“帮助”
4月 14th, 2008 at 15:14
赞同这一种观点。
公司有很多同学在写PRD和帮助文档的时候，老是喜欢写我这样做有多好多好，我为什么要这么做。
其实不管是PRD还是帮助文档，它们都只需要告诉读这份文档的人做什么，怎么做。
不同的只在于PRD是告诉读者应该做什么，应该怎么做；而帮助文档是告诉读者可以做什么，应该怎么做。
回到帮助文档的问题上来。
结合自己公司的例子。由于自己公司的用户都是低年龄、低文化层次和低收入的人群，与其你费劲心机让他们的思想跟你达到同一个高度，以期望他们能理解你一个细微末节的功能的设置是多么的人性多么的为他们考虑，还不如直接告诉他们这个功能怎么用。
4月 15th, 2008 at 14:50
[…] 2、UCDChina这期的话题是如何设计有效的帮助，各位前辈都提出了相当精辟的见解。 尤其是Junchen的帮助是什么以及白鸦的是否需要让用户“知其所以然”？。直接从帮助的根本需求来讨论这个问题，相当发人深思。 […]
4月 16th, 2008 at 22:21
逻辑性强，分希的不错
4月 22nd, 2008 at 9:04
写两份比较好
5月 1st, 2008 at 0:54
就是在这个中间状态 有些人想进入专家状态 但是又不想付出太多
这个时候告诉他们怎么做 只会让他们再一次问你怎么做
如果告诉他们为什么这么做 结果就是你看到的 太烦
我一般的情况是 如果第一次尝试完全没头绪 先扔着不管 以后再深入
因为各种东西之间或多或少都是有联系了 当相关的基础十分熟悉的情况下 会有突然就学会的感觉
5月 1st, 2008 at 1:06
这个时候告诉他们怎么做 只会让他们再一次问你怎么做
有太多太多的细节他们不想付出脑细胞去思考 而这些细节又是不得不面对的
5月 24th, 2011 at 9:09
[…] 2、UCDChina三月份的话题是如何设计有效的帮助，几位前辈都提出了相当有意思的见解。 尤其是Junchen的《帮助是什么》以及白鸦的《是否需要让用户“知其所以然”？》直接触发了我写文的欲望。 […]
10月 27th, 2011 at 11:16
[…] 是否需要让用户“知其所以然” http://ucdchina.com/blog/?p=420 […]