在當(dāng)今快速迭代的互聯(lián)網(wǎng)產(chǎn)品領(lǐng)域，社交App作為用戶日常生活中不可或缺的一部分，其設(shè)計細節(jié)和用戶體驗至關(guān)重要。本文作者憑借多年的產(chǎn)品設(shè)計經(jīng)驗，從產(chǎn)品經(jīng)理的視角出發(fā)，總結(jié)了27條關(guān)于社交App項目的產(chǎn)品設(shè)計經(jīng)驗。

產(chǎn)品經(jīng)理常常很快就把原型畫出完了，但是在設(shè)計UI的時候或開發(fā)的時候就常常被拉去澄清細節(jié)。

原因就是對設(shè)計的細節(jié)交代不清楚，或者了解的不甚深入，缺少對邊界或排他項的界定。

筆者將社交App項目做下來后，整理如下見解。

本文就移動端App產(chǎn)品的日?？偨Y(jié)，從產(chǎn)品經(jīng)理設(shè)計需求的角度，分享一些注意事項和細節(jié)如下。歡迎批評探討。

1、明確App的按鈕類型

從定義需求的角度來說，產(chǎn)品經(jīng)理只要交代了哪里是按鈕就可以了，可以通篇一律使用同一個按鈕線框表達。

但是這只能是個初稿，在落實之前，產(chǎn)品經(jīng)理或交互設(shè)計師需要確定按鈕的具體形態(tài)。

一般而言，一個APP的按鈕設(shè)定四種就夠了，設(shè)置的維度可以是按鈕的定位權(quán)重。（注意，菜單的入口或圖表不包括在本次討論中，比如微信的+、定位圖標(biāo)這種）。

1. 權(quán)重最高的按鈕：這種按鈕一般比較大，顏色明顯，主題鮮明。常見的比如用戶“登錄”按鈕；
2. 中等權(quán)重的按鈕：這種按鈕在產(chǎn)品中最為常見，比如一般的詢問框上的【確定/取消】按鈕；
3. 權(quán)重最小的按鈕：比如“關(guān)閉”、“查看更多”按鈕。這些按鈕的作用就是可以點擊，用戶看得到即可。這種按鈕形式多樣，可以沒有框，只有文字。也可以只是個圖形，比如關(guān)閉按鈕用x表示；
4. 特殊按鈕，這種按鈕區(qū)別于其他的按鈕，少且特別。要么是帶很多文字，要么是App的核心入口，比如soul首頁的“靈魂匹配”按鈕。

在輸出的需求文檔中，可以一開始在“全局規(guī)范”中就定義這四種按鈕代號，然后在原型中備注按鈕類型的代號。

這樣設(shè)計就知道你是要怎么樣的效果了。

2、了解第三方登錄的本質(zhì)

社交類App登錄方式，基本都是手機驗證碼為主，配合第三方登陸，很少注冊賬號密碼（與App的定位和用戶群有關(guān)）。

第三方登錄就是借助第三方應(yīng)用的接口實現(xiàn)用戶登記，比如常見的三家：微信、QQ、微博。

其目的之一是關(guān)聯(lián)賬號，形成社交群落之間的呼應(yīng)，有利于用戶生態(tài)鏈的搭建；其二是獲取用戶的一部分已有信息，比如用戶信息或流量資源。需要注意的有兩點：

（1）第三方賬號給的資料完善度和安全性不好把控。比如你期望獲取QQ中的頭像、昵稱、年齡、地區(qū)，但是QQ可能只給你頭像和昵稱。

又比如有一天第三方封了接口，那么第三方登錄功能就停擺了。

（2）第三方登錄方式，對用戶來說不一定就是省時省力的渠道。因為相關(guān)法規(guī)的要求很多APP是需要用戶手機號的，而第三方登錄并不能獲取用戶已經(jīng)提供給第三方的手機號（用戶隱私）。

因此對用戶來說常常是使用第三方登錄后，仍然要跳轉(zhuǎn)到驗證手機號的界面，還不如直接使用手機驗證登錄。

3、我們常見的支付功能的貓膩

支付很常見，社交應(yīng)用的虛擬禮物購買、知識平臺的付費學(xué)習(xí)等。在設(shè)計支付功能的時候，主要注意的是要從安卓和IOS兩個系統(tǒng)的角度區(qū)分設(shè)計。

（1）首先明確一個常識，就是支付必須是有資質(zhì)的支付平臺才能進行操作處理。

這就是為什么很多大的電商公司的交易要經(jīng)過支付公司的結(jié)算才能拿到錢，比如paypal、騰付通、支付寶、微信支付、網(wǎng)銀在線等。其中安卓手機最常用的是支付寶或者微信。

（2）安卓系統(tǒng)接通第三方支付體系還是比較友好的，手續(xù)費也不高。調(diào)用支付寶或微信支付，會返回其綁定的銀行卡或者余額，可以作為業(yè)務(wù)數(shù)據(jù)保存在后臺。

有時候前端感受不到這個數(shù)據(jù)，產(chǎn)品經(jīng)理應(yīng)該知道，作為功能擴展的考慮因素。

（3）蘋果手機（IOS系統(tǒng)）正常來說只能調(diào)用蘋果支付，蘋果順帶扣的手續(xù)費比較高。

虛擬支付的時候，安卓是可以使用任意金額充值的，但是蘋果手機對特定的原幣，只能選擇固定的金額。

這個是因為蘋果公司將充值金額本身固定了，當(dāng)成一個一個的商品對外出售。

如下圖就是蘋果提供的清單，比如可以購買的價格列就是需要支付的金額，收入列就是扣掉手續(xù)費之后有效的金額?？梢钥吹交?元錢，在蘋果這里只剩下了4.12元。

這就是為什么陌陌同樣是充值6塊錢，安卓系統(tǒng)給60個虛擬幣，蘋果只給42個幣。

4、了解后臺數(shù)據(jù)的存儲

做APP的不僅要盯住頁面和用戶，也要理解數(shù)據(jù)的運作，這樣對內(nèi)容推送機制、數(shù)據(jù)搜索的頁面展示的方案選型幫助很大。這里介紹三點：

