微信 10 个交互细节问题的探讨与重设计

2017-01-12 09:43:00

文章分析了微信交互设计中的几个细节问题，与大家分享，希望能够给大家带来一定的启发。

微信小程序开闸后果然立即成为这个雾霾格外严重的冬天中的一抹亮色，关于小程序将如何给互联网应用生态带来冲击的讨论迅速在朋友圈刷了屏，小至小程序和WebAPP体验的对比、低频APP的危机，大至微信在库克眼皮底下的暗度陈仓、引流与分流的博弈，太多的可能性值得我们拭目以待。

此时作为一枚安静的设计汪，注意力还是回到微信传统的聊天、朋友圈、公众号这三大模块的交互设计本身吧。原本以为伴随着微信小程序的发布，会有一次比较大的版本更新，但9号醒来后发现iOS端的版本号依然是2017年1月3日更新的6.5.3（说「开闸」结果真的是开闸而已啊……）。三大模块中一些可用性方面的交互细节问题依然坚挺。本篇将从我的个人体验、朋友闲聊中的反馈、知乎上「微信设计的渣细节有哪些？」这一帖子下的一千余条吐槽中，选择其中10个比较有代表性的问题，对可能的优化方案进行简单的重设计和探讨。

当然，这里虽然暂且称之为「问题」，但仅仅是纯粹从用户角度出发、在使用过程中在交互方面可能感到的一些不便之处。考虑到微信面对的亿级用户群体，任何一个功能的新增和改动的决策风险也都不是团队外的人可以妄加评论的。设计方案的优劣本就没有非黑即白的定论，我也有理由相信微信作为国内最成功的IM（以后会不会是OS？）团队，关于这些问题都是经过推敲和取舍的，甚至有的在用户看来是「问题」的地方是产品方出于业务目标考虑有意为之的。

因此，相比讨论我做出的10个重设计方案是否合理，我倒是更期待去了解经过千锤百炼的原版方案中为什么会这样做。如果有幸被知情人士看到这篇文章，并有机会一起聊聊的话，就再好不过了：）

本篇重设计和讨论将基于iOS端6.5.3版本进行，因为小程序仅处于发布初期，可以说仍然是测试和逐步完善的阶段，因此讨论范围将暂时不涉及小程序。

公众号阅读与聊天的切换
连续添加多个公众号
订阅号的分组查看
群聊消息的完全屏蔽
删除会话时的危险操作警告
收藏表情的排序整理
将非表情图片添加为表情
朋友圈的返回顶部操作
朋友圈消息通知的两个优化
意见反馈通道的简化

以上10个可用性细节中，第1~3点针对公众号模块，第4~7点针对聊天会话模块，第8~9点针对朋友圈模块，第10点则是关于辅助流程中的意见反馈功能。

1. 公众号阅读与聊天间的切换

在阅读公众号文章的过程中，小手机忽然虎躯一震——你知道收到了新消息，你担心是来自女朋友或是上司的「指示」，生怕回得不及时，便忙不迭地返回了会话列表，但当你查看并处理完这条新消息后，想要继续阅读公众号，又要重新从「会话列表」→「订阅号」→「你想读的公众号」→「公众号会话页」→「刚才在读的文章」这一路径重新回到文章页面。这一路径虽然并不算非常冗长，但当你好不容易继续阅读后，如果小手机又虎躯一震呢……想必如此往返几次，再耐心的人也会抓狂吧。

其实现在微信已经很人性化地帮助用户在第二次进入文章页面时，自动跳转到上次阅读到的位置，至少重新回到文章页面后不用滚动半天找到刚才的进度了。但仍然缺少一个可以在新收到的消息和正在阅读的文章之间直接往返的路径。

这种不支持多任务的做法很符合「用后即走」（在这里或许说「看完再走」更合适）的理念，通过提高往返成本，让用户尽量看完后再离开文章页面。在文章长度一般、收到新消息的频率和紧迫性都不高的情况下，用户可以尽量做到读完再走。但当文章较长、收到新消息的频率比较高、消息也比较重要的情况下，没法一键返回继续阅读就真的会导致体验受损了。

我个人的习惯是打开一篇文章，先看一下是不是很快能读完的，如果是长文就直接点击「…」→「在Safari中打开」，不过对于竭尽所能把用户留在微信中的产品方，也是一万个不希望大家都用这种方法去解决多任务问题吧。

对此，重设计中在文章页提供了一个提示新消息的控件，有别于原有「返回」操作，通过这一控件返回会话列表查看并处理新消息时，可以在聊天顶部看到一个返回继续阅读文章的入口，从而方便地一键返回文章页面、继续浏览。

