上一篇文章里刚说过设计师不要拘泥于设计细节,这次就要讨论一个设计细节问题了,好像有点打脸= =
Anyway, 今天想要讨论的是知乎的“赞同”和“感谢”功能。
首先整理一下“赞同”、“感谢”以及对应的“反对”和“没有帮助”这四个功能的定义。总体说来,设计者的思路是这样的:
赞同:我和答主的观点一致。 <-> 反对:我和答主的观点相反。
感谢:我从答主的回答中学到了新东西。 <-> 没有帮助:我认为答主的回答离题了。
其中,只有“赞同”数量会影响该回答的排序。(理论上反对应该也能,但是没找到数据支撑)
我不认为普通用户能准确了解这两组功能的区别并做出对应的操作。它是个过于复杂,over engineering,貌似精确但是难以执行的度量体系。
为什么这么说?我们先看网页版本的界面:
“赞同”部分的交互流程:
如果没有仔细留意数字变化的话,很有可能认为第一次点击带有数字的按钮就直接点赞了,然而并不是!第一次点击只是展开点赞/反对功能而已,需要二次点击才能选择具体功能。
“感谢”部分的交互流程:
只有“感谢”/“取消感谢”两种状态,且不显示“感谢”的人数。用户只能看到自己是否已经“感谢”了该回答。
需要注意的是,对于答主来说,不管别人是“赞同”还是“感谢”了你的回答,你都会收到通知。而对于读者来说,只有你“赞同”了的回答会出现在公开时间线上,而“感谢”并不会。
(这真是一个复杂的逻辑体系……)
再来看APP版本的界面设计↓
“感谢”按钮明显被放在了更醒目、更易点击的位置。虽然没有用户数据,但是可以推断在APP上点“感谢”的用户比例肯定多于网页端。
此外,“赞同”的交互方式也和WEB端略有差异,可以推断APP上“赞同”操作的错误率低于网页端(在网页端,第一次点击是展开点赞/反对功能而不执行点赞操作,容易被误判为直接点赞)
但是无论如何,需要靠两次点击才能完成“点赞”操作,这个交互过程过于繁琐。(只是点个赞而已,搞那么复杂干什么…)
并且,在这个交互过程中,很多数据并没有反馈给用户(点“反对”的人数、点“感谢”的人数、点“没有帮助”的人数)。虽然是否知道这些数据好像不会很影响使用体验,但是用户为什么要去点一个不知道点了会怎样的按钮?
综上所述,我觉得更好的解决方案是这样子的:
WEB版↓
APP版↓
结尾吐槽:
- 知乎网页和APP的蓝色调是不一样的!明显饱和度不同。
- 点击“感谢”后,网页端的按钮文字变成“取消感谢”,而APP变成“已感谢”
- 最新版的知乎APP logo从方的变成了圆的,这特么是为啥?
可以加个微信吗,好想和你聊聊,马上大四工设学生一枚