作者：石头
全文共 2675 字，阅读需要 6 分钟
—— BEGIN ——
这几天，静下心来，认真分析思考了一番，现在将思考结果展示出来。
据网上资料，最早出现“赞同”与“感谢”设计的知名网站是：Quora（知乎的对标产品，知乎“赞同”与“感谢”的设计可能是延续quora的设计吧）
上方截图是Quora联合创始人查理·切沃对“赞同”与“感谢”的回答，红框里的英文翻译如下：
一般来说，“赞同”一个答案表示“这个答案值得一看”；而“感谢”是表示“欣赏但对答案好坏不作声明”。
举几个只是“感谢”但不对答案进行“赞同/反对”的例子：
同时，我也在知乎查看了诸多类似 “知乎的「赞同」和「感谢」功能，各在什么情况下使用才合适？” “你有没有区分赞同和感谢的习惯？为什么？” 等问题，归纳了一下，主要为以下三种“只感谢但不投票”的观点：
从以上的信息来看，似乎知乎的“点赞”与“感谢”，是两个适用不同场景，满足不同用户需求的“井水不犯河水”“各自安好”的功能。
但是，随着我查看更多的资料（特指：更多的知乎用户对此相关问题的回答），调研了更多身边的实际用户（特指：身边使用知乎的好友和同事们），反馈的信息有：
“感谢”功能从没用过，不知道和“赞同”有什么区别。“感谢”是“赞”的意思吗？
“感谢”和“赞同”不会具体去区分，当时想点哪个点哪个，不会去纠结这些细节。
对一些有知识或启发的答案，没有明确观点的话，倾向于不做任何操作。
觉得答案写的好，就会点赞同，不会纠结答案本身正伪，正伪本身也是相对的。
对答案“赞同”也算是对作者的一种间接感谢吧。
对好的答案，我只点“赞同”，因为只有“赞同”才会让答案顶上去，点完“赞同”，就不会再点“感谢”了。
一般是在作为邀请人去邀请答主回答后，会点“感谢”，作为路人翻看答案，只会点“赞同”与“反对”。
……
这几天经过仔细的分析与思考，我得出的想法是：
“赞同”与“感谢”确实是个细心的设计，但同时是个“理想化”的功能设计。
这个“理想化”的功能设计，要想真正意义上为用户所用的话，必须基于以下三个前提条件：
用户能明确区分“赞同”与“感谢”，即在用户认知层面，“赞同”与“感谢”是有明显区别的，是适用于不同场景的，是没有功能重叠部分的，是清楚直观易于理解的。
用户能准确区分“赞同”与“感谢”，即解决“赞同”与“感谢”的用户认知问题后，还需解决应用层面的问题：用户能凭借该认知，在不同“答案场景”下，能够准确的进行对应的正确操作。
用户愿意区分“赞同”与“感谢”，即解决功能认知与准确应用问题后，还需要用户发至内心的接纳，用户愿意在不同场景下用理性去对待答案，去对待“赞同”与“感谢”。
要做到以上三个前提条件谈何容易，满足其中任何一个前提条件都是困难的。
在认知层面，试图清零用户多种多样的认知惯性，完成对功能的重新认知，极其困难（微信之前在消息页，采用下拉页面顶部，即开始拍摄小视频，就是一个“教育用户”的失败案例）。
在应用层面，应对不同“答案场景”，用户采用不同的对应操作，对于用户来说，是一种信息处理的负担，降低阅读效率的同时，面对诸如 “答案质量高，但由于涉及专业性，无能力判别正伪” “对于答案本身不赞同或部分不赞同，但从该答案中获得知识或启发” 这种“复杂而常见”的场景时，用户又如何判别自己专业不专业呢？外行一定不专业吗？专家一定专业吗？部分不赞同又怎么界定呢？90%赞同的话，投不投票呢？那么，60%赞同的话，投不投票呢？
在人性层面，用户不可能一直保持“理性状态”，而在群体性质的社区环境下，更容易变得感性，冲动。比如：某个用户对某个答案的观点毫不赞同或完全赞同，但是可能答案中的某句话、某种表达方式或某张配图，戳中了他/她的情绪，该用户可能就直接投票赞同或反对了（需要说明的是，这不是极少数用户存在的使用情况，想想最近一次你发火的情景吧，发得够理性吗？）。
而且，用户是“懒”的，在碎片化的使用场景下，用户专注在内容本身，内容外的功能越是复杂多样，用户的使用意愿越是降低（那么，用户有多“懒”呢？用户“懒”得“登陆”，“懒”得“感谢”，“懒”得“投票”，甚至“懒”得反馈“赞同”与“感谢”是多么让他/她困惑）。
在产品层面，对于知乎来说，“投票”与“感谢”两个功能，并不是并列级别的功能，而是很明显的主次级别的差异。（这也是为什么“投票”对答案的排序起决定性作用，而“感谢”对排序没有影响力的原因）如果主次功能相互独立，使用正常的情况下，那么“感谢”与“赞同”的关系，就如同“收藏”“评论”与“赞同”的关系，和谐友好。
但是，当一个主功能被次功能影响了，让用户产生了混淆，导致用户行为的混乱，从而使主次功能在某种意义上来说“失效”了，那么这样的设计是否是得不偿失呢？
还记得知乎联合创始人黄继新，在一席上的一次名为《社交时我们在干什么》的演讲中提到：
社会化网站主要干两件事，一件是尽可能增加用户获得认可的机会，一件是尽可能降低用户给他人提供认可的门槛。
我想，知乎的“感谢”这个功能的设计出发点可能是：尽可能增加答主获得认可的机会，且尽可能降低浏览者给答主提供认可的门槛。
设计出发点是好的，但是用户对功能的使用并不是顺畅的。分析完“赞同”与“感谢”功能设计的问题，我也思考了功能优化的方案。
我的优化思路很简单：让功能主次分明。
方案一：
在答案展示页面，取消“感谢”功能，弱化为一个邀请人在答主回答后，私下“感谢”的消息提示功能；同时将“投票”功能，拆分为“赞同”与“反对”，即用“反对”替代原“感谢”的位置。这样，用户对答案进行“赞同”或“反对”，只需要一次点击即可，使“投票”功能的操作比原先更为简洁而直观。
方案二：
在答案展示页面，将“感谢”与“评论”进行功能整合（参照微信朋友圈的“赞”与“评论”的设计），达到保留“感谢”功能，同时不影响到“投票”功能的效果；（投票功能的优化，与方案一相同）
对了，在知乎里，与“赞同”与“感谢”的功能设计存在类似问题的有：
“反对”和“没有帮助”这两个功能，“私信”和“通知”设计为两个独立模块，这些同样都是令人困惑的功能设计。
可能有些人会觉得这是app的“小功能”，没什么好纠结，不同的功能设计差别不大，我们更应该把握的是“大方向”。
但是，在我看来，从一个产品的功能设计，足以看出该产品的设计思想的点滴。我也坚信好的功能是深思熟虑的，不言自明的，简洁易用的。
—— END ——
作者：石头，微信公众号：产品志异（chanpinzhiyi）
本文由 @石头 原创发布于人人都是产品经理。未经许可，禁止转载