（1）初創(chuàng)公司的數(shù)據(jù)基本都使用的云端存儲，同時配合自己的數(shù)據(jù)庫。從效率和安全性上都會更有保障。產(chǎn)品經(jīng)理需大概了解數(shù)據(jù)存儲的定位。

以視頻直播類為例，直播或視頻數(shù)據(jù)文件占存比較大，一般都是存儲在云端的，而用戶業(yè)務(wù)數(shù)據(jù)放在自己的服務(wù)器的數(shù)據(jù)庫中，原因很簡單這些牽扯更多的隱私和安全責(zé)任，且一般數(shù)據(jù)不會太多。

（2）產(chǎn)品經(jīng)理需直觀地理解關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫。比如非關(guān)系型的mongdb數(shù)據(jù)庫，一般存儲信息量大的不定型數(shù)據(jù)，比如用戶日志。而MySQL則承擔(dān)了大部分可以用二維表表達的規(guī)則的數(shù)據(jù)，比如用戶資料、數(shù)據(jù)字典的參數(shù)配置等。

（3）數(shù)據(jù)存儲與頁面的搜索方式等方面都有很大關(guān)系。比如，在“我的好友”中搜索用戶昵稱，是只搜索自己關(guān)系為好友的用戶，還是搜出有一部分是好友，另一部分非好友的用戶并用標(biāo)簽分類呢？

這兩個方案前者比較保守，但是如果期望用戶擴大社交圈的話后者更有價值。因為不僅可以看到好友并且還能提供增加陌生人為好友的功能。

但是這時候還要結(jié)合后臺數(shù)據(jù)的存儲，是否好友和陌生人存儲在一個表里了呢，如果分開了那最好就不要一起搜索，隨著用戶量增大，聊表查詢很耗性能。

5、了解前后端接口

項目過程中，前端與后端開發(fā)之間溝通需求基本都是圍繞接口請求數(shù)據(jù)進行的。接口是前后端分開開發(fā)的行業(yè)標(biāo)配嗎，是高內(nèi)聚的體現(xiàn)。

因此產(chǎn)品經(jīng)理要理解接口的原理和自己的目的，協(xié)助前后端完善接口的定義（另一篇文章有專門介紹）。

后端開發(fā)在寫接口的時候，一般需要知道未來的走向，包括數(shù)據(jù)量級、功能擴展性等。

產(chǎn)品經(jīng)理要針對該功能給開發(fā)們說清楚未來的擴展可能性。比如：App的用戶動態(tài)的評論，計劃是展示一部分優(yōu)質(zhì)評論內(nèi)容（類似微信的朋友圈）在外層，類似下圖：

但是對于展開部分的算法尚還在研究階段，因此這個版本將評論折疊，只顯示數(shù)字。點開則打開評論列表。

后端在給前端傳的接口中，可能會多設(shè)計出“是否展示在外層”標(biāo)識，提前預(yù)留參數(shù)，以后版本用。本版本前端只需填留下自己需要的信息即可。

6、圖片比例、圓角和縮放的注意事項

App用到圖片的地方很多，每一處又可能有不同狀態(tài)下的不同表現(xiàn)形式。產(chǎn)品經(jīng)理不能只放一張圖了事。應(yīng)當(dāng)對圖片不同場景下的樣式列舉清楚。比如下面幾點：

（1）縮略圖的縮放比例

微信朋友圈的列表中，圖片都是縮略的。那么設(shè)計的時候首先就是縮略方式的問題。

之所以要給出縮小的比例或最終尺寸大小，是因為拍攝的手機屏幕尺寸和比例不一致，上傳的圖片又可能有各種形狀。

因此發(fā)布之后要給予對應(yīng)的規(guī)則和秩序。避免效果模糊、展示不全、圖片過小等不良效果。

在確定方案的時候，合理即可?？梢酝ㄟ^研究競品，找近期流行的產(chǎn)品的規(guī)律。比如：

按圖片或視頻的H:W:

①H:W>4/3(高圖）：切上下兩端，保存為4/3，靠左展示。

②3/4≤(H:W)<4/3之間(方圖）：切成正方形，靠中間展示。

③H:W≤3/4(扁圖）：切成3/4，靠中間展示。

以上并不一定是最好的，但是秩序是要給到開發(fā)的。

（2）圖片的圓角和直角

留意的話，就會發(fā)現(xiàn)有的App的圖片是圓角的有的是直角的。

目的只有一個，就是確定這兩種展示方式哪種更符合產(chǎn)品的定位和氣質(zhì)。

一般而言，做社交類的產(chǎn)品，圖片用圓角看著舒服和氣。做技術(shù)類的或者法律類的比較嚴(yán)肅的產(chǎn)品，可以考慮直角。

最后還是一句話，看競品，以及一段時間流行哪種。

（3）大圖和縮略圖

消息發(fā)送成功之后 ，圖片也是縮略的。并且要設(shè)計發(fā)送失敗的提示圖例。點擊打開之后大圖是否鋪滿整個窗口？

最后就是不要忘記做縮略圖和大圖，這是完整的一套。

另外在很多公司，這個算是設(shè)計師方面的工作，但是產(chǎn)品經(jīng)理要全局把關(guān)，就要知其然知其所以然，不是主管覺得看著順眼就這樣吧。

7、產(chǎn)品經(jīng)理對視頻拍攝窗口的界定

產(chǎn)品經(jīng)理在設(shè)計拍攝視頻或圖片功能的時候，需要考慮是否滿屏拍攝，是否限制必須按一定比例拍攝等。

之所以考慮這個問題，是因為有的手機全屏比例拍攝的效果并不美觀。另外一些帶劉海的手機屏幕，劉海部位必然是看不到拍攝畫面的。

因此為了避免這個影響，很多產(chǎn)品就會選擇將上方平齊與劉海的高度遮住，設(shè)置成只支持劉海以下拍攝。

當(dāng)然，也有將底部菜單位置遮住的，還有的規(guī)則是只允許拍攝出指定比例的畫面，比如安寬度固定，取16:9的畫面作為視頻窗口，多余的部分在拍攝期間都用黑色背景遮住。

這種規(guī)則的制定有好有壞，屬于A/B選擇的問題。這個選擇，需要產(chǎn)品經(jīng)理來定。

產(chǎn)品經(jīng)理可以通過借鑒競品和分析本產(chǎn)品的定位，有理有據(jù)地說出自己的理由，支持自己的觀點即可。

8、將低頻功能放深一點，以便將高頻功能凸顯出來

以拍攝視頻后的貼紙為例，貼紙可以貼在視頻的指定位置，也可以應(yīng)用在視頻的某一時間段上。

但是根據(jù)調(diào)研，多數(shù)用戶使用的功能只是選擇貼紙、刪除貼紙和拖動位置。少數(shù)用戶才會花精力在手機上調(diào)整貼紙應(yīng)用的時間段，因為這個操作稍微有點麻煩。

但是畢竟還是有這么一小部分用戶是希望將自己拍攝的作品精益求精的，對此我們看如下方案：

方案一，在選擇貼紙的同時就展示出時間軸，讓用戶選擇貼紙和應(yīng)用的時間軸一次性完成。讓功能集中在一處開始和結(jié)束，干凈利索。

方案二，將選擇貼紙、刪除貼紙和拖動位置放在第一層。完成之后，再點擊該貼紙，彈出‘編輯’，這才進入時間軸的編輯。

很明顯第二個方案要好一些，一來提高了大部分用戶的操作效率，不被無關(guān)的功能干擾；另外也不會影響發(fā)燒用戶進一步挖掘極致。

這其實是整個產(chǎn)品設(shè)計的指導(dǎo)思想：考慮了復(fù)雜性和使用頻率，針對大眾用戶和極致用戶進行功能分離，最終實現(xiàn)完美的效果。

9、圖片上傳、壓縮等需要注意的細節(jié)

圖片上傳是APP離不開的功能，比如聊天消息、上傳照片做認證或頭像等。

提到圖片上傳，就離不開上傳的規(guī)制、發(fā)送或上傳成功的效果、點擊后的效果、發(fā)布失敗的效果、下載到本地的效果等。具體可以這樣分析：

（1）上傳的圖片文件大小和尺寸大小的要求：

在服務(wù)器承受的壓力之內(nèi)盡量不做限制，必要的時候才給予閾值。作為產(chǎn)品經(jīng)理，需要與開發(fā)溝通當(dāng)前的方案選項是否有限制的必要。

一般而言，可以由客戶端自行壓縮或調(diào)整后展示。

對于PRD，給不給上述限制都要交代清楚。

（2）限制一次上傳的圖片張數(shù)：

比如微信是9張，抖音12張。對于PRD，該限制雖小，但要交代清楚。

（3）上傳的圖片限制格式：

一般盡量不限制。作為產(chǎn)品經(jīng)理，需要與開發(fā)溝通當(dāng)前的方案選項是否有限制的必要。對于PRD，要交代清楚。

（4）上傳圖片后展示的效果：

一般都是縮略圖，固定顯示的長寬高。上傳失敗的圖片，支持再次上傳。

點擊上傳成功的圖片，打開大圖。

（5）若需要該圖片進行小圖標(biāo)或者展示形式的多樣化應(yīng)用，則后臺只需要保存原圖，其余的格式化應(yīng)用在客戶端進行定義。

比如頭像圖片在后臺存一張大圖，應(yīng)用層面展示的是原型圖。又比如送禮物的圖標(biāo)，選擇的界面展示的是大圖，發(fā)出去之后的消息通知可能就只是個小圖標(biāo)。

（6）圖片上傳的方式：

①第一種是九宮格式的

典型的就是微信發(fā)朋友圈的圖片上傳功能，這種圖片上傳功能適合上傳多張圖片，圖片的呈現(xiàn)方式一般都是九宮格的方式，在社交類，電商類的商品上傳和寫游記的app上多見。

多用于信息內(nèi)容的展示，一般都是圖文相結(jié)合。一般是先開啟相冊選取圖片，圖片的點擊順序也一般是最后的呈現(xiàn)順序。

②第二種文件上傳式

一般在聊天界面會用到這個功能居多，點擊qq和微信下方工具欄的加號都會有一個圖片上傳的功能，這種功能一般是基于聊天的場景，這部分圖片上傳功能展開的方式都是半浮窗的樣式，系統(tǒng)會先展示當(dāng)前相冊最近的幾張圖片，會有選擇是否發(fā)原圖的設(shè)計。

③第三種嵌入式圖片上傳

嵌入式圖片上傳一般應(yīng)用在文檔撰寫類的應(yīng)用，在編寫文章的時候需要嵌入一些圖片說明，這種設(shè)計時圖片嵌入屬于一種輔助文檔編輯的功能，一般需要去調(diào)取系統(tǒng)相冊，然后手動從相冊里選取出你所需要的圖片，可一次性上傳多張圖片。

④第四種添加附件

這種圖片上傳形式一般圖片會作為附件的形式上傳，也是調(diào)取系統(tǒng)相冊，一般上傳成功后圖片都是縮略圖的形式展示。

例如我們常用的寫周報和百度云盤里就常用到這個功能。這種設(shè)計的圖片上傳功能適合大批量的圖片上傳。

10、時間格式的定義

時間的顯示基本分兩類，一類是展示在外層的，不需要很精準(zhǔn)的時間，比如聊天環(huán)境下的時間、用戶動態(tài)外層顯示的時間；另一種作為嚴(yán)格的時間落款，比如賬單明細。

后者基本可以一刀切，就用年月日時分秒，一般都不是問題。

前者就要切合場景，對時間的要求和用戶情感的匹配性，融入一定的感情色彩或者暗示。這里就有多種流派，比如推特和微信就區(qū)別很大。

對于前者，筆者在這里整理一套自己用于聊天信息、評論、系統(tǒng)消息、動態(tài)的時間的展示規(guī)則，可以作為借鑒：

剛剛（T<1分鐘）；

XX分鐘前（1≤T<1h），比如53分鐘前；

XX小時前（1h≤T<24h），比如23小時前；

昨天 +點鐘（24h≤T<48h），比如 昨天 12：20。

日期+點鐘（48h≤T<1年） 比如：6-5 14:52，跨年則加上年 2018-12-9 16:21

年-月（1年≤T） 比如：2018-5

11. 請求設(shè)備授權(quán)可以更簡捷嗎？

用戶如果未開啟APP的設(shè)備授權(quán)，那么用到相應(yīng)的功能，就需要臨時提醒用戶授權(quán)。

比如點擊【抖音】的拍攝按鈕進行視頻拍攝，就需要請求攝像機授權(quán)。

如上圖，點擊“去設(shè)置”，則前往手機的【系統(tǒng)設(shè)置】界面手動操作。

相當(dāng)于App只負責(zé)告訴用戶：我需要你去設(shè)置中授權(quán)。

①若不同意，則放棄視頻功能的使用。

②若同意，則前往【系統(tǒng)設(shè)置】中，執(zhí)行獨立于App之外的操作。

操作完成，會發(fā)現(xiàn)連個返回APP功能都沒有，還需要自己找到App再進入一次。是不是很low？

為什么不能在App中一鍵完成授權(quán)呢？

這其實與手機操作系統(tǒng)有關(guān)系。

以IOS為例，手機操作系統(tǒng)對設(shè)備授權(quán)有一個規(guī)定：

安裝后，首次打開App，App會自動請求用戶進行設(shè)備授權(quán)。

僅此一下，之后打開App，操作系統(tǒng)就不會幫忙請求了。

因此，若首次未授權(quán)，或之后關(guān)閉了授權(quán)，那么手機系統(tǒng)不允許App直接一鍵授權(quán)了。

明白這個道理，設(shè)就可以設(shè)計出貼合實際的方案。需摸到操作系統(tǒng)的“屋檐”，適當(dāng)“低頭”。

12.頁面刷新加載的“蘿卜和泥”

刷新，是產(chǎn)品經(jīng)理需要定義的常見的功能。

要么是手動觸發(fā)刷新，要么是定時任務(wù)觸發(fā)。

定時任務(wù)觸發(fā)，比如1分鐘內(nèi)的消息顯示“剛剛”，那么系統(tǒng)就可以每一分鐘自動刷新一次，使顯示合理的時間格式。

本文主要以手動觸發(fā)說明，產(chǎn)品經(jīng)理至少可以考慮四個方面的問題：

①怎樣的觸發(fā)方式

列表頁面加載，主流觸發(fā)方式是滑動，包括上下左右滑動。

對于瀑布流的內(nèi)容為主的產(chǎn)品，刷新較為頻繁，除了使用滑動加載之外，還可配合按鈕加載。

比如【抖音】，可以雙擊底部菜單實現(xiàn)頁面刷新。

“滑動+點擊”這樣的設(shè)計，避免用戶置身于視頻瀑布流中只靠單一滑動帶來的枯燥和不適。

②打開新頁面加載的

刷新有打開新頁面的，也有在當(dāng)前頁面加載新內(nèi)容。

打開新頁面的，需要考慮如下：

a. 翻頁方向：目前流行的交互方式，是左右平移或覆蓋平移，比較符合用戶對線性操作流程的的直觀感受。

b. 加載發(fā)生在翻頁的前還是后呢？

翻頁前加載：適用于需要判斷及驗證處理的頁面中。例如表單信息判斷和登錄驗證等。

而絕大部分app采用翻過去之后加載，這樣可以極大的增強頁面的流暢感。

③設(shè)計loading標(biāo)示

a.loading標(biāo)示的樣式

菊花和進度條是最基礎(chǔ)的loading標(biāo)示。

若做成動畫，或者加入App品牌特色，就更顯誠意了。

 

 

b.loading標(biāo)示的位置

是在頂部、中部、還是底部呢？

若看不出優(yōu)劣，就選一種，并向團隊交代清楚。必要的時候做A/B測試。

④加載策略

在實現(xiàn)機制上，產(chǎn)品經(jīng)理要說清楚效果。

比如最遲不超過2s、要求某些內(nèi)容先加載出來等等。

這樣就引導(dǎo)出了常見的幾種機制：

異步加載、分模塊加載、懶加載和預(yù)加載等。

需要注意的是：加載機制不僅僅是受限于網(wǎng)速，更是信息泛濫時代的一種策略：

讓用戶優(yōu)先看到什么，節(jié)約用戶精力，提高回報率。

13. 【消息】模塊的設(shè)計

①消息歸類

在設(shè)計消息菜單的時候，需要考慮默認置頂、消息歸類等功能。讓目標(biāo)信息曝光增加，同時讓消息有條理。

比如，【互動通知】置頂在列表的最上方，類于“文件夾”。點擊，則打開系統(tǒng)消息列表。

②未讀提示：數(shù)字還是紅點呢？

一般而言，人與人的聊天顯示未讀條數(shù)，因為時效性要求高。

超過99條一般顯示99+。

實際顯示99也可以，對用戶而言已無差異。

非緊急的通知可以不顯示具體數(shù)字。

消息已讀的判斷標(biāo)準(zhǔn)：只要打開就算已讀。

哪怕眼前條只展出了1條，哪怕沒來得及看就手機掉線了，也都當(dāng)做已讀處理。

③刪除消息

分兩類，一類是單條聊天記錄的刪除；一類是整個聊天條目的刪除。

④消息保存時長

可以保存在服務(wù)器，用戶可以通過加載，分批查看歷史消息。

此外，考慮聊天消息的復(fù)制、轉(zhuǎn)發(fā)、失敗重發(fā)等。

14. Web在手機端的適配

產(chǎn)品官網(wǎng)，初期都很簡單，基本都是：產(chǎn)品介紹+下載鏈接。

功能不復(fù)雜，因此可以考慮設(shè)置手機訪問官網(wǎng)的功能。

如上圖所示，手機端直接訪問PC官網(wǎng)體驗極差。

因此需要一定程度的適配，大概會有以下幾種形式：

①極簡適配

極簡適配就是對內(nèi)容進行刪減，直到剩下最后一個頁面，用一個頁面去呈現(xiàn)最基本的產(chǎn)品介紹以及下載按鈕。

②完全適配

做了全適配的官網(wǎng)會在手機端有良好的表現(xiàn)。當(dāng)然，Pc端的官網(wǎng)有時候體量太大，在適配到手機端的時候也要有刪減。

15. 左右滑動切換Tab頁簽

很多App的Tab頁簽，支持左右滑動切換。那么是不是在設(shè)計Tab頁簽的時候都要這樣規(guī)劃呢？

筆者認為在確定這個方案時，產(chǎn)品經(jīng)理需要考慮如下：

（1）明確滑動切換頁簽的優(yōu)缺點

操作步驟上，點擊切換和滑動切換都是1個動作事件。只是通常來看，滑動操作比點擊操作難度稍低，畢竟點擊需要找到觸發(fā)區(qū)。

另一個方面，支持滑動切換可以覆蓋更多用戶的操作預(yù)期——假設(shè)用戶普遍習(xí)慣滑動切換的操作方式。

但是滑動切換頁簽的操作本身也有弊端。比如有時候本來是想上下滑動的，但是手指一不小心就滑歪了，于是無意識觸發(fā)了滑動事件，跳到了另一個頁面去，可能就打斷用戶沉浸式體驗。

（2）基于以上，筆者建議如下

①沉浸式的瀑布流，比如抖音的視頻流，不推薦滑切Tab頁。

如果非要做，則將滑動切換觸發(fā)靈敏度降低。

②內(nèi)容長度有限，或者閱讀速度快的Tab頁簽，可以使用滑切。比如電商商品的【參數(shù)】、【評論】之間的切換。

③除了左右滑動切換Tab，還可以結(jié)合下翻切換：如果頁面內(nèi)容較短，那么在下翻至Tab頁內(nèi)容結(jié)束的時候，緊接著就切換下一頁的內(nèi)容。比如：

最后要注意，不管做不做滑切，產(chǎn)品經(jīng)理都要給予開發(fā)人員明確的說明。

16. 分享功能的“借尸還魂”

（1）分享的原理

第三方平臺提供了分享接口，目標(biāo)App對接后，獲取了對應(yīng)權(quán)限和功能支持。

因此在分享事件中，目標(biāo)App分享出去的內(nèi)容是“客隨主便”：第三方支持什么，分享出去才能做什么。

通常，內(nèi)容分享出去之后，會在第三方平臺中以一定的格式展示。這種格式不由產(chǎn)品經(jīng)理設(shè)計，而是第三方平臺規(guī)定的。（產(chǎn)品經(jīng)理需要確認要展示的內(nèi)容）。

在第三方平臺中打開分享的內(nèi)容后，就會基于第三方平臺內(nèi)置環(huán)境進行功能展示。通常都會引導(dǎo)用戶觸發(fā)打開App，或到應(yīng)用市場下載App。

（2）技術(shù)實現(xiàn)方面

第一步，接口對接，實現(xiàn)第三方系統(tǒng)的授權(quán)。

未授權(quán)的情況下做分享，會有類似下圖的提示：

第二步：實現(xiàn)功能需求。

以分享小視頻到微信為例，若要在微信H5中實現(xiàn)視頻播放、點贊等功能，則要基于H5寫相關(guān)的代碼。

當(dāng)然也可以使用SDK（SDK通常本身支持多個系統(tǒng)：電腦、安卓、ios、H5等）。

而前面提到的跳轉(zhuǎn)到APP或應(yīng)用市場的邏輯，就是校驗到本手機沒有App則跳轉(zhuǎn)到應(yīng)用市場下載，校驗到已經(jīng)安裝則打開App。

但是在實現(xiàn)的時候，要了解第三方分享接口是否支持喚醒App。若不能支持，那么就要借助其他方式間接實現(xiàn)需求。

（3）產(chǎn)品經(jīng)理要確認的

①確定分享的場景或業(yè)務(wù)位點：

比如，操縱完成或得到結(jié)果時提示分享（如截圖后、完成拍照和攝像時）、打開App時出彈層提示分享、勝利完成任務(wù)時提示分享（比如王者榮耀連勝的提示“炫耀一下”）。

②確定分享的形式

主要有：文字或鏈接地址的分享（比如天貓和淘寶的“淘口令”）、圖片分享（靜態(tài)圖片、GIF動圖）、音視頻類行形（標(biāo)記它是音頻或是視頻，并且可以直接在當(dāng)前頁播放）；網(wǎng)頁分享（帶有網(wǎng)頁縮略圖的）。

其中網(wǎng)頁分享是最常見的。

以分享到微信為例，分享過去的網(wǎng)頁有自己的格式。比如：同一個內(nèi)容，從APP或外部瀏覽器分享到微信，會顯示APP的名稱和縮略內(nèi)容，從微信內(nèi)置瀏覽器分享的就不會展示這些信息。

另外注意：分享網(wǎng)頁和分享鏈接是不同的分享形式。前者帶有網(wǎng)頁自身的縮略內(nèi)容，后者屬于文本范疇的分享，簡單原始。

③用戶打開的效果是什么

如果將分享理解為“借尸還魂”引流的話，那么打開分享鏈接之后，可以以最基礎(chǔ)的靜態(tài)畫面呈現(xiàn)，再次點擊頁面，則引導(dǎo)跳轉(zhuǎn)到App，或引導(dǎo)到應(yīng)用市場下載App。

但是，產(chǎn)品經(jīng)理需要知道，某些第三方的應(yīng)用不給提供便利，不支持跳轉(zhuǎn)到App。比如微信。

因此設(shè)計時候考慮增加提示“使用本地瀏覽器打開”（假設(shè)瀏覽器是支持的）。這樣就借助一個新的橋梁“假途滅虢”實現(xiàn)需求了。如下圖這樣：

④最后，讓分享自然甚至驚喜

比如：讓用戶獲得優(yōu)惠，得到好處（如「哈羅單車」通過分享獲得紅包）；

輔助業(yè)務(wù)實時共享（如「滴滴」可以分享行程給他人共享實時位置）；邀請好友，分享快樂（如「王者榮耀」邀請朋友一起組團開黑）；

分享成就（如游戲獲得了九連勝等）。

17. 【消息】模塊設(shè)計的關(guān)注點

（1）必要時提供消息歸類

讓目標(biāo)信息曝光增加，同時讓消息有條理。

就好像微信的【訂閱號消息】一樣，進行歸類，給予總?cè)肟凇?/p>

（2）未讀消息提示數(shù)字或紅點

為了不給用戶負擔(dān)，不是很要緊的消息盡量使用紅點。

消息數(shù)的消除以打開為準(zhǔn)，即打開就視為已讀。

（3）歷史消息保存留時長

永久保存在服務(wù)器，用戶可以通過加載，分批查看歷史消息。

（4）聊天消息記錄的操作

①已發(fā)出的文字和表情（包括發(fā)送失?。?/p>

長按可以轉(zhuǎn)發(fā)、刪除、復(fù)制。

②已發(fā)出的音頻、圖片和視頻（包括發(fā)送失?。?/p>

長按，可以轉(zhuǎn)發(fā)、刪除，但不能復(fù)制（系統(tǒng)不支持）；

點擊，打開預(yù)覽大圖，長按大圖，彈出保存按鈕。

③發(fā)送失敗的內(nèi)容：

增加重復(fù)發(fā)送按鈕，或者點擊發(fā)送失敗的按鈕實現(xiàn)重發(fā)。

④長按消息記錄，彈出的操作框開口方向：

就近原則，若消息在屏幕上方，則操作內(nèi)容在下方；

反之，長按后的操作框展示在內(nèi)容上方。

（5）消息通知方式

根據(jù)緊要程度，選擇橫幅通知、鎖屏通知、菜單通知。

建議只對主要的信息用音效，盡量不要騷擾到用戶。

（PS 但是根據(jù)經(jīng)驗，一般老板都會要求“騷擾”用戶。）

18. 「聊天」發(fā)表情，是怎樣的機制

在微信發(fā)一個表情出來，你發(fā)現(xiàn)顯示的是名稱[調(diào)皮]，而不是一個圖標(biāo)

。

收到表情的一方，退出到聊天信息總列表，顯示的也是[調(diào)皮]。

那么為什么不是直接放一個表情在上面呢？實際這與實現(xiàn)原理有關(guān)系。

當(dāng)發(fā)表情給對方的時候，實際上發(fā)的是這個表情對應(yīng)的ID——>服務(wù)器拿到這個ID之后，再傳給接收方的客戶端——>接收方收到，再解碼出一個表情，展示在客戶端。

用圖示如下：

因此，表情的發(fā)送，是發(fā)送給服務(wù)一個對應(yīng)ID，而不是發(fā)送表情文件給對方的。

所以表情文件（圖文件）需要存在客戶端，而不需存在服務(wù)器。此外客戶端還要存表情名稱和ID。

事實上客戶端需要以josn格式存儲表情圖-名稱-表情ID，如下圖這樣：

注意，App正式運營階段，需要自己制作表情，避免盜用侵權(quán)。

19. 「輸入框」的約束這件小事

從約束的程度看，輸入框可以分兩類，一類相對開放，比如作品評論框、好友留言框；另一類相對約束，比如昵稱、個性簽名、標(biāo)簽。

這兩類之所以約束程度不同，主要是跟用戶心理訴求以及頁面的展示形式?jīng)Q定的。

比如個性簽名一般會展示在個人資料頁，不管是自己看，還是他人看，都要求美觀，比如居中對齊。

同時頁面空間有限，所以字?jǐn)?shù)需加以限制。

