編輯導讀：互聯網用戶高達十億，但大多數用戶都不具備高成本的長文章創作能力。垂直興趣社區更多是聚焦于某一個內容的建設，會更注重用戶的活躍度和反饋分享，所以進行短內容化改造是大多數社區的發展方向。

本文作者結合實際項目，分享了垂類興趣社區進行短內容化改造的經驗與思考，供大家一起參考和學習。

最早思考短內容化是在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協議