微信扫码登录

其他登录方式

绑定手机号

注册

我同意用户协议

忘记密码

用户协议

绑定手机号

近期有不法分子打着爱盈利的旗号,制作“爱盈利”名称的App,并伪造爱盈利证件,骗取用户信任,以抖音点赞赚钱或其他方式赚钱为名义,过程中以升级会员获得高佣金为名让用户充值。
爱盈利公司郑重声明:我司没有研发或运营过任何名为“爱盈利”的APP,我司做任务赚钱类产品从没有让任何普通用户充值升级会员。我公司产品均在本网站可查询,请将网站拉至底部,点击“关于我们”可查看爱盈利相关产品与服务。
温馨提示:当遇到此类问题请拨打官方电话或添加官方微信,以免财产损失。爱盈利官网地址:www.aiyingli.com。
  • 推广与合作
X

知乎的“赞同”与“感谢”,这两个功能有什么区别?

来源: 2894

知乎的“赞同”与“感谢”,这两个功能有什么区别?是个糟糕而重复的设计,还是一个巧妙而细心的设计呢?

知乎的“赞同”与“感谢”,这两个功能有什么区别?

这几天,静下心来,认真分析思考了一番,现在将思考结果展示出来。

据网上资料,最早出现“赞同”与“感谢”设计的知名网站是:Quora(知乎的对标产品,知乎“赞同”与“感谢”的设计可能是延续quora的设计吧)

知乎的“赞同”与“感谢”,这两个功能有什么区别?

上方截图是Quora联合创始人查理·切沃对“赞同”与“感谢”的回答,红框里的英文翻译如下:

一般来说,“赞同”一个答案表示“这个答案值得一看”;而“感谢”是表示“欣赏但对答案好坏不作声明”。

举几个只是“感谢”但不对答案进行“赞同/反对”的例子:

有人解答了某个实际问题,但你不确定答案是否正确。你不赞同一个偏主观的问题的答案,所以你不想为这个答案投票,但是你欣赏他/她尝试回答的努力。

同时,我也在知乎查看了诸多类似 “知乎的「赞同」和「感谢」功能,各在什么情况下使用才合适?” “你有没有区分赞同和感谢的习惯?为什么?” 等问题,归纳了一下,主要为以下三种“只感谢但不投票”的观点:

答案质量高,但由于涉及专业性,无能力判别正伪。对于答案本身不赞同或部分不赞同,但从该答案中获得知识或启发纯粹是出于礼貌或对答主的鼓励。

从以上的信息来看,似乎知乎的“点赞”与“感谢”,是两个适用不同场景,满足不同用户需求的“井水不犯河水”“各自安好”的功能。

但是,随着我查看更多的资料(特指:更多的知乎用户对此相关问题的回答),调研了更多身边的实际用户(特指:身边使用知乎的好友和同事们),反馈的信息有:

“感谢”功能从没用过,不知道和“赞同”有什么区别。“感谢”是“赞”的意思吗?“感谢”和“赞同”不会具体去区分,当时想点哪个点哪个,不会去纠结这些细节。对一些有知识或启发的答案,没有明确观点的话,倾向于不做任何操作。觉得答案写的好,就会点赞同,不会纠结答案本身正伪,正伪本身也是相对的。对答案“赞同”也算是对作者的一种间接感谢吧。对好的答案,我只点“赞同”,因为只有“赞同”才会让答案顶上去,点完“赞同”,就不会再点“感谢”了。一般是在作为邀请人去邀请答主回答后,会点“感谢”,作为路人翻看答案,只会点“赞同”与“反对”。……

这几天经过仔细的分析与思考,我得出的想法是,“赞同”与“感谢”确实是个细心的设计,但同时是个“理想化”的功能设计。这个“理想化”的功能设计,要想真正意义上为用户所用的话,必须基于以下三个前提条件:

用户能明确区分“赞同”与“感谢”,即在用户认知层面,“赞同”与“感谢”是有明显区别的,是适用于不同场景的,是没有功能重叠部分的,是清楚直观易于理解的。用户能准确区分“赞同”与“感谢”,即解决“赞同”与“感谢”的用户认知问题后,还需解决应用层面的问题:用户能凭借该认知,在不同“答案场景”下,能够准确的进行对应的正确操作。用户愿意区分“赞同”与“感谢”,即解决功能认知与准确应用问题后,还需要用户发至内心的接纳,用户愿意在不同场景下用理性去对待答案,去对待“赞同”与“感谢”。

要做到以上三个前提条件谈何容易,满足其中任何一个前提条件都是困难的。

在认知层面,试图清零用户多种多样的认知惯性,完成对功能的重新认知,极其困难(微信之前在消息页,采用下拉页面顶部,即开始拍摄小视频,就是一个“教育用户”的失败案例)

