在之前的文章中，我们说了设计一个社区你需要：一是确定好调性；二是只设计一个信息流；三是直接在信息流里进行互动。当然这个肯定不是通用的，二和三更多的依据其实是第一步调性的选择。

接下来，我们讨论将围绕：如何设计产品功能让社区的运营更流畅。

1. 马甲

先问一个问题，作为产品经理，你会如何让你的产品符合定位？

相信你一定是在一些功能上做一些选择和取舍，把符合定位的核心功能做透。那么，如果你是社区运营，你会如何让社区的调性符合预期？你的抓手和发力点是什么？我们最先能想到的就是控制社区的内容，这就引出了我们的第一个工具：马甲。

在社区刚刚开放的初期，我们需要一些内容底料，这个任务不可能由一两个账号完成，所以需要给运营人员配备一堆马甲。马甲可以从已经活跃的社区上去获得，背后可能还真有这么个真实用户在，切忌想到什么发什么，今天马甲还在找对象，明天这个马甲就晒萌娃照了。当然，这些都是运营层面操作的技巧，不多展开，说回产品。

为了保持业务顺畅，我们设计在app上直接切换马甲。回想两个月前我提出这个想法的时候，运营和技术同学差点把下巴掉桌子上，表示没见过这样干的，一般马甲也都是在管理后台上操作，而后台一般都是PC端的。我之所以坚持这样做理由如下：

1. 运营人员总有下班的时候下班了谁还开电脑呢，手机则是相当顺手的事；

2. 用于一旦发了动态或评论如何才能快速通知到运营人员，手机push看起来是最好的选择；

3. 从技术实现角度，不用重复在后台实现一套发动态发评论的逻辑，复用app即可。

随着场景的丰富，马甲需要设计成全局的切换。其实一开始小中（我们家小产品经理）在做马甲设计的时候，主要考虑了评论的场景，因此很自然的做成了在填写完评论后选择一个马甲。这种设计看起来影响面小，但实际上相当繁琐。如果这个时候来一个发动态的场景，聊天的场景，对产品原有逻辑的侵入性太强，按我的话说，就是不优雅。更好的产品方案是只做全局的切换，理论上就是一个快速登出再登录的快捷方式。

为了及时的互动，在任何一个真身和马甲上都汇聚了未读消息。作为真身就是真实用户，所谓马甲就是给这真实用户配的一堆小号。马甲一方面服务于调性，主动发一些我们期望用户按葫芦画瓢来跟发的特定类型的内容，另一方面就是去和真实用户互动。互动可以是给对方简单点赞，也可以是更有人情味的评论鼓励。在社区里，其实是最能体现人性互惠心理的，你给一个陌生人评论，对方一般也会给予回复，一来二去氛围就起来了。当别人给你互动时，及时地给予对方反馈无疑是最有效的。于是我们就设计了，无论你在真身还是在马甲上，只有有人和你互动，都会把消息数透传出来，你点击进入马甲列表就能看到哪个马甲有消息。这样就可以让你及时切换到对应的马甲上去处理。

让运营一眼识别出谁是真用户谁是马甲，好钢用在刀刃上。在产品设计时，我们就考虑到社区运营不止一个。如果把马甲和真用户混在一起就傻傻分不清楚了，到时候马甲彼此间是玩嗨了，真用户却受到了冷落。如何去标识新用户，也是个值得考量的细节。小中一开始想要不给用户加个徽章标记什么的。大中一看就觉得不妥，又是一种UI侵入性过强的设计，在某些场景下增加了布局的复杂度。最后，我们只在用户名字体颜色上做了文章，对空间无破坏。

2. 话题

上一节我们说马甲，它的作用是发一堆预先规划好的动态和评论来达到保持社区调性的目的。这一节我们要说保持调性的另外一种手段：话题。社区的调性有多重要，相信你也看出来了，我们反反复复通过不同产品功能设计来支持调性的落地。

对于UGC社区，如何引导用户产生内容是有讲究的，比如知乎是通过问题来引导领域专家来给出回答。这一点上我们其实主要借鉴的是微博。好吧，我承认运营妹子老来问我：”大中叔叔你到底想做朋友圈还是微博呀？“在这个时候，我的回答是：我们是用了县域人民最熟悉的朋友圈的形式，做了县城的微博。