那么對于這類輸入框，要做的是：限制字?jǐn)?shù)、對齊方式、內(nèi)容校驗、文案提示等。

舉一個個性簽名輸入框約束方案的例子：

（1）限制字?jǐn)?shù)：字?jǐn)?shù)上限盡量高，不讓用戶心理上感到被束縛（好比商城大廳都很高，盡管“摸著天杜千”這樣的用戶很少），比如40-50字。

字?jǐn)?shù)上限可以在右下方顯示，隨著輸入而扣減字?jǐn)?shù)。

（2）字?jǐn)?shù)校驗：推薦在輸入的時候，截取到限定字?jǐn)?shù)，多余的不予錄入。無需語言提示，用戶都看得懂。

（3）文案提示：根據(jù)（1），由于已經(jīng)有顯示位數(shù)了，所以可以換個提示，比如“據(jù)說簽名會提升關(guān)注幾率哦”。

如果簽名為空，為了提高體驗，則建議對他人展示一個固定值，比如“歡迎關(guān)注我”。

（4）對齊方式：展示的時候，建議居中，最多顯示兩行，多出的省略。

在編輯環(huán)境自己看的時候，如果是下圖這種樣式，可以規(guī)定：滿行則靠左側(cè)對齊，不滿行靠右對齊。

20.你的App用到過「音效」嗎

