本文5千字，圍繞社交類App的產品，對常見的9個方面的設計要點和原理，進行摘要分享。

01

社交App設計「音效」實現機制

在社交過程中，音效的加入，讓事情變得有趣、及時。

QQ的咳嗽聲和消息通知是否勾起了回憶呢？

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

那么音效的實現是怎樣的機制呢？

是不是在后臺配置音頻文件，通過點擊按鈕調用呢？

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

一來是因為音效變動不大，你看QQ的加好友的咳嗽聲用了那么多年。
所以在客戶端寫死并不影響實際需要。?
二來牽扯到觸發后，對交互的時效性要求較高。
因為音頻文件會比圖標大很多。

以「SOUL」為例，本來已經匹配到用戶了，如果因為網速等導致了延遲，遲遲沒有發出匹配成功的聲音，那就尷尬了。

所以使用音效，一般音頻文件，都是放在前端的。

至于文件壓縮和音質，就是個篩選的過程。

02

「聊天」發表情，是怎樣的機制

社交聊天，就需要發表情。

在微信發一個表情出來，你發現顯示的是名稱[調皮]，而不是一個圖標。

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

那么為什么不是直接放一個表情在上面呢？

實際這與實現原理有關系。

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

用圖示如下：

因此，表情的發送，是發送給服務器一個對應ID，而不是直接發送表情文件給對方的。

所以表情文件（圖文件）需要存在各自的客戶端，而不需存在服務器。

此外，客戶端還要存表情名稱和ID。

具體就是，客戶端需要以josn格式存儲表情圖-名稱-表情ID，如下圖這樣：

注意：灰度階段可以偷些表情用，但是App正式運營階段，需要自己制作表情，避免盜用侵權。

03

社區動態的時間格式的定義

時間的顯示基本分兩類：

• 一類是展示在外層的，不需要很精準的時間。比如聊天環境下的時間、用戶動態外層顯示的時間；
  

• 另一種作為嚴格的時間落款，比如賬單明細。

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

前者就要切合場景，對時間的要求和用戶情感的匹配性，融入一定的感情色彩或者暗示。

這里就有多種流派，比如推特和微信就區別很大。有興趣自行研究下。

筆者在這里整理一套自己用于聊天信息、評論、系統消息、動態的時間的展示規則，可以作為借鑒：

剛剛（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

? 04

【消息】模塊的設計

1. 消息歸類

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

比如：將系統與用戶的消息，放入【系統通知】，默認折疊。

類于“文件夾”。點擊，則打開系統消息列表。

將用戶的【互動通知】默認展開。

2. 未讀提示：數字還是紅點呢？

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

超過99條一般顯示99+。實際顯示99也可以，對用戶而言已無差異。非緊急的通知可以不顯示具體數字。

消息已讀的判斷標準：只要打開就算已讀。

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

3. 刪除消息

分兩類：一類是單條聊天記錄的刪除；

一類是整個聊天條目的刪除。

大家用微信就知道。

4. 消息保存時長

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

5、聊天消息記錄的操作

此外，需考慮聊天消息的復制、轉發、失敗重發等按鈕。

1）已發出的文字和表情（包括發送失敗）

長按可以轉發、刪除、復制。

2）已發出的音頻、圖片和視頻（包括發送失敗）

長按，可以轉發、刪除，但不能復制（系統不支持）；

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

3）發送失敗的內容

增加重復發送按鈕，或者點擊發送失敗的按鈕實現重發。

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

就近原則，若消息在屏幕上方，則操作內容在下方；反之，長按后的操作框展示在內容上方。

5）消息通知方式

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

建議只對主要的信息用音效，盡量不要騷擾到用戶（PS：但是根據經驗，一般老板都會要求“騷擾”用戶。）

05

左右滑動切換Tab頁簽

很多App的Tab頁簽，支持左右滑動切換。

那么是不是在設計Tab頁簽的時候都要這樣規劃呢？

在確定這個方案時，產品經理需要考慮如下：

1）明確滑動切換頁簽的優缺點

操作步驟上，點擊切換和滑動切換，都是1個動作事件。

只是通常來看，滑動操作比點擊操作難度稍低，畢竟點擊需要找到觸發區。

2）另一個方面，支持滑動切換可以覆蓋更多用戶的操作預期——假設用戶普遍習慣同類產品的滑動切換的操作方式。

但是滑動切換頁簽的操作本身也有弊端。

比如有時候本來是想上下滑動的，但是手指一不小心就滑歪了，于是無意識觸發了滑動事件，跳到了另一個頁面去。

可能就打斷用戶沉浸式體驗。

基于以上，筆者建議如下:

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

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

2）內容長度有限，或者閱讀速度快的Tab頁簽，可以使用滑切。

比如電商商品的【參數】、【評論】之間的切換。

3）除了左右滑動切換Tab，還可以結合下翻切換：

如果頁面內容較短，那么在下翻至Tab頁內容結束的時候，緊接著就切換下一頁的內容。比如：

最后要注意，不管做不做滑切，產品經理都要給予開發人員明確的說明。

06

分享功能的“借尸還魂”

1、分享的原理

第三方平臺提供了分享接口，目標App對接后，獲取了對應權限和功能支持。

因此在分享事件中，目標App分享出去的內容是客，“客隨主便”：

即：第三方支持什么，分享出去才能做什么。

通常，內容分享出去之后，會在第三方平臺中以一定的格式展示。

這種格式不由產品經理設計，而是第三方平臺規定的。（產品經理需要確認要展示的內容）。

