本文內容為社區類APP的完整原型設計思路及文件，對于產品及交互很有參考意義，推薦大家學習。

目錄：

• 版本應用內更新（可支持灰度、A/B TEST測試）
• 發布圖文功能
• 自建敏感詞管理

版本應用內更新

APP應用內更新提醒是個基建功能，APP剛做的時候就可以開始規劃進去，這個功能開發時間比較短的，服務端大概半天，兩個客戶端半天，測試半天就好了。應用內更新提醒主要目的有兩個。

第一個目的是把新功能快速覆蓋到所有用戶，比如雙十一來了，而老板臨時在十月中旬給了個新的業務需求，把審核時間都算進去后發現，用戶能下載的時間是十一月八號，這個時候就需要應用內更新去提醒用戶，不更新沒有這個功能。

第二個目的是針對某些特殊的機型解決Bug，碰見最多的是iOS9以前的系統，這類用戶是iPhone4代或5代的手機，安卓就更多了，有些特別老的機型或系統兼容不到，就會出現bug。用戶通過客服反饋過來，產品經理收集給研發，改好了以后不能立馬發新版本到市場，所以應用內更新提醒就可以指定給這些用戶，專門指定使用這些機型的用戶發布新的版本，他們通過更新去下載已經解決了問題的包即可。

一、功能結構

二、客戶端原型

客戶端需要注意的問題有：

1. 是否提醒？

拿當前版本和推送消息的版本對比，如果推送的版本號高則彈出更新提示，如果當前版本號已經是最新了，則不彈出提示；

2. 有國際版的應用

產品訴求是判斷用戶APP當前的語言類型，去推送對應語言的更新提醒；

3. 可選更新

可選更新每天只提示一次，用戶可以點擊“關閉”按鈕關掉提醒彈框；

4. 強制更新

用戶打開后就提示，隱藏“關閉”按鈕，用戶不更新就無法進入APP主界面；

5. 指定用戶更新

這里有一個問題要考慮進去：如果指定的用戶沒有登錄怎么辦？用戶沒有登錄程序就沒法知道是要推到哪個設備上去，一種做法是用戶沒有登錄就不提醒了，另一種做法是在一開始設計APP的時候，就把硬件設備號和用戶注冊的賬號捆綁一下。這樣就算用戶沒有登錄也能推送到指定賬號捆綁的硬件設備上。

把賬號和硬件設備捆綁還有一個長遠的好處是用戶賬號安全，如果賬號切換到別的設備登錄時，硬件設備號對不上，程序可以判定賬號為盜號，這個時候需要注冊的手機號或郵箱去驗證身份。當然這里會誤傷有多臺設備的人，比如測試的妹紙（真實的用戶只有少部分人有多臺設備的）。

6. 哪里下載更新的包

iOS的更新包需要跳轉到app store去下載。這里產品經理要注意一個問題：APP審核通過并在app store釋放后，服務器會有一個小時左右的延遲，所以此時如果去發布應用內更新提醒的話，用戶從我們APP跳轉過去的時候狀態是不對的，也會出現更新失敗的情況，所以iOS的應用內更新要晚至少一個小時才發布。

安卓的應用內更新不新包不走市場的服務器，是走我們自己的服務器，所以包要先傳到自己的服務器上面，從自己的服務器下載，安卓在發布更新前只需要保證好新包傳到服務器即可。另一點需要注意的是安卓的下載頁面是可以自己定義的，可以寫成一個新頁面、可以寫成一個彈窗、也可以只在狀態欄顯示下載進度，根據自己的需要來吧。

三、管理后臺

管理后臺分兩個部分，第一個部分是已經添加過了的版本記錄，如第一張截圖顯示；第二個部分是發布版本的頁面，每個字段必填，版本號需要按照研發給的新包版本，有個交互要注意的是，選擇全部用戶時，更新選項可選更新和強制更新都可以選，選擇指定用戶時就只能選擇強制更新，道長經歷的項目是這么做的，小伙伴們可以結合自己的需求去規劃。

指定用戶組這個問題，產品經理在自己的APP剛開始規劃時最好考慮進去，根據自己的業務把用戶分組，比如設計到買賣類的就需要有一個復購率、客單區間、地區等的分組；社交類的就可以看活躍情況、發布動態、寫評論等行為的頻次去分組，給這些用戶打不同的標簽，特別有利于新功能的灰度測試。

發布圖文動態

一、功能結構

發布圖文的功能結構相是比較標準的，只要有這個功能的APP，大家都大同小異，不同的可能是誰的特效更多一些。

二、客戶端原型-路徑一-從手機相冊選擇照片

路勁一的原型是用戶直接從相冊選擇照片，如果用戶在截圖第四張里面點擊照片，可以跳轉到后面的路徑二里面去編輯照片。

社區類的APP大多數做發布這個功能的時候做的挺粗糙的，很少會想到去利用這個頁面的空白地方，微博發布的時候會在頂部顯示廣告。那我們自己在做的時候心理一定要有這個思考，為APP或者發布動態這個功能帶來增長，不管是老用戶的活躍還是新用戶的留存，這里都比較關鍵的。