以App「SOUL」的匹配按鈕為例，匹配中有音效，匹配成功，也會有個音效。

那么音效的實現(xiàn)是怎么的機制呢？是不是在后臺配置音頻文件，通過點擊按鈕調(diào)用呢？

實際上一般不需要在后臺存儲音頻文件。

一來是因為音效變動不大，比如QQ的加好友的咳嗽聲用了那么多年。所以在客戶端寫死并不影響實際需要。

二來牽扯到觸發(fā)后，對交互的時效性要求較高。對比前面提到的表情，音頻文件會大很多。

以「SOUL」為例，本來已經(jīng)匹配到用戶了，如果因為網(wǎng)速等導(dǎo)致了延遲，遲遲沒有發(fā)出匹配成功的聲音，那就尷尬了。

21.分頁加載，還是一次加載全部

考慮是否需要分頁的時候，基本有三個特征：

• 第一，數(shù)據(jù)需要從服務(wù)器拉取；
• 第二，拉取的數(shù)據(jù)容量不太??；
• 第三，拉取內(nèi)容的條數(shù)不太小。

客戶端是一次加載完，還是分頁加，分別需要服務(wù)器提供分頁或全部數(shù)據(jù)的吞吐機制。

那么采取兩種措施的優(yōu)劣如何呢？