在应用层面,应对不同“答案场景”,用户采用不同的对应操作,对于用户来说,是一种信息处理的负担,降低阅读效率的同时,面对诸如 “答案质量高,但由于涉及专业性,无能力判别正伪” “对于答案本身不赞同或部分不赞同,但从该答案中获得知识或启发” 这种“复杂而常见”的场景时,用户又如何判别自己专业不专业呢?外行一定不专业吗?专家一定专业吗?部分不赞同又怎么界定呢?90%赞同的话,投不投票呢?那么,60%赞同的话,投不投票呢?

在人性层面,用户不可能一直保持“理性状态”,而在群体性质的社区环境下,更容易变得感性,冲动。比如:某个用户对某个答案的观点毫不赞同或完全赞同,但是可能答案中的某句话、某种表达方式或某张配图,戳中了他/她的情绪,该用户可能就直接投票赞同或反对了。(需要说明的是,这不是极少数用户存在的使用情况,想想最近一次你发火的情景吧,发得够理性吗?)

而且,用户是“懒”的,在碎片化的使用场景下,用户专注在内容本身,内容外的功能越是复杂多样,用户的使用意愿越是降低。(那么,用户有多“懒”呢?用户“懒”得“登陆”,“懒”得“感谢”,“懒”得“投票”,甚至“懒”得反馈“赞同”与“感谢”是多么让他/她困惑。)

在产品层面,对于知乎来说,“投票”与“感谢”两个功能,并不是并列级别的功能,而是很明显的主次级别的差异。(这也是为什么“投票”对答案的排序起决定性作用,而“感谢”对排序没有影响力的原因)如果主次功能相互独立,使用正常的情况下,那么“感谢”与“赞同”的关系,就如同“收藏”“评论”与“赞同”的关系,和谐友好。

但是,当一个主功能被次功能影响了,让用户产生了混淆,导致用户行为的混乱,从而使主次功能在某种意义上来说“失效”了,那么这样的设计是否是得不偿失呢?

还记得知乎联合创始人黄继新,在一席上的一次名为《社交时我们在干什么》的演讲中提到:社会化网站主要干两件事,一件是尽可能增加用户获得认可的机会,一件是尽可能降低用户给他人提供认可的门槛。

我想,知乎的“感谢”这个功能的设计出发点可能是:尽可能增加答主获得认可的机会,且尽可能降低浏览者给答主提供认可的门槛。

设计出发点是好的,但是用户对功能的使用并不是顺畅的。分析完“赞同”与“感谢”功能设计的问题,我也思考了功能优化的方案。

我的优化思路很简单:让功能主次分明。

方案一:在答案展示页面,取消“感谢”功能,弱化为一个邀请人在答主回答后,私下“感谢”的消息提示功能;同时将“投票”功能,拆分为“赞同”与“反对”,即用“反对”替代原“感谢”的位置。这样,用户对答案进行“赞同”或“反对”,只需要一次点击即可,使“投票”功能的操作比原先更为简洁而直观。方案二:在答案展示页面,将“感谢”与“评论”进行功能整合(参照微信朋友圈的“赞”与“评论”的设计),达到保留“感谢”功能,同时不影响到“投票”功能的效果;(投票功能的优化,与方案一相同)

对了,在知乎里,与“赞同”与“感谢”的功能设计存在类似问题的有:

“反对”和“没有帮助”这两个功能,“私信”和“通知”设计为两个独立模块,这些同样都是令人困惑的功能设计。

后记

可能有些人会觉得这是app的“小功能”,没什么好纠结,不同的功能设计差别不大,我们更应该把握的是“大方向”。但是,在我看来,从一个产品的功能设计,足以看出该产品的设计思想的点滴。我也坚信好的功能是深思熟虑的,不言自明的,简洁易用的。

作者:石头,微信公众号:产品志异(chanpinzhiyi)


爱盈利(aiyingli.com)移动互联网最具影响力的盈利指导网站。定位于服务移动互联网创业者,移动盈利指导。我们的目标是让盈利目标清晰可见!降低门槛,让缺乏经验、资金有限的个人和团队获得经验和机会,提高热情,激发产品。

评论

相关文章推荐

SELECT dw_posts.ID,dw_posts.post_title,dw_posts.post_content FROM dw_posts INNER JOIN dw_term_relationships ON (dw_posts.ID = dw_term_relationships.object_id) WHERE 1=1 AND(dw_term_relationships.term_taxonomy_id = 412 ) AND dw_posts.post_type = 'post' AND (dw_posts.post_status = 'publish') GROUP BY dw_posts.ID ORDER BY RAND() LIMIT 0, 6

京ICP备15063977号-2 © 2012-2018 aiyingli.com. All Rights Reserved. 京公网安备 11010102003938号