知乎的“赞同”和“感谢”

上一篇文章里刚说过设计师不要拘泥于设计细节,这次就要讨论一个设计细节问题了,好像有点打脸= =

Anyway, 今天想要讨论的是知乎的“赞同”和“感谢”功能。

 

首先整理一下“赞同”、“感谢”以及对应的“反对”和“没有帮助”这四个功能的定义。总体说来,设计者的思路是这样的:

赞同:我和答主的观点一致。          <->   反对:我和答主的观点相反。

感谢:我从答主的回答中学到了新东西。   <->   没有帮助:我认为答主的回答离题了。

 

其中,只有“赞同”数量会影响该回答的排序。(理论上反对应该也能,但是没找到数据支撑)

我不认为普通用户能准确了解这两组功能的区别并做出对应的操作。它是个过于复杂,over engineering,貌似精确但是难以执行的度量体系。

 

为什么这么说?我们先看网页版本的界面:

Untitled-1-02

 

“赞同”部分的交互流程:

Untitled-1-03 如果没有仔细留意数字变化的话,很有可能认为第一次点击带有数字的按钮就直接点赞了,然而并不是!第一次点击只是展开点赞/反对功能而已,需要二次点击才能选择具体功能。

 

“感谢”部分的交互流程:

Untitled-1-04

只有“感谢”/“取消感谢”两种状态,且不显示“感谢”的人数。用户只能看到自己是否已经“感谢”了该回答。

 

需要注意的是,对于答主来说,不管别人是“赞同”还是“感谢”了你的回答,你都会收到通知。而对于读者来说,只有你“赞同”了的回答会出现在公开时间线上,而“感谢”并不会。

(这真是一个复杂的逻辑体系……)

 

再来看APP版本的界面设计↓

Untitled-1-06

“感谢”按钮明显被放在了更醒目、更易点击的位置。虽然没有用户数据,但是可以推断在APP上点“感谢”的用户比例肯定多于网页端。

此外,“赞同”的交互方式也和WEB端略有差异,可以推断APP上“赞同”操作的错误率低于网页端(在网页端,第一次点击是展开点赞/反对功能而不执行点赞操作,容易被误判为直接点赞)

Untitled-1-05

 

但是无论如何,需要靠两次点击才能完成“点赞”操作,这个交互过程过于繁琐。(只是点个赞而已,搞那么复杂干什么…)

并且,在这个交互过程中,很多数据并没有反馈给用户(点“反对”的人数、点“感谢”的人数、点“没有帮助”的人数)。虽然是否知道这些数据好像不会很影响使用体验,但是用户为什么要去点一个不知道点了会怎样的按钮?

 

综上所述,我觉得更好的解决方案是这样子的:

WEB版↓

MyDesign-07

 

APP版↓

MyDesign-08

 

结尾吐槽:

  1. 知乎网页和APP的蓝色调是不一样的!明显饱和度不同。
  2. 点击“感谢”后,网页端的按钮文字变成“取消感谢”,而APP变成“已感谢”
  3. 最新版的知乎APP logo从方的变成了圆的,这特么是为啥?

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注