在一个以表达生活状态为主的社区里，类似”今天穿什么“，”美不美晒大腿“这样的常规性话题会比较受欢迎。有一句话怎么说的，有女人的地方就有男人。结合我们的业务，有两种类型的话题特别有效：一类是和线下活动结合的话题，比如：”XX请你来K歌“，这个XX可能是官方的运营人员，也可以是网红； 另外一类是和商业稍作结合的话题，比如”最美老板娘“，截止到现在为止最多评论的动态来自于这个话题。下面是放福利时间：

产品设计上，我们在用户发布动态时直接让用户选择话题；在信息流顶部显示热门话题；在动态里可点击进入相关话题。这些功能都中规中矩，产品经理的最大价值往往是去决定做什么。

3. 积分

在社区运营中，我们时常会思考一个问题，如何激励用户活跃。方法有很多，最有效的是送粉丝，其他的还有活动物质奖励，常规保底的则是积分机制。

和马甲一样，我们期望给用户最快的积分反馈，所以把积分的发放做到了app上。无论是动态还是评论都可以快速操作。这里有个小细节是：如何避免多个运营重复奖励同一个动态或评论？ 我们在奖励界面上给出了次动态或评论的奖励记录。考虑到无需过于频繁的给予用户积分奖励，在界面上也显示了改用户近期的积分奖励记录。

用户的首次互动都会自动奖励积分。互动包括发动态和发评论和点赞。那么，给予多少积分合适呢？

有两个角度来考虑这个问题：

1. 从积分货币价值的角度来说，1个积分相当于1元RMB比较合适，这样手机满十几个积分基本就可以兑换出小物品了；

2. 从运营持续相对高频次地激励用户的角度来说，1积分相当于1毛或1分比较合适。

如何让新用户感知到互动可以拿到积分？小中说我们把奖励的积分直接显示在动态或评论旁边吧。如果我们设计的是网页产品，我觉得这个方案也是可以接受的，毕竟页面空间大，但是在移动端，这样的设计基本不可取。于是，我们在首页信息流的顶部增加了一个单独的跑马灯，这个跑马灯既适合曝光优质的内容点击进入，也完成了向用户教育好内容会有积分奖励的政策。

4. 消息

如果你去观察社区性质的app，它们往往会把”发布“和”消息“提升到一级导航里面。这种设计其实是为了让用户得到一个最短路径，无论是发布内容还是互动。那么如果把”消息“放到个人中心里面去会如何呢？那就意味着你需要经过两次透传，繁琐自不待言。我们也正是考虑到了这一点，把消息放到了一级入口。

为了让社区里的人及时互动起来，我们就需要以消息的形式提醒用户去关注和他有关的任何风吹草动，比如他的动态被别人点赞评论了，他的评论被别人回复了，甚至是他的动态里的A的评论被B回复了也要消息通知。

对于低活跃用户，消息可能还不够，必须加上push。

在我们冷启动的时候，我坚持做一件变态的事情，真实用户的每发一条动态就要发push到运营同学的手机，让他收到消息后就点赞，评论，给奖励，做完整套服务。开发同学在接到这个需求的时候觉得好夸张，说我都不考虑运营同学的感受，我就怼了一句，这么重要的冷启动过程，只有用户的体验是要充分尊重的，我们自己没有体验可言。等过了冷启动阶段，可以再考虑取消，比如部分老用户发动态就用不着push了。

总结一下

1. 马甲为社区调性打底料，app上切换互动全天候更方便更及时；

2. 话题是给运营真正的抓手，数据爆点都从这里出；

3. 积分是保持用户互动的长效产品机制；

4. 消息通知是社区互动的基础设施。

正如我在面试产品经理时聊到的，社区产品的第一个迭代需要相对完整，小步快跑不适用于冷启动阶段。你可以把优质内容的沉淀展现留到后面的迭代里，也可以把发小视频功能留到后面的迭代里，你却不应该把马甲留到后面的迭代里，社区冷了就难再热了。