编辑导读：互联网用户高达十亿，但大多数用户都不具备高成本的长文章创作能力。垂直兴趣社区更多是聚焦于某一个内容的建设，会更注重用户的活跃度和反馈分享，所以进行短内容化改造是大多数社区的发展方向。

本文作者结合实际项目，分享了垂类兴趣社区进行短内容化改造的经验与思考，供大家一起参考和学习。

最早思考短内容化是在19年的微信公开课，听到张小龙关于微信积极拥抱短内容化的反思，而后真正在自己产品落地进行短内容化是到了今年年初了，当时整个团队出现2种声音：

第一种是觉得短内容化可能不太适合汽车垂类的内容社区，因为绝大多数用户来汽车社区是为了找到对我有购买决策帮助的内容辅助我进行买车的，而碎片化的短内容更偏娱乐化的属性，没有太大的价值。而另外一种声音觉得，移动端场景下，用户很难在手机端上进行大几百字的长帖写作，我们这样做导致创作转化率极其低下。

我是后者观点的积极推动者，于是我决定用实验数据来进行说话。

一、对现有业务场景梳理

有车以后-UGC样式

最早的有车以后定位是一个汽车垂类的媒体平台，所谓的媒体平台就是拥有PGC、OGC、UGC的综合内容集合体，就像汽车之家、易车、懂车帝等，拥有各种各样的样式，在过往的几年发展里，因为对社区业务的不断探索，先后有不同的产品经理负责社区内容详情页，导致了内容详情页样式的多样化。比如像参考传统论坛结构的图文混排长帖、参考微博的短动态、参考抖音的短视频等。

很长一段时间里，因为业务高速增长，大家一直没有停下来很好的思考为什么要这么去做这种页面的设计，更多是觉得其符合这个业务场景出发，忽略了整体产品的全局考虑。

有车以后-UGC编辑器入口

有展示页面必定有发帖页面，作为内容平台不同内容业务模块，就会有不同的一级落地页，与之匹配的是一级落地页中UGC编辑器入口的不一样，因内容详情页样式的多样化将导致了发帖入口选择过多，用户不知道应该选择什么样的编辑器。

这里需要站在用户的角度考虑：图文、短动态、长文等一系列的概念都是平台的定义，对于用户自己来说，他只是想单纯的分享内容，不会去思考你对内容的定义背后代表着什么。因此光从凌乱的入口有可能就劝退了一大批用户。

二、对现有问题分析

对于内部：过去一直基于最早的论坛来进行迭代（而我们一直照着竞品等来对标，却忽略了我们压根没有PC时代遗留的包袱），当运营来回更换提各种需求，产品也没有充分的时间去做一个大局观思考，基于一波流的功能迭代的思维来工作，导致大家一直在做功能的加法。

对于用户：用户只会去关注内容质量，在乎阅读体验和阅读效率，而不在乎呈现的形式（在用户的眼中：车主口碑和提车日记的长帖本质都是内容），因此从内容生产角度考虑：一个用户要发内容，不应该给他这么多选择（他是分不清什么是长帖、什么是小视频、什么是短动态，这些都是我们产品自己的概念），需要做精简。

从内容分发考虑：既然整个产品是扎根UGC的产品，那么内容应该是无处不在的，只是通过一定的联系用产品功能把内容串联起来，比如说：车系详情页（与车相关的所有PGC、OGC、UGC内容）；车友圈详情页（车系分论坛，与车系有关的所有UGC内容，包含口碑）；话题（以一个主题串联UGC内容）；APP、小程序首页（以用户感兴趣串联起PGC、OGC、UGC内容）；车友圈首页（以人工精选串联起UGC内容）。

从内容品相考虑：从列表阅读美观性我们也不应该在一个列表里面出现各种各样的内容，就像小红书从头到尾只有笔记没有别的类型帖子，长帖+短动态+视频+问答的穿插会造成用户的视觉疲劳，我们应该在产品上克制，做减法，帮助用户筛选出值得阅读的内容，而不是一股脑的都列在上面让用户选择，他们才没有这么多时间。

三、对内容详情页展示形式的改造

改造后的详情页初版

我们当时基于了市面上主流的移动端社区进行研究，发现其实每个产品的设计都大不相同。像老牌的社区因为是从PC时代过渡而来的，其社区氛围、用户构成都是偏年长的用户，因此他们习惯于使用PC端发帖，PC和移动端是共享的内容数据，因此会发现他们的APP端也是长内容为主。

像马蜂窝早期是PC后来在移动端发力，于是它是即夹杂着长内容、又有部分短内容。而像小红书、得物、一兜糖、穷游等APP，其本身兴起于移动互联网时代，没有PC，所以基本上是短内容偏多。