從用戶角度，并不能一棍子打死說全部加載就省事。

因為全部加載浪費用戶流量和加載時間。很可能后面的內(nèi)容是用戶不需要的。這時候加載那么多反而適得其反。

但是分頁加載的缺點就是增加用戶操作的次數(shù)。用戶看完一頁需要再次加載才能看更多內(nèi)容，影響用戶沉浸性體驗。

目前整體來說，采用分頁加載的較多。根據(jù)用戶的適應(yīng)性，每一頁給予的內(nèi)容數(shù)量加以調(diào)整。比如抖音的分頁瀑布流。

作為產(chǎn)品經(jīng)理，在確認列表頁（比如好友通訊錄）、信息流（比如好友動態(tài)）的時候，首先要在PRD中明確是否分頁加載。

若分頁，則確定每頁加載的大致條數(shù)。最重要的是需考慮清楚，支持分頁或不分頁的原因。

22. 「緩存」是整體性、系統(tǒng)性的工作

使用緩存，主要是提高性能和離線訪問數(shù)據(jù)（用戶需求或體驗）。比如，緩存可以支持離線訪問、支持用戶離線操作、減少用戶流量損耗、提升速度、節(jié)約訪問服務(wù)器成本等。

其原理就是將加載過的內(nèi)容存儲下來（緩存），下次讀取時，首先從緩存中查找，找到了則直接執(zhí)行，找不到則再從內(nèi)存中找。

