社交类产品设计的9个点,整不好会挨怼~
本文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个点,整不好会挨怼~的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 产品问答 | 领导把锅甩给你,你会怎么做
- 下一篇: 社交电商这条路,也许只有腾讯能走远