道長在設計的時候頂部設計了一個廣告，這是鼓勵用戶多發布動態的一個示范，通常情況下，運營人員的KPI會有發帖量的要求，通常大家都是怎么做的呢？一種是APP內私信用戶發布動態可以的積分；一種是通過勛章或頭銜鼓勵用戶發動態；最土的一種是組件一個用戶群，然后里面發禮物鼓勵用戶，這種方法受眾面很窄，其實不值得長期運營。

那我們就可以在“發布”動態的這個頁面鼓勵用戶參與發布，某種程度上來說，對用戶“發布”這個動作有臨門一腳的促進作用，道長在原型的下方描述里面有提到要考慮好用H5做，H5不用發布APP版本，隨時能夠配合運營活動的修改，這里產品經理要重點關注。

三、客戶端原型-路徑二-拍照&照片編輯

拍照一張頁面就搞定了，如截圖里面的第一張，用戶拍照完如果不需要使用后面的美化功能的話，直接點擊第二張圖導航條右上角的“下一步”把圖片插入動態發布的頁面。用戶如果使用美化功能，則會需要用到后面的頁面，用戶可以在任意一個頁面點擊“下一步”完成照片編輯并使用照片。關于濾鏡這些功能和邏輯這里不再多說，自己可以先列一個需求框架，你們的產品需要什么樣的功能去滿足用戶發布照片的需求，然后在跟進框架去理出來即可。

敏感詞管理

敏感詞的管理方案建議采用第三方的，比如阿里云或者網易云盾這些專門解決敏感詞和敏感圖片的服務，初創團隊不建議自己去做這么大的工程，自己做的投入產出比真的很低。我們自己開發，最多能做的好文字的敏感詞部分。圖片就很難做到了，涉及到圖片識別和算法的東西，比如一張裸露或者是領導人照片被用戶拿來做頭像了，我們自己做的敏感詞解決不了，這些對產品都會有傷害，也會帶來法律風險。后期產品做的比較大后再考慮自己做，但一般的實際情況是，都是用第三方加自己開發的配合在一起使用的。

道長經歷過的小項目使用如下的兩個處理方式：

方式一：客戶端處理提示用戶修改

用戶寫評論提交內容的時候，把內容里面的敏感詞檢測并標記出來，彈出操作面板讓用戶編輯或刪除，如果用戶不修改則不能提交評論內容，把該功能寫成一個單獨的模塊，APP的用戶昵稱、簽名、動態等等都可以用，流程和原型如下：

用戶在提交的時候把內容先和敏感詞庫匹配，檢測到就高亮標記出來，讓用戶去編輯或刪除后重新提交，如此重復的檢測、修改、提交，這個方法用戶有抱怨過，造成的問題是使用起來感覺有點不近人情，另外檢測效果完全取決于自身的語料庫有多豐富和技術實現方式。

敏感詞庫匹配一種是直接從服務端查找，帶來的問題是服務端開銷大、檢測速度慢，每次都要拿用戶提交內容去和整個語料庫對比，可以想象我們服務器的成本和用戶使用的速度是極其低的。

另一種方式是每次用戶打開APP，判斷用戶是wifi環境時，都把服務端的語料庫下載到APP本地的數據庫，用戶提交的時候只需要和本地的語料庫對比就行了，我們發現效果也不是很理想。

方式二：隱藏敏感詞內容

用戶提交內容的時候服務端做校驗，如果有敏感詞則把敏感詞替換成星號，用戶發布時不提醒，提交成功顯示的時候把敏感詞部分替換成星號。該方案對用戶來說操作門檻最低，但體驗不好的地方是用戶不知道自己犯錯了并且會造成內容不完整。流程和原型如下：

敏感詞后臺原型：

敏感詞后臺基礎版本是這樣子的，可以按照自己的需要增加一個導入表格的功能，我們因為前期準備了大量的表格，直接開發的同學在數據庫里面導進去了，就不需要再網頁上在做這么個功能，后期需要添加一個就添加，也不會出現一次需要手動添加幾百個敏感詞的場景。

好了，第二期原型分享到此結束，下一期是積分商城，比較龐大。

相關閱讀：

第一期：某社區APP完整原型案例（附源文件下載）

產品經理課程：APP產品經理入門實戰課程（交互、原型、方法論）

……………………………………………… 我是美麗的分界線 ………………………………………………

如果你想獲取文中原型圖源文件，請關注起點學院公眾號（ID：qidianxueyuan666）回復關鍵詞“666”獲取下載地址。

如果你想跟我交流原型設計技巧，歡迎加QQ群：159912926

#專欄作家#

芒果道長，人人都是產品經理專欄作家，起點學院特聘導師。騰訊課堂【30天教你做一個APP】作者。

本文獨家首發于人人都是產品經理，未經本站許可，不得轉載，謝謝合作

題圖來自 Pexels，基于 CC0 協議