知乎问答中的“赞同”和“感谢”有什么区别？是拙劣重复的设计方案，还是恰当周密的设计方案？
这几天我静下心来，仔细分析思考了一下，现在就来展示一下我的思考结果。
网上资料显示，第一个出现“赞同”和“感谢”设计方案的知名论坛是quora(知乎问答的对比产物，知乎问答中“赞同”和“感谢”的设计方案可能是持续的Quora设计)
上面的截图是Quora创始人查理·切沃对“赞同”和“感谢”的回应。白盒中的英文翻译如下:
一般来说，对一个答案的“赞同”表示“这个答案值得一看”；而“谢谢”的意思是“赞赏但不陈述答案的是非曲直”。
给出几个只是“感谢”而不是“同意/拒绝”答案的例子:
有些人解释了一个具体的问题，但你不确定这个答案是否恰当。你不认同一个主观谜题的答案，所以你不想给这个答案投票，但你欣赏他/她努力回应的勤奋。
另外，因为我在知乎问答“知乎问答”里查询了很多类似的功能，那么它们的适用条件是什么呢？”“赞同和感激的习惯有什么区别吗？为什么？“经过对难点问题的梳理，重点是以下三种‘只感谢不投票’的意见:
回答质量很高，但是因为涉及到专业能力，所以没有辨别对错的工作能力。答案本身不同意或部分不同意，但从答案中获得专业知识或启示，纯粹是出于文明礼貌或说话人的动机。
从上面的信息内容来看，似乎知乎问答的“关心”和“感谢”是两个不同的场景，“井水不犯河水”和“互相照顾”的功能是根据不同的用户需求。
但伴随着我点击查看的材料(具体来说:大量知乎问答用户对此事相关问题的回复)，我对身边大量特定用户(具体来说:身边应用知乎问答的朋友同事)进行了调查，反馈的信息内容如下:
“谢谢”功能从来没用过，不清楚和“同意”有什么区别。「感谢」是「赞美」的意思吗？“感谢”和“赞同”实际上并不容易区分。这时候你想点哪个就不容易担心这个关键点了。对于一些有专业知识或者启发性的回答，如果你没有既定的观点，你倾向于不去做所有的实际 *** 作。如果你觉得这个答案写得很好，你就会认同它。不容易担心答案真假，这也是相对的。“同意”回答也可以算作对创作者的间接感谢。对于好的答案，我只点“同意”，因为只有“同意”才会让答案上去。点击“同意”后，点击“谢谢”就不容易了。一般在邀请回答者作为邀请者回应后，会点击“谢谢”。作为路人翻看答案，总会点“同意”和“抵制”。……
经过近几天的仔细分析和思考，我得到的想法是，“赞同”和“感谢”确实是一个精心的设计方案，但也是一个“理性”的功能设计方案。如果这种“理性的”功能设计方案要被用户真正和实际意义上的普遍使用，它必须基于以下三个必要条件:
用户可以建立“赞同”和“感谢”的区别，即“赞同”和“感谢”在用户认知能力上有显著差异。它们适用于不同的情况，没有重叠的功能，清晰直观，易于理解。用户可以准确区分“赞同”和“感谢”，即在处理了“赞同”和“感谢”的认知问题后，还需要处理应用中的问题:用户可以凭借这种认知能力，在不同的“回答场景”中准确地进行恰当的实际 *** 作。用户想要区分“赞同”和“感谢”，就是在处理了功能认知能力和精准应用的问题之后，必须发自内心的接受。用户希望客观的看答案，看不同情况下的“赞同”和“感谢”。
要保证以上三个必要条件很容易，很难全部考虑。
在认知能力上，试图清除用户各种认知能力的惯性力，重新认识其功能是极其困难的(手机微信曾经在资讯页，拉下网页顶端，也就是开头拍短视频的“文化教育用户”就是一个不成功的例子)。
在应用方面，解决不同的“答案场景”，用户选择不同的匹配实际 *** 作，对用户来说是一种信息资源管理的压力，降低了阅读文章的效率。此外，还要处理“答案质量很高，但没有辨别对错的工作能力”、“我们不同意答案或其中的一部分，但从答案中获得专业知识或启示”等“复杂而常见”的问题。难道没有必要是技术类专业吗？专家一定是技术专业人士吗？如何定义一部分不赞成？如果90%同意，你投还是不投？所以，如果60%同意，你投还是不投？
从人性来说，用户不太可能一直保持“客观情况”，但在具有人群特征的社区环境中，更容易变得越来越理性和不理性。举个例子，一个用户从来不赞同或者完全赞同一个答案，但是很有可能答案中的某一句话、某一个表情或者某一张图片戳中了他/她的心态，用户很有可能立刻投了赞成票或者反对票。(必须指出，这并不是极少数用户的应用状态。想想最近你生气的那一幕。够客观吗？)
而且，用户“懒”。在泛娱乐的应用场景中，用户专注于内容本身，内容之外的功能变得更加复杂多样，用户的应用意向降低。(那么，用户有多懒呢？用户的懒登录，懒感谢，懒投票，甚至懒反馈“赞同”和“感谢”)有多混乱
商品方面，就知乎问答而言，“投票”和“感谢”两个功能并不是并列的功能，而是顺序和层次上的显著区别。(这也是为什么投票在答案的排列中起着关键作用，而致谢却不为人所知的原因。)如果序贯函数是独立的、分布的，并且应用于所有正常情况，那么感谢和认可之间的关系就像个人收集、评价和认可之间的关系一样和谐友好。
但是，当一个主功能被一个子功能危及，导致用户的困惑和用户个人行为的混乱，然后顺序功能在某种程度上“无效”的时候，那个设计方案是不是因小失大？
大家还记得知乎问答创始人黄继新在一次题为《社交时我们在做什么》的演讲中提到，社交网站要做两件事:一是最大化用户获得认可的机会，二是最小化用户向他人表示认可的门槛。
在我看来，知乎问答中“感谢”功能的设计方案的立足点可能是:最大化回答者被认可的机会，最小化访客展现回答者认可的门槛。
设计方案的立足点是好的，但是用户对功能的应用并不流畅。在分析了“同意”和“谢谢”功能设计的难点后，我思考了功能改进的方案。
我的推广思路很简单:把功能顺序说清楚。
方案一:取消答案显示网页中的“谢谢”功能，在邀请人回复回答者后，弱化为私下“谢谢”的消息提醒功能；另外，“投票”功能分为“赞成”和“抵制”，即将原来的“谢谢”部分换成“抵制”。那样，用户只需点击一次就可以“同意”或“抵制”答案，这使得“投票”功能的实际 *** 作比以前更加简单和直观。方案二:在答案展示页面，整合“感谢”和“评价”功能(参考微信朋友圈“赞”和“评价”的设计方案)，既保留“感谢”功能，又不危及“投票”功能的实际效果；(投票功能的推广与方案一相同)
是的，在知乎的问答中，“赞同”和“感谢”的功能设计方案也有类似的问题:
“反抗”和“不援助”两个功能，“私聊”和“公告”的设计方案是两个独立的控制模块，都是令人费解的功能设计方案。
后果
很可能有人会觉得是app的“小功能”，没什么好怕的。不同的功能设计方案没有太大区别，每个人都要掌握“方向”。但我认为，从一个商品的功能设计方案中，可以看出商品设计方案理念的点点滴滴。因为我确信好的功能都是经过深思熟虑的，众所周知的，简单实用的。
创作者:石头，微信公众平台:chanpinzhiyi
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）