（1）產(chǎn)品經(jīng)理在處理緩存問題的三類場景

第一類，功能或性能上必須緩存。這種情況下無需產(chǎn)品經(jīng)理強調(diào)，開發(fā)都會進行緩存處理的。

比如微信通訊錄中用戶的頭像，在第一次加載的時候就全部拿到。之后刷新列表，都將基于前一次緩存的數(shù)據(jù)重新進行更新。

第二類，產(chǎn)品經(jīng)理有目的地針對具體功能要求給予緩存。根據(jù)KANO模型，多是為了做出用戶期望的或興奮的效果。

比如，資訊閱讀類App，用戶第一次加載出的內(nèi)容緩存下來。下次因網(wǎng)絡(luò)太差無法加載數(shù)據(jù)時，可以看到老信息。

第三類，在產(chǎn)品功能基本完善的時候，將緩存作為一個系統(tǒng)整體機制來梳理和規(guī)范。這個時候產(chǎn)品經(jīng)理做的是排查，然后以緩存作為方案進行補充完善。

產(chǎn)品經(jīng)理要清楚一般App的緩存習(xí)慣，比如如下場景：

①聊天記錄（使用IM及時聊天SDK的情況下，往往本身就是保存了的）；

②個人資料（用戶自己在本地維護的，所以無需拉取服務(wù)器）；

③自己創(chuàng)作的作品（原理同個人資料）；

④草稿或編輯一半的內(nèi)容（比如制作視頻的規(guī)程中意外中斷了操作，下次進入可以繼續(xù)）；

⑤支付明細，或其他操作記錄。

⑥其他。

以上，有的可能在開發(fā)的過程已經(jīng)實現(xiàn)了。但最終產(chǎn)品經(jīng)理要做一個核查和規(guī)范。

（2）緩存的數(shù)據(jù)到哪里了

緩存數(shù)據(jù)就是存在手機的文件夾路徑中了。當(dāng)然也可以存儲在相冊這樣的地方。必要的時候產(chǎn)品經(jīng)理要與開發(fā)定義。

總的來說，App緩存的位置分內(nèi)部存儲和外部存儲兩類（以前的手機的SD卡就是外部存儲)。

內(nèi)部存儲里的文件默認是只能被指定的App訪問的。卸載App的時候，里面的相關(guān)文件都清除干凈。

外部存儲并不總是可用的，往往需要請求授權(quán)，比如訪問相冊。當(dāng)用戶卸載App時，系統(tǒng)僅僅會刪除其中相關(guān)的文件。

（3）緩存數(shù)據(jù)的清除

緩存本質(zhì)就是拿內(nèi)容換時間，因此緩存的內(nèi)容會擠壓存儲空間，甚至拖累性能。通常自動清除，結(jié)合手動清除。

自動清理緩存的兩個要素：設(shè)置緩存的上限、設(shè)置清理緩存的頻率。

比如UCG的視頻，App每次刷新可以加載10個，且不重復(fù)加載，那么就可以將每次加載的視頻ID存儲在手機中，下次加載做差異化扣減。

但是顯然這個量日積月累也夠大的。所以可以設(shè)置為（比如）每周自動清除一次。

手動清除，比如微信的清除緩存。

手動和被動清除，都需要代碼規(guī)定哪些可以清掉，哪些不能，這個在具體應(yīng)用中要與開發(fā)約定。

23. 「版本更新」的三種場景

版本更新，通常是通過應(yīng)用市場、使用時提醒用戶、離線時推送消息，這三種手段分別對應(yīng)三種用戶與App的場景。

（1）彈框更新提醒

版本發(fā)布到應(yīng)用市場，市場就會判斷后提醒用戶更新（當(dāng)然前提是用戶得來到應(yīng)用市場）。如果用戶不來，就需要App內(nèi)彈窗提醒更新。

打開應(yīng)用時，通過彈窗的方式來告訴用戶有新的版本了。好處在于用戶使用產(chǎn)品時就能夠看見，有針對性。不好的是打擾到用戶了。

一種常見的機制是，設(shè)置兩個版本號，一個開發(fā)版本號，另一個是顯示給用戶的用戶版本號。

每個App版本都有唯一的開發(fā)版本號，就像序列號一樣唯一且嚴(yán)格。而顯示版本號是給用戶看的，所以可以擬定。在用戶打開應(yīng)用時校驗版本差別。

后臺設(shè)置的參數(shù)有：開發(fā)版本號、顯示版本號、更新內(nèi)容、是否啟用等。

還有一個看不見的規(guī)則：當(dāng)新版本的【開發(fā)版本號】大于用戶版本的【開發(fā)版本號】，則強制更新；否則，更新，但不強制。

舉個例子：用戶的App的當(dāng)前顯示版本號是V1.1.1，開發(fā)版本號是1.2.2。發(fā)布了更新，并在后臺設(shè)置新版的顯示版本號是V1.1.2，開發(fā)版本號是1.2.2，那么啟動后，會彈框提醒，但是不強制用戶更新。

（2）總結(jié)彈框更提醒新

①每次打開App，都校驗是否有新版本；若有，則校驗是否屬于強制更新。強制更新 則只能更新，或者退出應(yīng)用；非強制更新可以不更，繼續(xù)使用；

②安卓往往從公司服務(wù)器下載（避免商城的不確定性），當(dāng)然也可以像IOS一樣跳往應(yīng)用商店。