在第三方平臺中打開分享的內容后，就會基于第三方平臺內置環境進行功能展示。

通常都會引導用戶觸發打開App，或到應用市場下載App。

2、技術實現方面

第一步：接口對接，實現第三方系統的授權。

未授權的情況下做分享，會有類似下圖的提示：

第二步：實現功能需求

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

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

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

但是在實現的時候，要了解第三方分享接口是否支持喚醒App。

若不能支持，那么就要借助其他方式間接實現需求。

3、產品經理要確認的

1）確定分享的場景或業務位點

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

2）確定分享的形式

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

其中網頁分享是最常見的。以分享到微信為例，分享過去的網頁有自己的格式。

比如：同一個內容，從APP或外部瀏覽器分享到微信，會顯示APP的名稱和縮略內容，從微信內置瀏覽器分享的就不會展示這些信息。

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

3）用戶打開的效果是什么

如果將分享理解為“借尸還魂”引流的話，那么打開分享鏈接之后，可以以最基礎的靜態畫面呈現，再次點擊頁面，則引導跳轉到App，或引導到應用市場下載App。

但是，產品經理需要知道，某些第三方的應用不給提供便利，不支持跳轉到App。比如微信。

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

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

比如：

讓用戶獲得優惠，得到好處（如「哈羅單車」通過分享獲得紅包）；

輔助業務實時共享（如「滴滴」可以分享行程給他人共享實時位置）；

邀請好友，分享快樂（如「王者榮耀」邀請朋友一起組團開黑）；

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

07

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

刷新，是產品經理需要定義的常見的功能。

要么是手動觸發刷新，要么是定時任務觸發。

定時任務觸發，比如1分鐘內的消息顯示“剛剛”，那么系統就可以每一分鐘自動刷新一次，使顯示合理的時間格式。

本文主要以手動觸發說明，產品經理至少可以考慮四個方面的問題：

1. 怎樣的觸發方式

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

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

比如：【抖音】，可以雙擊底部菜單實現頁面刷新。

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

2. 打開新頁面加載的

刷新有打開新頁面的，也有在當前頁面加載新內容。

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

1）翻頁方向

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

加載發生在翻頁的前還是后呢？

2）翻頁前加載

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

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

3. 設計loading標示

1）loading標示的樣式

菊花和進度條是最基礎的loading標示，若做成動畫，或者加入App品牌特色，就更顯誠意了。

2）loading標示的位置

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

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

4. 加載策略

在實現機制上，產品經理要說清楚效果。

比如：最遲不超過2s、要求某些內容先加載出來等等。

這樣就引導出了常見的幾種機制：異步加載、分模塊加載、懶加載和預加載等。

需要注意的是：加載機制不僅僅是受限于網速，更是信息泛濫時代的一種策略：讓用戶優先看到什么，節約用戶精力，提高回報率。

08

Web在手機端的適配

產品官網，初期都很簡單，基本都是：產品介紹+下載鏈接。

功能不復雜，因此可以考慮設置手機訪問官網的功能。

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

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

1. 極簡適配

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

2. 完全適配

做了全適配的官網會在手機端有良好的表現。當然，PC端的官網有時候體量太大，在適配到手機端的時候也要有刪減。

09

App第三方登錄的注意事項

社交類App登錄方式，基本已經沉淀了這三種：賬號密碼、手機郵箱驗證碼、第三方賬號登陸。

隨著社交類霸主的穩固，很少注冊賬號密碼（與產品的定位和用戶群有關），多的是第三賬號登錄。

第三方登錄就是借助第三方應用的接口實現用戶登記，比如常見的三家：微信、QQ、微博。毫無疑問，這是看上了小三的大腿，可以抱。借助已經形成的社交生態之火，去點燃另一團社交生態。

1. 使用第三方登錄的目的

1）簡化注冊環節，減少可能因為注冊繁瑣帶來的用戶損失

2）關聯賬號，形成社交群落之間的呼應，有利于用戶生態鏈的搭建。

比如：用戶可以把平臺上的某些內容一鍵分享到第三方平臺；

3）獲取用戶的一部分已有信息，比如用戶信息或流量資源

4）節省用戶的記憶成本

用戶在使用多個應用時，只需使用第三方登錄即可，無需記得每個平臺的賬戶和密碼。

2. 使用第三方登錄的注意點

1）第三方賬號給的資料完善度和安全性不好把控。

比如你期望獲取QQ中的頭像、昵稱、年齡、地區，但是QQ可能只給你頭像和昵稱。

又比如有一天第三方封了接口，那么第三方登錄功能就停擺了。還有注銷了第三方賬號的情況。

2）第三方登錄方式，對用戶來說不一定就是省時省力的渠道。

因為相關法規的要求很多APP是需要用戶手機號的，而第三方登錄并不能獲取用戶已經提供給第三方的手機號（用戶隱私）。

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

3）后臺創建了自己的賬戶體系時，若沒有設計好合理的第三方和本地賬戶對接的方案，會導致同一個用戶在平臺上有多個賬號的情況發生。

3. 總結

知道了第三方登錄有如此這般的優點和缺點，但迫于它又確實是能夠為用戶一定程度上帶來便利。

所以你必須想辦法折磨自己折磨設計然后折磨開發工程師，以此來盡可能帶來一個比較和諧的用戶使用體驗。

↘好文推薦：

字節跳動如何做教育？ | 詳解

5個步驟，繪制高質量的業務流程圖

騰訊產品經理的一天是啥樣的？

點個“在看”吧

總結

以上是生活随笔為你收集整理的社交类产品设计的9个点，整不好会挨怼~的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。