那我们当时基于的锚定点是参考小红书，首先汽车类社区与微信朋友圈、微博等偏碎片娱乐化的社区不一样，80%以上的用户进来是为了基于效率查找，解决买车、用车问题的。过短的内容载体会让内容价值本身有影响，过长的内容又会使生产端门槛过高，影响创作转化率。

而小红书偏笔记的这种内容展示方式，从最早期境外购物，到现在覆盖旅游、美妆、探店、学习各种各样的内容，都可以进行承载，买车本身过程其实就是查阅一个一个其他用户买车用车过程的经验分享，于是我们选取了上图下文这种样式作为了对比实验的实验组。

通过对内容详情页50%、50%的AB版本测试，在长达一个月的观察中，我们发现改版前后人均阅读时长、和评论人数占比有了几何倍的提升，于是决定采用了新版上图下文的样式，全量了新版方案。事后我们进行复盘：在移动端大背景的前提下，重图下文的样式更适合移动端短动态的阅读习惯，而展示效率的提升可以进一步促进用户的互动。

四、对内容列表样式进行改造

帖子列表聚合样式

整体内容平台短内容化的改造是从内到外的，进入第二阶段之后是对列表的详情页进行改造。当时对比了几个汽车垂类的竞品，做了些思考：

1. 短动态并不是有价值内容的呈现方式，当短动态与长帖交叉在同一个列表就会显得杂乱，像我经历过买车过程，我要找有价值的内容从来不会看短动态。
2. 用户的耐性是有限的，所以好的内容一定要第一时间呈现，不要让用户去找。小体量的社区如卡本、好好住采用小红书化的布局能突出图片弱化文字，页面布局十分美观。
3. 不管是话题还是车友圈本质都是以一个关键字来把同属性的内容串联在一起。

改造结论：

1. 车友圈和栏目类话题，我们应该只有图文长帖，短动态只在活跃类话题出现。
2. 列表里面弱化无用信息，做到极简，倒逼文字升级（如正文概括）。

改造预估效果：

1. 列表更美观，分发效率更高，可阅读性更强。
2. 以产品的克制倒逼图片质量升级。

这里我们上了第二期的AB实验，通过对某一端进行50%，50%的AB版本测试，通过不同业务场景下的列表展示控制，做了版本、业务场景双重变量的实验，最终得出了一个结论：“在逛的场景下，强调图片的瀑布流CTR会更高，而在带有某一种目的进来查找信息的情况下，信息流的CTR会更高”，于是我们在社区话题这种闲逛的场景采用了瀑布流设计，在车系车型专区这种快速结构化信息搜寻的场景使用了信息流的设计。

五、对UGC编辑器的改造

最后是对编辑器的一个改造了，原来的发帖流程里面，存在了很多的问题：

1. 发帖缺乏引导，用户直接进入编辑器可能会一脸懵逼；
2. 会有许多硬性条件，比如说标题必填而且要有字数下限；
3. 不同形态的内容详情页对应了不同形态的UGC编辑器，用户分不清在不同界面编辑器下操作产生不一样的预期效果，只能通过文字和经验来做区分。

新版编辑器改造

对于改造，我们先思考了整体用户使用路径和日常场景。首先，作为一个垂类汽车社区，UGC生产者不会像发朋友圈一样，快速发布自己的动态进行分享，那个是碎片化社区做的设计，而我们定位更多的是一种买车用车经验的分享，它是一种价值类的信息，因此是高于碎片化短动态又低于pc长文的，有点像小红书的笔记。

并且整个社区其实还没有壮大，不能全面放开自建话题，不然整体调性和氛围都很难有高质量的把控，话题由平台控制，我们根据全网数据创建了买车、用车用户最感兴趣的9大话题，以及1500+日常和车有关的话题，因此用户发帖的时候其实他大概率是已经知道自己要发什么内容了。

所以我们把选择图片、视频放在了前置，填写文字与选择车系专区和话题放在了后置。从门槛来说，选图总是比码字门槛要低，而选好图无疑是提高了用户的沉默成本，降低用户流失率。

因此功能核心变化点是2个：

1. 弱强制，重引导，避免发布挫败感
2. 先选图，再写文，顺畅发帖流程

通过对整个发帖流程进行sdk打点，进行转化漏斗分析，然后逐步攻克每一个坏点，改版发帖方式，来降低整体发帖门槛，提高生产效率。最终整个社区大盘的UGC发帖转化率有了明显的好转。

尾声

短内容、富媒体，我相信不管现在还是未来会是移动端很长时间的一个趋势，积极拥抱变化，不能等到时代和用户把我们淘汰。但是并不是所有产品都适合短内容、富媒体，我们最终还是要结合用户使用场景，以实际出发来做相对的适配。别忘了，真正给用户提供价值的是内容本身的质量是否对用户有帮助，而不是内容展示的形式。

本文由 @罗舜伟 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议