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

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

 

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

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

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

 

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

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

 

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

 

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

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

 

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

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

 

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

（这真是一个复杂的逻辑体系……）

 

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

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

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

 

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

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

 

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

WEB版↓

 

APP版↓

 

结尾吐槽：

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