接上篇～～～

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

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

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

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

6. 收藏表情的排序整理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第二种抱怨，是关于共同朋友间互动的计数气泡。朋友圈出现红色的计数气泡的情形分以下三种：
A. 你发了朋友圈，则你共同朋友的点赞和评论（无论评论有无指向性），都会出现计数提示。
B. 你点赞了X的朋友圈，则你的共同朋友（包括X本人）的点赞和无指向性评论，都会出现计数提示。
C. 你评论了X的朋友圈，则你的共同朋友（包括X本人）的点赞、无指向性评论和指向你的评论，都会出现计数提示。

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

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

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

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

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

首先，允许只对部分朋友的朋友圈在更新时显示红点提示，从提高提醒质量的角度解决第一个需求。

其次，允许用户关闭朋友之间互动产生的计数提示，即只保留上述分类中A类和C类中指向用户自己的评论。

10. 意见反馈通道的简化

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

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

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

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

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

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