其实，类似小程序中在Action Sheet中提供「显示在聊天顶部」选项，允许用户手动将文章保留在聊天顶部的设计方式也是一种可行的方案。但考虑到公众号文章页点击「…」后调出的菜单已经较为复杂，而且用户在没有收到新消息的情况下，主动中断阅读前往其他页面的场景可能并不多见，因此最后还是选择了上面这种重设计方案。

2. 连续添加多个公众号

当你通过非精确的关键词搜索，查找关于某一领域的公众号时，你可能对搜索结果中的多个公众号都有兴趣。而当你进入其中一个公众号的「公众号信息页」并点击关注后，关注成功后的状态会一闪而过，然后进入「公众号会话页」并收到公众号的欢迎语。此时点击导航栏的返回按钮将直接返回「微信」页的会话列表。想关注刚才搜索结果中的其他公众号的话，你只能重新再搜索一次。

个人觉得任何一个页面的「一闪而过」对用户而言都是不太好的体验，不但没有太大必要（闪一秒反正也看不清），也容易让用户对自己的操作产生不可控的沮丧感。因此，关注成功后，要么直接（不显示关注成功后的状态）进入「公众号会话页」，要么停留在已成功关注状态的「公众号信息页」，都是更好的做法。

而回到刚才的场景，如果要为用户提供一个连续添加多个公众号的入口，那么后者，也就是关注后停留在已成功关注状态的「公众号信息页」更为合适。用户此时可以自由选择，想添加其他搜索结果时，可以通过「返回」回到搜索列表；无意添加其他搜索结果、只想开始浏览当前公众号时，可以通过「进入公众号」进入「公众号会话页」；想直接退出当前流程，回到会话列表时，可以通过新设的「关闭」直接退出添加公众号的流程，回到「微信」页。

3. 订阅号的分组查看

这个问题对关注订阅号的数目不是很多的用户来说并不明显，但对于身边一些关注了数十个公众号的「订阅号控」们来说，无论是从「微信-订阅号」这一入口按消息更新顺序翻找，还是从「通讯录-公众号」这一入口，在订阅号和服务号等全部公众号中按字母表翻找，都是一件痛苦的事情。

两种入口中，经过询问多个朋友的使用习惯，包括自己的个人习惯，都是更习惯使用「微信-订阅号」这一入口，实在找不到时才会尝试从「通讯录-公众号」按字母表查找，因此本节讨论暂针对前者进行。

如果用户想找的是一个订阅号时，可以在「通讯录-公众号」中按字母表查找，或者使用「置顶公众号」功能暂且解决。

而如果不是一个，而是一类呢？例如，用户想重点关注几个质量特别高的公众号，或者此时只看某一类别的公众号时，就变得有点棘手了。

对此，重设计中利用「订阅号」页面的导航栏右端，提供了一个筛选控件，默认显示「全部」，点击后可以筛选并选择只显示特定分组的订阅号，从而提高用户阅读特定一类公众号的效率。而订阅号的分组可以在「公众号信息页」中进行设置和管理。

4. 群聊消息的完全屏蔽

群聊无法彻底屏蔽应该是一个很多人吐槽已久的问题了，尤其是鹅厂自家的QQ明明在消息接收模式上很好地满足了用户多样化需求的情况下，微信中群聊只支持免扰、不支持屏蔽的特点，在对比下就成了一条广为诟病的设计，微信拖讨论组不需要对方同意更是把这一问题进一步放大。各种想加入的、不想加入的群，无时无刻不在接收着巨量的消息（其中还包含漫天飞舞的表情包），无论对存储空间还是流量的消耗上都让很多用户怨声载道。

重设计中，在「消息免打扰」功能下方设置了「消息屏蔽」的选项，打开后即可停止接收消息和图片文件。不过，我猜测微信迟迟不引入这一简单的功能，应该不是没意识到、也不是无法解决的技术问题，而是出于某种业务层面的考虑，并不希望用户有机会彻底屏蔽群聊吧。

5. 删除会话时的危险操作警告

左滑会话可以调出删除按钮是一个iOS下很常规的交互操作，但微信中删除一个会话意味着所有聊天记录、图片文件也都随之彻底删除了，无法恢复，关于这一规则的设置，我猜应该是聊天记录的存储机制导致的技术问题，总之微信自有自己的道理，不必过多计较。

但既然要同时删除所有聊天数据又不进行任何提示，看似是简化了不必要的二次确认，但却很容易造成问题。对中级和专家用户来说，或许对此早已心中有数，而对于基数最大的新手用户（尤其是年龄段较高的用户）来说可能未必如此，很容易由此造成的聊天记录和图片不可逆的损失。

