（五）交互分析
【点赞中】：发文页
【1】点赞按钮操作
用户痛点：频繁出现操作困难、易失误的情况。
问题Q4：痛点原因是什么呢？
带着疑问，进入用户视角：我尝试模拟用户单手持机，完成一次表态点赞。体验记录如下：
我的定位和AB用户一样，我们当前并不清楚表情点赞是什么、也不知道该如何正确使用它，所以我的第一件事是先看看这些表情是什么意思、是否有我想要的心情。我试着把每个表情走一遍，但按压到第4图的抱抱时，我已经有点吃力了；想选择第5图最后一个悲伤，我需要把大拇指捋直了才能触碰到它。
梳理整个点赞过程，操作手势有两种：
1、点击：选择
2、长按：预览+选择
这两种手势，使用场景是：
1、你能清楚知道某个表情含义，并毫不犹豫选择它时，才会使用点击，这是个精确操作。
2、你不清楚表情时，可能会和我一样都试一遍，操作流程是：长按预览-移动浏览-松手选择。长按过程中，你需要时刻保持注意力，掌握好按压的力度，否则移动中手滑松开了、或者后悔当前的选择时，你就会选错表情，之后你又要重头再把这个流程走一遍。
由此，操作难的原因有：
1、信息的布局。
表情赞从左到右，依次按照“负向-中立-正向”的逻辑来排序。把正向情绪放在操作舒适区，这是产品有意规划的位置，权衡了正负信息的优先级。把负向情绪靠前，增加了2-3秒的操作时间，目的是让用户慎重考虑自己否真的要表达负向，避免无意义的冲动宣泄。
2、长按的局限性。
长按的重复试错成本很高，是个耗时耗力的操作。它虽然能有效防止误操作，但稍不留神也会有失误。
🌵我的解决思路是：从用户认知入手，多熟悉这几个表情。当唤起表态按钮时，他们能下意识直接点击操作，而不是走“长按-预览-再操作”的老路。
【2】点赞结果反馈
反馈状态，主要包含：点赞成功、取消点赞、点赞异常（无网络点赞失败）。
微博点赞反馈，没有任何弹窗提示，它主要依靠醒目的动画效果、按钮高亮状态，来判断你是否点赞成功。
1、有网情况下，点赞动画和按钮高亮同步显示并发生变化，容易辨认点赞是否成功。
2、但无网情况下，就有些困惑了。它允许用户进行无网操作，还显示点赞动画，让人以为自己点赞成功了。但实际上，操作后的点赞是无效的，点赞数不会变化、按钮也无反应，这前后矛盾的操作十分令人不解。
🌵我的解决思路是：
添加异常情况的逻辑提示。用toast吐司提示，明确告知用户“当前是什么情况，因为什么原因导致无法点赞，并给予对应的解决办法”。同时不显示点赞动画，别让用户有点赞成功的错觉。
【点赞后】：评论区页/消息页
『评论区页』
用户和产品的需求场景：
问题Q5：评论发布者，需求：发布评论后，希望收到他人的点赞认同。在设计上如何实现这个目标？
目标达成需要几个条件：
1、先确保自己的评论能被人看到，并允许别人参与。
2、点赞功能容易看到、好用。
3、赞，不是任意的赞，而是评论者想要的、对他有利的赞。
由此看重两个因素：
1、评论区的结构：内容显示、互动形式、排序规则。
2、确定合适的点赞功能：拇指赞or表态赞，功能易见、操作好。
【1】评论区结构
微博评论区，选用是主题式结构。
主题式结构特点：
1、每条评论单独一层，可以形成一个主题，进行延展讨论。它作为一级关系，显示在评论区。
2、该评论的所有回复，都集中在这个评论主题内。它作为二级关系，折叠在主体评论下，进入详情能看到整个对话的过程。
设计原因：
1、微博评论量巨大，必须筛选信息的优先级。
2、优先突出评论者的主体评论，提供热度和时间排序，两种方式都给内容曝光的机会。
3、浏览者看到后，可以快速判断是不是自己感兴趣的内容，然后再决定下一步是否深度参与。整个过程循序渐进，符合用户“先浏览、做决策、再行动”的认知习惯。
实现目标：
当评论者的内容足够引起共鸣时，他的内容会成为一个新主题，在独享页面内聚众引发热议。
1、对于评论者：可以有效集中志同道合的人，迅速得到点赞认可。
2、对于浏览者：连贯预览一二级对话，可以清晰了解主题的前后脉络，直接定位在感兴趣的节点加入讨论。
3、对平台：当热议数据达到足量时，用户评论会转变成热搜、热门词条，全站迅速传播，给平台带来二次热门话题效应，实现更多的流量吸睛。
【2】评论区点赞功能
评论区对于评论者，仅提供拇指点赞功能，并把功能放置在每条评论下方触手可及的位置。
设计原因：
在社交互动形式中，评论产生的价值、付出的成本、优先级＞点赞。当一个用户愿意评论时，他的交流意愿和互动分享是最强烈，平台鼓励这样的用户积极参与，使用拇指点赞，它表达的赞同和喜爱，能给予评论者很大的支持和鼓舞，这也是评论者想要的赞。
实现目标：
赞越多，认同感越强，评论者心里的满足感和成就感也越高。继而形成一个良性循环，点赞促使评论者愿意发布更多有价值、有共鸣的评论内容。
『消息页』
用户需求：不论是点赞者、收赞者，都对接收消息有轻度通知、防打扰的需求。
【1】通知形式
选择Badge徽标，作为站内信的通知形式。点赞通知，允许用户设置数字、小红点。
Badge特点：用符号告知用户当前应用出现新动态、新消息。它仅通知，不需要用户立即做出回应，也不会打断用户正在进行中的行为，是一种弱提醒。
Badge两种模式，使用场景不同：
数字模式：是精确通知，告诉用户具体的点赞数量。数字和红面结合，视觉醒目、干扰强烈。
红点模式：是模糊通知，只用一个小点告诉用户点赞有动态，仅此而已，对人的心理压力和干扰比较小。
当用户选择红点模式时，意味着他们并不想被过多的点赞消息干扰。
【2】通知规则
1、平台尊重用户意愿，根据用户设置，弱化红点的显示状态。
红点模式：有人点赞时，仅在赞消息入口显示红点，底部tab不做通知，在页面上把通知干扰降到最低。只有用户开启数字模式时，底部tab才会跟随显示通知，高度提醒用户看消息。
2、对重复点赞消息，做合并通知：主要合并流程中的历史节点，仅记录最新一条信息。
同一个人，对同一条博文点赞时，不论赞变更几次选项，都合并到一条通知里，只告诉用户最新的一次点赞情况，从根源上降低红点重复出现，防止信息轰炸。
但规则逻辑有点缺陷，没有对“取消赞”的行为做前后判断，导致用户取消赞后，对方依旧收到点赞通知，但打开消息却看不到点赞人、也看不到赞。
用户反馈中，经常看到各种吐槽“莫名其妙、谁给我点赞了？？”，强打扰的情况出现频繁。
🌵我的解决思路是：
设计考虑容错、防错机制。因为用户不可能都按我们规划的路线走，他们使用功能时总会有各种状况发生，比如撤回、修改、反悔取消等等，我们允许他们犯错，但也要控制他们犯错给别人带来的困扰。
优化：流程中增加对“取消赞”的行为判断。不通知无效点赞，只通知最终有效的点赞记录。
1、赞后取消：不发送取消通知，并撤回上一个点赞通知。
2、赞后取消，再成功点赞：只记录最新一次点赞情况，并通知用户。
从机制上，减少无效空赞、通知点赞数和实际显示赞数不一致的情况，降低对用户的骚扰。
【3】查看消息：『点赞详情页』
AB用户查看点赞消息，有两个需求：
A：希望收到对方的好感。
B：希望高效回应对方的点赞。
这里都涉及一个重要的互动形式：点赞回复。
【1】列表结构
点赞详情列表页，主要有几个模块：
1、点赞人信息：（头像、人名、时间、点赞动作）
2、点赞信息源：（点赞内容、内容来源）
3、社交功能：（回复、屏蔽、拉黑）
页面结构逻辑是，告诉用户：“是谁，在什么时候，给你的什么信息点赞，你可以对他做哪些社交回应”。说明，这是一个注重「双向互动」的点赞页面。
有两点值得注意：
1、点赞信息源，展示得的非常详细：一级点赞内容、二级内容来源，全都完整的展示出来。
设计原因：帮助收赞人回忆“自己在过什么地方、说过什么话、做过什么事”，结合上下文判断点赞人在哪些方面和自己的喜好、价值观一样，由此加深好印象，促使双方进行互动。
存在弊端：屏效性差，单条信息占面大，查阅效率变低。
2、点赞的互动方式，主要是回复。而且是由人，亲自手动写回复。
问题Q6：点赞场景下的回复，要回什么呢？回一个“谢谢”而已？这是一个高频使用的功能吗？
【2】点赞回复
产品定位下的点赞特征：
这是一个公开的社交平台，任何人都可以对你的博文点赞，陌生人互动居多。因为点赞操作快、成本低，很多人养成随手一赞、路过支持的习惯。这个赞，只是一种简单又表面的态度，点赞不像评论，它不会产出可探讨的观点和内容，单凭一个赞是很难进行深度交流的。赞完就走，成为常态。
手动回复，适用场景：当你有明确目的，知道自己该说什么内容的情况下才会使用。
但面对陌生人随手赞完就走的程度，很多场景下是无话可说的，要用手动回复来对应“轻社交、无内容”的点赞形式，这种互动成本太高了。
🌵我的解决思路是：
调整点赞回复的目标，不是高门槛“深度交流”，而是低难度“增进好感”，用轻回应代替重回复。
优化实施：
1、通过点赞内容数据显示，通常2-3行基本满足查阅的需求，修改信息源规则：默认3行内展示，超出折叠，可提供展开预览。
2、提供系统智能回复点赞，无需人工填写，只需一键发送回赞、比心、送花答谢，即可。
（六）总结
表态点赞功能，基本能满足用户的表达需求，也能实现产品目标。
设计上很重视信息的主次权重，把表情点赞变得易懂、有趣，但因为功能的显示和操作机制有难度，导致用户使用有局限性，难以触达互动体验。
我的想法是基于场景需求，适当调整功能的感知难度和互动成本，让更多人认识和参与表情点赞，在社交中表达更多的真情实感。