安卓受管制少，所以一般直接顯示下載進度條，下載不能打斷或暫停；下載完畢 toast提示，同時直接安裝；安裝完畢 toast提示，同時直接打開APP。

④提醒更新和商店更新的文案不同。提醒更新的更簡潔，文案在后臺配置。

比如，要求最多顯示6行（一行顯示不完的自動換行，超行與換行符的換行無差別對待），超出6行的顯示…

（3）推送消息通知更新

提醒更新前提是用戶打開App，為避免用戶長久不打開App，也可以通過發(fā)推送的方式提醒用戶更新版本。

推送不能點擊后直接跳入AppStore。其主要作用是提醒用戶：最近我有很多好玩的新功能哦，快來瞅瞅吧。

24. 熱更新就那點事

熱更新就是，通過一些技術(shù)手段，直接對線上App添加新功能或者修改bug，以避開上架審核造成的麻煩或不通過。

該過程所用的技術(shù)手段就統(tǒng)稱為熱更新。

熱更新時候，可以通知用戶手動觸發(fā)，比如王者榮耀。也可以不告訴用戶，直接更新。

無論代碼是原生還是H5，理論上都可以進行熱更新。

熱更新可以理解為代碼版本更新的一個細分手段，只下載缺失的那部分內(nèi)容，文件對比后 重新合并，減少了下載量。

25. 關(guān)于安裝測試包

（1）正式包與測試包

測試App時候，可以使用正式包（生產(chǎn)包），也可以使用測試包，二者因連接兩個不同環(huán)境的服務(wù)器而區(qū)別。

需要注意的是，這與是否連外網(wǎng)沒必然關(guān)系，測試環(huán)境也可以連外網(wǎng)，供在公司之外測試。

有時候我們需要生產(chǎn)和測試環(huán)境切換來來排查問題，安卓的開發(fā)員通常會寫一個開發(fā)者模式，這樣安裝一個APK包，就可以在測試版和正式版之間切換。

正式包與測試包通常是同一份代碼，分別發(fā)布在不同的環(huán)境中。但需要注意， 兩個版本可能不對稱。

比如1.1版本的代碼只在正式服務(wù)器發(fā)布了，那么切換到測試服務(wù)器的時候代碼是不一樣的，功能就不一樣了。

（2）安裝版本

安裝新版本的時候，安卓可以文件傳輸形式進行安裝。但是蘋果不能。蘋果需要連手機線在特定環(huán)境下安裝。當(dāng)然也可以申請一個臨時的小版本企業(yè)賬戶（百十來個人的上限），因為蘋果管控比較嚴(yán)格。

新舊安裝包安裝時候，壓縮包簽名相同的會自動覆蓋，這樣更新之后賬號依然在，類似熱更新。但最好是先卸載舊的，避免可能的沖突。

26. APK壓縮

精簡安裝包大小對用戶升級等待時間和流量消耗影響很大。在正式發(fā)布之前，會抽出一段時間，著重壓縮安裝包。

基本是從兩個思路去減少APK體積的：減少代碼的大小、減少資源的大小。

（1）減少代碼的大小

比如，刪除無用的代碼邏輯，刪除無用的產(chǎn)品邏輯，混淆代碼，把一些代碼做內(nèi)聯(lián)，把代碼中的類名、方法名和變量名替換成更加短小的無意義名字，測試代碼分離等。

（2）減少資源的大小

其原理就是找出里面較大的文件或數(shù)據(jù)庫，進行壓縮。比如封面圖或字體大小，若壓縮之后清晰度可以，那么就這么干了。

通常開發(fā)通過插件，對所有的圖片進行遍歷，自動壓縮成webp，并刪除原來的圖片；很多png是不能進行webp化，那么可以進行tinypng壓縮。

壓縮應(yīng)用是個持續(xù)工作。如果沒有去持續(xù)關(guān)注，很可能一點點就擠壓過大了。

27. SDK調(diào)研和選型

接入SDK是明智的選擇。

功能插件的底層代碼，沒有誰再愿意從石器時代重新造一遍輪子。比如人臉識別、美顏等。

但前提是SDK的加入，在時間、質(zhì)量上靠得住。

（1）參與SDK的初步調(diào)研和篩選

先閱讀準(zhǔn)供應(yīng)商的SDK方案文檔，判斷是否滿足產(chǎn)品當(dāng)前的大致需求，以及未來的擴展。

下圖就是某SDK提供商的方案文檔局部截圖：

以拍攝視頻的功能為例，其功能清單如下圖：

通過分析功能，列舉出缺失功能，和自研該功能的成本。

從而得出對該家SDK的基本評分。

（2）多家的橫向?qū)Ρ龋瑩駜?yōu)而取

假設(shè)我們鎖定了四家SDK，他們的基本版功能都是滿足的。但是實現(xiàn)方案和細節(jié)就有差異。

比如，某SDK沒有編輯時間軸的功能。也就是只能一個貼紙應(yīng)用整個視頻，無法實現(xiàn)在視頻不同時間段使用不同貼紙的需求。

而我們是需要這個時間軸編輯功能的。因此就將這個SDK的該項缺陷登記出來，并評估出自己開發(fā)所需的成本。

使用該方法，輸出一份初步調(diào)研文檔，以便后續(xù)跟蹤調(diào)查，如下圖所示：

（3）輸出基于SDK的需求、UI方案

SDK往往還需要二次開發(fā)，或者自主研發(fā)一些功能加以彌補。

就算代碼不需要寫，UI還是要自己做的。

因此需為開發(fā)人員輸出一份基于SDK的需求文檔。

SDK結(jié)合本地代碼之后，可能出現(xiàn)未曾預(yù)見的新問題。

比如，拍攝視頻到發(fā)布視頻的過程中，會出現(xiàn)多次合成或加載，影響用戶體驗。

這個時候產(chǎn)品經(jīng)理就需要基于當(dāng)前的環(huán)境，羅列出不同的操作場景下的加載位點，并用文案區(qū)分出不同位點的提示文案。

選擇適當(dāng)?shù)腟DK固然能省事，但是一款產(chǎn)品的品質(zhì)，還在于協(xié)調(diào)和氣質(zhì)定位等。