重设计中，在调出删除按钮、点击后会多出一步确认操作，用于提示用户，在删除会话的同时，聊天记录和文件会同时删除。同时，也允许用户在熟知这一操作背后的危险性后，选择「下次不再提示」。

6. 收藏表情的排序整理

表情包是当前年轻用户使用IM聊天时不可缺少的一部分（当然，中老年用户也使用表情包……虽然不是一类表情）。而当用户收藏了数目较为可观的表情后，将最常用的表情以特定的顺序放在最方便的位置，就成了一个很普遍的诉求。

最方便的位置，显然是表情面板的第一屏，可惜寸土寸金的第一屏已经被硕大的「+」入口、猜拳和骰子占掉了三个座位，只剩下5个位置可用的情况下，一定程度上加剧了上述需求出现的频率。

而在整理表情时，用户经常会按照其他应用中类似场景下的使用习惯，理所当然地觉得表情是可以通过长按拖动，实现自由的排序的，可事实上微信的表情整理只支持「移到最前」这一种方式，这就让表情的顺序调整变得很笨拙，尤其是小范围内的精细调节时，比如下面这个例子。

重设计中，补充了长按拖动这一功能，这一符合用户已有使用习惯和心智模型的交互方式并不需要太高的学习成本。大范围地调节时，可以选中后一起「移到最前」，小范围地局部调节时，可以长按拖动。两者相辅相成，我想可以大幅优化用户管理表情包时的体验。

另外，对「让常用表情出现在更方便的位置」这一需求，按使用历史或者使用频率自动降序也是一种看似可行的方向。不过，Genie解释过这个问题，无论是按使用历史还是频率，自动排序都会导致用户想找一个表情时不确定位置在哪，大大提高寻找表情的时间成本。也就是说，这种做法只方便了查找最常用的几个表情，而偶尔要找一个不算很常用的表情时，这种做法的弊端就会很明显。

因此，重设计中还是考虑通过长按拖动，允许用户更灵活地自定义固定排序即可较好地解决表情管理中的这一问题。

7. 将非表情图片添加为表情

同样是关于表情包的一个问题。「为什么有的表情可以添加到自己的表情，有的不行？」这个问题已经不止一次听到朋友或者同事聊起。

原因很简单，不过解释起来有点绕。会话中的图片我们看上去都一样，但其实有两种格式，暂且一种称之为「表情」、一种称之为「非表情」吧。「表情」是其他用户已经通过正确的方式转化并添加到收藏的「真正的」表情，而「非表情」则只是单纯的图片（虽然这个图片本身可能是一张金馆长熊猫脸的表情），并没有转化成微信内部「表情」的形式，而是在聊天中通过「发送图片」、「转发」等形式四处流传的，这样的情形不多，但偶尔出现时，无法收藏进自己的表情也常常会造成用户的困惑。

熟悉表情管理的用户一定知道，如果想把一张「非表情」添加为「表情」，可以先将其保存为图片，再经表情面板的第一个「+」按钮→「我的表情」→「添加的表情」→点击表情列表末尾的「+」格子→从相册中导入这一图片，从而将其从「非表情」格式转化为「表情」格式（这一过程这里不再赘述）。但对很多不熟悉这一流程的用户来说呢？还是通过下面这个小例子来说明吧。

重设计中对「非表情」也添加了「添加到表情」功能，从而一键代替现有方案中冗长而繁琐的添加表情流程。至于功能的位置，原本考虑直接在会话界面长按图片调出的快捷菜单中设置一个「添加到表情」功能，但在已有5个选项的情况下，再添加一个五个汉字的选项并不合适，所以还是把这个功能收进了大图模式长按图片调出的Action Sheet中。

当然了，我猜测微信这样设计可能是有意为之的，有可能是为了避免过量的「非表情」图片变成可以更便捷地流通的「表情」，导致加剧表情包大战的风气，才刻意提高了这一操作的学习和时间成本。不过纯粹从用户体验角度，我想应该有比当前方案更合适的解决途径。

8. 朋友圈的返回顶部操作

这一点严格来说不是问题，因为iOS端的应用实际上是内置了「点击状态栏快速返回顶部」的功能，但和上面提到的很多问题一样，对中级和专家用户来说不言而喻，不代表对新手用户不言而喻。在熟知这一个功能的人看来，这种小技巧只要知道一次以后就都不言自明了，但事实是相当数量的人至今还不知道，我就亲眼目睹过很多人不停地向上滚动屏幕以返回朋友圈顶部的操作习惯。

重设计中，考虑到用户并不一定能正确区分「状态栏」和「导航栏」这些术语，便将返回顶部的功能赋予了区域更大、更容易点击的导航栏中部，并显式地告知了用户「点击这里就可以返回顶部」。

