找回密码
 立即注册
查看: 36|回复: 0

从两个交互细节,学抖音的设计策略

[复制链接]

9400

主题

0

回帖

2万

积分

论坛元老

积分
28208
发表于 2024-3-1 12:53:02 | 显示全部楼层 |阅读模式
产品在面向用户时,要做好功能的更新迭代,以更好地契合用户体验与实际场景下的用户需求。在本篇文章里,作者便针对抖音的评论「不喜欢」、点赞推荐功能进行了交互拆解,并测验考试 做了重设计计划 ,一起来看看吧。

抖音已是世界级的短视频流播放平台,岂论 TIKTOK还是抖音,它所面向的巨量用户及普遍 的用户特征,都要求抖音需要坚持 高频次的更新迭代,以完善灵活的设计策略和机制。
今次简要剖析抖音中近期新增的两个我小我 比较喜欢的功能:评论「不喜欢」、点赞推荐,以窥见抖音的交互与业务设计策略。
一、评论「不喜欢」
在聊评论区之前,弗成 避免地要聊到社区气氛 和治理。
社区气氛 对任何内容社区类平台来说都属于老年夜 难,评论区的气氛 劣质水平 往往与DAU呈正比,这一点在抖音、哔哩哔哩、微博等过亿级社区平台表示 得更为明显,这和平台的年夜 用户量以及弗成 避免的用户下沉化息息相关。‍
1. 社区气氛 ‍‍

针对社区气氛 ,在C端设计上一般采取的方法 为:
新增默认展示的推荐区Tab,展示筛选后的优质评论,在表示 层面营造良社区气氛 ,以引导用户揭橥 适合 恰当的内容;折叠评论提交入口和展示页,增加用户使用评论功能的成本,降低触及;排序规矩 改革 ,默认以热度或推荐排序,可进行人工干涉 ,引导用户进行良性互动。

以上办法 多在可用性上表示 得较差,究竟 仅是通过黑盒机制或提升使用成本,来减弱用户对不良社区气氛 的感知。
在用户层面而言,与用户期望存在一定的偏差,并且 一部分用户依旧需要一窥评论区全貌,难免因以上的办法 而受到负面影响。
2. 社区治理

采取 产品设计技巧可以低成本涌现比较优质的社区气氛 ,而气氛 利害 的根源还是在宣布 者身上。
以往的社区治理多是针对是否违法违规展开,在普遍追求优质气氛 的竞争环境下,年夜 家开始把目光放在了评论内容自己 的质量问题上。
这意味着需要平台有基本的治理能力,也需要有识别内容利害 的能力,随着NLP(自然语言处理Natural Language Processing)或OCR(字符识别 Optical Character Recognition)这类能力的成长 ,治理手段也高超起来:
1)内容宣布 治理
评论内容触发本地或办事 器端症结 词库,转为仅自己可见,严重的直接被删除;评论内容未通过机器算法NLP审核,转为仅自己可见,严重的直接被删除。
2)内容质量识别:‍‍‍‍
机器算法NLP无法明确判断内容倾向,转入人工审核流程,审核结果未出前坚持 为仅自己可见,依照 审核结果释放展示或自见或删除;评论内容被机器算法NLP识别为无意义或低质量,被折叠或击沉;评论内容被「不喜欢」过多,被折叠或击沉。

以上五类方法 中,前几种为年夜 多半 平台所使用,既可包管 宣布 者最基本的体验,也照顾到平台的平安 和不雅 者的清净。
折叠或击沉评论的办法 ,使用的范围较窄,比较典范 的当属知乎,按其自己 强调专业性和关怀 回答价值的角度而言,“折叠”是平台专业态度的体现,用户一定水平 上是可以接受的。
3. 评论「不喜欢」


评论区的「不喜欢」功能已几乎成了摆设,一般体现为用户评论在收到一定命 量的「不喜欢」后才会被折叠或击沉或转为自见。
这只满足了用户点击「不喜欢」时的投票态度,无法体现用户主动介入 气氛 治理的姿态,并且 这条评论会停留在用户视野内很久,用户不知道它何时被处理、会不会被处理,既不克不及 包管 不雅 者的体验,也没有满足“所见即所得”的设计基本法。

在抖音平台而言,尤其是面向年夜 基数的下沉用户时,社区的气氛 治理是必须要解决的“硬骨头”。
抖音可能采取 了如下的办法 (验证与猜测,不代表官方就是这么做的):
混搭排序规矩 :以评论点赞数与宣布 时间轴为基础排序规矩 ,配合NLP质量分,前置部分优质且有一定热度或者新宣布 的评论,包管 用户在评论区前两屏得以查看高热和较新的优质评论;
排序公式模拟:在「混搭排序」中,猜测是采取 净正向点赞+NLP质量分的方法 进行的排序,或是采取 评论质量分公式影响排序,对公式的简单模拟:
xyz分别代表LIKE、DISLIKE、NLP识别分的权重系数,应当由后端控制,可随时进行调剂 ‍。
「不喜欢」交互设计:作为负点赞方法 ,在用户侧的表示 是点击即隐藏该条评论,相符 “所见即所得”的交互规矩 ,也满足了用户「杀灭」负面内容的情绪;在排序影响上,应该是抵消了部分的正向点赞,得出评论的实时净点赞分的权重,用以影响排序。

