只说产品：微信的聪明设计(1)有效率的群组

iDoNews 只说产品 第1期 3月26日亮点：

• 导入QQ联系人被评价为微信成功最重要的因素之一，但为何微信却未考虑导入Q群？
• 既然不可以导入Q群，为什么微信又有多人聊天的群组形态？

本期 iDoNews 只说产品为您介绍微信是如何将群组设计得高效率而低噪音的。

盛大的产品经理周建华曾经在知乎中评价：「微信是我见过的所有app里，将复杂产品逻辑简单清晰化做的最棒的」[1] 。不仅如此，在沉浸了微信一段时间之后，发现微信有许多非常精彩的设计，在第一篇里，我们先聊一下「有效率的群组」

知乎上曾经有一个讨论：为什么微信只导入QQ联系人，不导入QQ群，回答者，也是笔者的朋友量子同学说了效率论：手机是一个讲求效率的东西，而群是一个没有效率的东西。

但不可否认，微信还是有「群」这种形态的，那么微信到底是要群呢，还是不要群呢？

如果要说同时具备「多人+同步通讯」特性的产品，QQ群算非常早的，甚至 —— 他可能是国内第二个产品，为了阻击 MSN 的多人聊天，但时间长了之后，QQ群一直有一个问题：难以保持高的参与率。

之所以这里说「参与率」而没有说「活跃度」，因为Q群一直存在一个问题，少量用户可能具有高的参与率，但同时这些高度活跃的群在排挤更多的用户，以至于大多数用户变得沉默，所以我们经常会发现，一个200人的群，真正活跃的用户不超过20个，次活跃的用户也不超过30个。

大量进入了之后就不太愿意按「退出」，或者沉默的用户占据了QQ群内，表面来说，这样或许是好的：虽然这些人不参与，但「总有一定概率他们会偶尔参与一下」，但细细想一下，实际上这样并不好。因为：

1. 所有加群的动力都会存在上限，当一个人发现加群太多了，他就不会加群。
2. 如果群组不能保持自由、轻易、简单的加入与退出，基于第一点，用户与群组之间就会存在不合理的「结构分配」。即有意愿、兴趣群聊的用户，不一定能找到能接纳他的群。

因此，群组合理的分配是非常有必要的。但我们谈的是微信啊，要控制一下篇幅，为什么群员要保持高流动速率，可以看一下我之前的这篇文章：互联网群、圈子形态产品与社交

于是，我们很自然能想到一种少即是多的做法：为每个群组限定最长沉默时间，如果一个用户在群内超过 X 时间内不参与，则自动退群。

但这种限定方式比较直脑子，因为你无论X设为多少，总不能满足所有情形，譬如一些热闹的群，可能设为一个月比较好；而一些冷清但是重要的群，又可能是半年比较好。

这个问题本来跟微信的设计没有太大关系，但直到那天，微信上出现了「为什么微信只导入QQ联系人，不导入QQ群」的问题。

后来笔者发现，在参与那个回答之前，与量子都没有看清楚一个问题：微信保持了群自由的退出与加入。

自由的加入这不成问题，无论是早期的管理员邀请制，还是后期的所有群员邀请制，需要邀请好友关系进入都非常简单。

而自由的退出则成问题，如果我们真的在微信中导入Q群，那会发生极大的灾难：整个微信吵得要死，索性直接关闭了微信。[2]

而微信通过「设定最大的动态长度」，很好地解决了这个问题：

每个微信的群组都「仅」出现在「微信动态列表」里，而微信的动态列表会随着用户接收最大的消息量，将较早发生的动态冲刷到末尾（直至冲出动态），当群组排位靠后之后，会发生不算增大的「沉默」概率，直至冲刷出群组后解散。

而在被冲刷的过程中，如果群组内需要重新发起讨论，也可以迅速被激活到动态的第一位：直至群组实在没什么可聊的时候，他就会自动冲刷到末位，直至消失。

不知道是微信有意设计还是妙手偶得，这种设计理念解决的核心问题是：「在解决了用户为什么用之后，怎么解决用户为什么不用，以防止积累所形成的体验不佳」。所以当初笔者的朋友量子同学说：「微信的群是暂时性的群聊，而不是持续的群聊」，笔者就觉得很奇怪，什么样的产品设计能做到「暂时性的群聊」呢？因此笔者仔细研究之后，来写了这篇文章分享。

同样的问题可以借鉴到其他地方，举个例子，我们经常会开很多聊天窗口，直到任务栏有了十几个聊天窗口，因为我们总是忘记关或者懒得去关。腾讯的解决方案是，可以把五个窗口合并为一个窗口+五个分页。

但这问题还没有根本上的解决。那是否可以设计将聊天窗口的分页也作为动态，最新的聊天摆在最前面，而大量少的聊天就会在最后了？甚至设定最大值10个窗口，超过10个窗口的自动关闭？或者数据转存到硬盘，提高程序效率？

不仅仅是QQ聊天，这类型需要「暂时」的设计方案还有很多种应用可能。以实现复杂逻辑的简单之美。

[1]：http://www.zhihu.com/question/20717745/answer/16071932

[2]：需要注意，在移动端中，由于内容通道大小、操作精确度、使用环境等都与桌面端有较大的差距，整体来说，PC桌面端能忍受群较大的噪音，而移动端则只能忍受很少噪音。