9. 朋友圈消息通知的两个优化

关于朋友圈的消息通知，听到过频率比较高的两种抱怨。

第一种抱怨，是关于朋友圈更新的红点提醒。

A：「朋友圈老是有红点，我又有见到红点不刷不舒服的强迫症，只好不停地去刷，时间就这么过去了T_T」
B：「那你关了呗」
A：「关了更会想，虽然没提示，但是不是有更新呢……于是刷得更频繁了」
BCD：「……」

这类抱怨的本质不是用户想不想接收提示的问题，而是用户被提示吸引进行了刷新操作后，看到的信息并不一定是他们感兴趣的。所以，现有方案中简单的非开即关的设置很难有效地解决这一问题，用户需要这一提醒功能，只不过希望更有质量的提醒，而并不是完全关闭。

第二种抱怨，是关于共同朋友间互动的计数气泡。朋友圈出现红色的计数气泡的情形分以下三种：

A：你发了朋友圈，则你共同朋友的点赞和评论（无论评论有无指向性），都会出现计数提示。
B：你点赞了X的朋友圈，则你的共同朋友（包括X本人）的点赞和无指向性评论，都会出现计数提示。
C：你评论了X的朋友圈，则你的共同朋友（包括X本人）的点赞、无指向性评论和指向你的评论，都会出现计数提示。

而抱怨主要是针对B和C类的。

A：「我给朋友晒结婚证的朋友圈点了赞，然后一整天都在收到别人点赞和评论的提醒。」
B：「说明你朋友人缘好呗」
A：「可是，不停地看到红色数字，点进去却发现全是别人之间的互动，自己发的朋友圈无人问津，会很失落的」
ABCD：「……」

其实这类抱怨因人而异。有人喜欢看共同朋友之间的互动，比如八卦一下「哎呀原来A也这么关心B」、「天呐C怎么说话这么酸」，对他们来说，现有的提示机制就很得欢心，甚至巴不得连朋友之间有指向性的互相评论也有提示更好。

而有人则对和自己没有直接关联的互动毫无兴趣，却又不得不逐条看完别人之间的点赞和评论，对他们来说，只有A类和C类中指向他的评论，才是他所关心的。对他们没兴趣看的互动，数量有限时或许还好，但对一部分微信好友数量比较可观的用户来说，每每动辄几十条的话，久而久之可能就干脆懒得看了，我想这也不是产品方愿意看到的后果。

两类用户都有一定的数量，不过在我的圈子和询问的用户范围内，后者稍微占多数。

关于红点提醒和计数提醒的抱怨代表了两个用户诉求，那么综合这两种需求，我的重设计方案考虑如下：

首先，允许只对部分朋友的朋友圈在更新时显示红点提示，从提高提醒质量的角度解决第一个需求。
其次，允许用户关闭朋友之间互动产生的计数提示，即只保留上述分类中A类和C类中指向用户自己的评论。

10. 意见反馈通道的简化

最后想说的一点，是关于微信的意见反馈功能。
意见反馈作为一个每个APP必备的常规辅助功能，原本并非核心流程，也不容易出现什么明显的问题。但微信的意见反馈路径……实在是我所见过最长的。

长的原因首先是和常见问题的FAQ公用一个入口，这个出于简化「设置」页信息元素的考虑也无可厚非。

但同时，微信的意见反馈要求用户必须帮助产品方将问题进行两级细分后，才能抵达输入意见的页面。如果用户选择的不是「其他异常反馈」而是某个细分的选项，那么在输入意见时还要进行第三次关于故障位置的细分。

这种设计的实质就是将用户反馈的收集和分类工作，由产品方转嫁给了用户。一级分类或许还可以理解，但二、三级的分类简直是让用户有放弃的冲动。不过假如这是出于资源有限的考虑，有意将提交意见反馈的流程复杂化，从而提高反馈的质量、同时大幅降低反馈数量的话，倒也不难理解。

如果不考虑这些，单纯从用户角度出发，个人觉得应该有更好的方案可以考虑。重设计中，我首先将「常见问题」和「意见反馈」的两个入口分离，「查询既定帮助文档」和「直接提交反馈」两种场景的差异还是蛮大的，在「设置」页的信息没有过载的情况下，分离开来利大于弊。

「常见问题」保留除意见反馈外的全部原有内容，此处不再赘述。而「意见反馈」则直达输入意见的页面，其中「问题分类」选项允许用户视自己的意愿是否提供细致的分类（逐级细分的选择流程参考现有方案，不再赘述），并通过文案告知用户，如果愿意提供准确的分类，将有助于你提出建议得到更好的反馈，即「诱导」而不是「强迫」用户替代产品方对反馈进行细分的工作。