抖音采取这种排序逻辑和设计策略的优势在于:
可以提升高热、高质量的评论的触及和展示效率;社区治理上,可规避质量较差的评论涌现,抬升评论区气氛 ;用户体验上,既包管 了社区气氛 的舒适感,也在交互层面上做到所见即所得;体现用户DISLIKE的投票权,点击即对用户隐藏的方法 ,一定水平 上满足了用户对评论区定制的期望,也体现了用户操作是有权威性的这一安慰剂式的设计理念。

二、点赞推荐
「点赞推荐」的功能释义为:用户可以通过打开功能,使自己的朋友或粉丝看到自己所点赞的视频。
我见之熟悉的原因是之前在Soul时设计但未落地的“转播”功能有异曲同工之处。
本义都是为了增进 内容在用户侧的自然分发,提升优质内容的流传 性。
也就是说,点赞推荐功能,其实是Twitter和微博“转推”功能的翻版,微信的「在看」功能亦属同样的业务逻辑。

在业务价值上,用户侧内容的自然分发,更易于产生社交互动,也有助于用户之间突破推荐机制带来的信息茧房影响。当封闭 朋友可见时,推荐则成了一种低权重的流量推荐手段。
在功能设计层面上,它是个比较有趣的功能,既增加了用户之间互相窥探对方喜好的途径,也有助于用户之间社交关系的加固。

但在交互设计上,我更倾向于抖音在实验试错,因为该功能的交互设计计划 是失败的,原因有以下几点:
1)它在信息设计上的门槛过高,使用户无法快速的理解这个功能的影响
“点赞作品不会推荐给朋友”&“点赞作品会推荐给朋友”,很难相信,涉及状态开关提醒的文案只有这么弱的差别 。如果是有意为之,便有刻意降低用户感知和认知的嫌疑;如果是无意为之,那这个计划 真的让人年夜 跌眼镜。
2)推荐给朋友后的涌现方法 ,需要用户适当存眷 和支付 一定的学习成本

点击推荐后的样式变革 ,即是告诉 用户「推荐」是会这样展示给用户;同时在设置拉起的浮层有种动图以演示该效果。表意太弱了。
3)功能开关的说明信息比较庞杂 ,无形中抬升了用户的使用门槛
总的来说,功能是好的,但使用门槛和学习成本过高,对年夜 龄用户或轻中度用户而言,功能触及可能仅仅会停留在“点赞之后有新的器械 出来了,看一看”罢了 。
并且 在用户侧会出于私密性的原因,并不会愿意坚持 恒打开「推荐」。因此推荐开关需要考虑临时开关和总开关两个状态。
好的功能,需要好的设计。好的设计,一定 是使用门槛和学习成本比较低的。
可以适当教育用户,但不克不及 自说自话地教育用户。
以下依照 VADU的设计理论对这个功能进行Redesign的测验考试 。
三、计划 重设计
在重新设计之前,需要深入了解业务组成 。
线上版本的「点赞推荐」中涉及到的开关过多,功能入口表示 又稍显含蓄,在文案的信息设计上拔高了使用门槛,重新设计将以重点解决这些问题为目标。
1. 「点赞推荐」线上业务组成

业务的起点,实是增加推荐手段,引导用户推荐内容给其他用户。‍‍‍‍
在这个基础上“增加”了用户可进一步选择将点赞的内容推荐给朋友。只是这一步增加,将「点赞推荐」的流程庞杂 化。开关逻辑见下图:

2. 「点赞推荐」拆解与重设计‍‍‍‍‍‍

在了解了基础的业务逻辑后开始着手。
1)功能入口强化‍‍‍‍‍‍(价值强化)
将功能价值点表示 在入口上,增加用户决策因子,也使用户能一眼了解功能寄义 。

2)功能说明浮层信息强化(抵达性强化)‍‍‍‍
点赞作品和推荐作品实是两件事,需要在表意上明确区分,不要给用户留任何暧昧 的余地。适当情况下可以增加Icon帮助 表意。‍‍


3)浮层中的功能开关交互合理化(抵达性、可用性强化)‍‍‍‍
线上的 坚持 封闭 /开启 & 坚持 开启/封闭的按钮互斥状态,完全不合乎交互设计的任何规矩 。既不明确,也没有体现开关状态。可以适当增加说明,并采取 开关形式解决。‍

4)总开关表意和交互合理化(可用性强化)
原本的浮层说明和开关示意,均存在表意不清的情况。改革 原浮层交互为新启页面,在页面内详细释义功能。

5)改革 总览

四、综上所述
从上述案例,我们得以窥见抖音在业务细节上的打磨,同时在交互细节上的瑕疵点。但这种细节的把控和测验考试 ,都应当是IT行业万马齐喑的今天应该去做的,这也是最原本IT公司做过的事情。
作为设计师,能跳脱出来审视自己,以理论来作为工作办法 论的基底,都是难能可贵的品质。
这也正是我回答面试问题“你觉得你比同样十年经验的设计师的优势在哪里”的谜底 。
跳出设计者思维,以普通不雅 者的视角反不雅 自己的办法 和输出,以学术理论来指导自己,进行适当的反思和纠正,这很重要。
本文由 @无鹿森 原创宣布 于人人都是产品经理,未经许可,禁止转载
题图来自 Unsplash,基于 CC0 协议
该文不雅 点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间办事 。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|手机版|小黑屋|货拉客微商论坛 |网站地图|网站地图

GMT+8, 2024-9-20 07:55 , Processed in 0.080992 second(s), 19 queries , Gzip On.

Powered by Huolake! X3.5

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表