中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：消息系統是產品的重要組成部分，它是企業產品和用戶之間的橋梁，然而，產品若無法將信息有效地傳遞給用戶，則會影響后續的用戶留存與產品迭代優化。為了去除冗雜、推動系統優化，若想重構消息系統，應該從哪些方面下手呢？本文作者做了相應解讀，一起來看一下。

消息模塊是每個產品必不可少的重要模塊，作為溝通用戶與產品的重要橋梁，消息系統一直在整個產品的各個周期中占有重要的地位，它必須保證企業核心業務流程的正常運轉，同時還需要傳達用戶的反饋。

本文將分為上下兩篇，以消息中臺的思路設計方案，最終落地消息中心及后臺方案，以消息收發為基礎應用，為公司不同的業務場景提供支撐。

一、重建背景

對于一個金融咨詢類公司來說，怎么把專業指導消息有效、準確、及時地傳達給用戶，是非常重要且核心業務。隨著新業務不斷的疊加，因為沒有進行系統的規劃，造成了現有業務消息冗雜、消息分類不明確、傳達方式不及時等諸多問題，如果不進行徹底的重構，無法做到支撐后續更多的業務。

任何一款產品重建重要模塊的過程，都是一種極為富有挑戰的工作，特別是對核心業務，原有流程已經深入人心，前端的功能體驗和交互方式已經被用戶所熟悉和接受，如果突然進行很大的改變，用戶重塑認知的風險，會不會因為認知成本太高而造成原有用戶流失，業務人員會不會不接受，眾多因素都是此模塊能否成功的關鍵因素。

下面筆者將詳細分享自己對于消息中心重建的設計經驗（以下內容數據方面有一定的模糊處理，僅供參考）。

二、需求調研

需求調研的方式有比較多的分類和方法，在這此消息系統的優化中，筆者采用了內部調研和外部調研兩種方案，下面給大家詳細說明。

1. 內部調研

如何對現有消息系統有全面細致的了解，需要我們先找到一個突破點，日常工作職責中必須用到消息的職能部門。

我們不僅需要了解其在消息業務背后的痛點，要對業務進行系統的了解，如果是需求調研更多是為了解決一個點的問題，而我們現在要對于整個流程進行了解和整理，這樣不僅可以知道更深刻的業務邏輯，還可以讓我們對業務有進一步了解的機會（作為新人帶著需求去了解業務是比較快的成長方式）。

方法一：相關人員走訪調研

實際的調研過程中，確定了哪些業務部門的關鍵人以后，與相關業務人員面對面訪談，在公司內部比較常見的方式；如果是不同辦公地點的同事也可采用線上溝通的方式進行。

我們要先提前把問題想好，避免約了需求方見面后以后不知道重點，造成調研無中心。這里可以提供大家幾個方向問題，幫助大家在調研消息業務時，進行業務方面的了解。

1. 請列舉一下我們部門那些業務需要通過消息推送發送給業務用戶，消息推送全流程是如何實現的？
2. 目前這些業務對于消息的觸達方式有哪些？系統自動發送還是需要人工推送，頻率如何？有沒有遇到什么問題？
3. 大家現有的渠道公眾號推送/App Push/站內信推送時是如何進行推送渠道的篩選的？你們覺得是不是需要增加推送渠道？不同的渠道對應的是哪些業務場景？
4. 目前我們的消息業務是否可以滿足現有應用場景和客戶群體，對于更多有助于公司業務提升的場景中，我們有哪些不足點可以進行優化？
5. 在沒有消息渠道觸達客戶時，我們目前是如何與客戶進行溝通的？溝通的結果如何？是否有相關的數據支撐呢？

特別注意溝通的時候盡量要記下來自己不懂的問題，隨后要和相關訪談部門進行及時的確認，避免在后續方案實施中遺漏比較重要解決方案。

方法二：收集相關資料

消息系統作為每一款產品的基礎模塊，在前期的版本規劃中，相關的產品經理和技術會留有相關的文檔，如果我們在具體實施方案前，業務方沒有明確的方向，我們可以通過部門內部調研，來解決需求真偽的問題：

1. 我們需要通過產品內部對齊信息，并與相關的產品經理了解其他模塊與消息模塊的業務關聯，并收集相關的文檔，避免造成優化的過程中方案無效。
2. 其次我們需要和相關的技術負責人溝通，收集現在系統中的消息種類、發送機制等，盡量讓技術提供系統消息模版，這一步非常關鍵，因為隨著業務的變遷，人員的更迭，業務部門的人員提供的相關信息可能存在紕漏和錯誤，查看技術代碼可以最真實的還原現在消息模塊的具體情況。

2. 外部調研

如果你對消息系統沒有概念，只是知道這套系統具體功能是做什么的，這樣是遠遠不夠的。你需要進行深入的調研，我們可以進行競品調研，大致把競品和你所熟知的app的消息模塊進行系統了解，這樣你才能夠提出足夠有重點的問題。

筆者在進行消息模塊的競品分析時，根據消息模塊的特點，從業務層和體驗層兩個大的維度進行了分析，表格如下：

三、如何全面梳理消息系統

關于消息系統，我們必須清楚的知道消息本身的底層邏輯都包含哪些主要維度，并從這些維度去分析前臺的功能設置，以及后臺需要配置的相關支撐數據，接下來筆者使用5W1H的方法，從5大維度進行分析。

1. 消息觸發的業務（what）

作為模塊重建，通過對業務部門及內部產品的調研，我們不僅需要了解觸發消息的業務都有哪些，還需要和業務方探討隨著業務的增加，有哪些新的業務需要新增消息提醒服務。

如運營部門現有的消息業務為課程打折活動，通過調研發現最近運營需要負責直播業務，此業務需要增加消息發送，我們需要先記錄下此業務。

2. 消息觸發的條件（way、when）

• 從業務維度劃分：在什么業務流程中什么時間會給用戶觸發消息，如按周期重復的時間點，或系統狀態變更、用戶操作結果等；
• 從觸發維度劃分：分為系統觸發和手動推送兩部分，系統觸發顧名思義為用戶觸發某個業務流程后自動發送給用戶，例如購買基金成功后會發送申購成功的通知；手動推送消息，需要運營同學或者業務同學在后臺進行設置后，才可以推送給目標用戶。

如：我們用直播業務流程完成的說明消息觸發的條件舉例說明：

1. 直播創建后，當運營的同學成功上架一場新的直播活動，觸發機制為運營在后臺手動推送給目標用戶，告知目標用戶有新的直播可以預約；
2. 直播預約前，用戶在直播模塊的前端頁面點擊「預約直播」按鈕，系統觸發消息提示用戶，本場直播用戶預約成功；
3. 直播開播前，系統在設置的時間節點自動發送給預約用戶，提示用戶直播開始。

3. 消息推送的人群（who）

即消息接收方，可能是系統中的全部用戶，也可能會根據權限劃分推送到某個用戶群組，或者是某個特定用戶；用戶群組的劃分，與用戶的畫像和業務緊密關聯，如果后臺已設置用戶標簽和畫像庫，則會使消息更加高效。

4. 消息推送的渠道（where）

首先我們要先梳理，消息的推送渠道一共有哪些及這些渠道的特點：

• 電話；傳統的電銷模式下，電話提醒作為獲客的主要手段，優勢在于可以強提醒用戶，并和用戶做深度溝通，但是由于過度打擾用戶，觸發方式及渠道比較特殊，成本較高，所以這種提示方式需要甄別業務實施，不建議使用。
• 短信；作為及時觸達用戶的一種方案，用于把重要且信息量較少的消息內容及時傳達給用戶的有效方法，如驗證碼、基金申購通知等。
• 郵件；互聯網2.0時代的重要的溝通方式，優勢可以把信息量較大的消息準確地推送給用戶。但是隨著移動互聯網的興起，即時通訊APP大量的出現，郵箱作為主要的pc端工作交流的渠道，所以劣勢就是無法及時提醒用戶；如常見的消息業務員激活郵箱、驗證碼、銀行賬單等依舊在使用。
• push推送；主要是配合應用的出現，iOS和安卓系統的推送方式不同，iOS可以運用自身系統的原生推送渠道，推送規則一致；安卓則因手機廠商的規則不一致，則應用無法單獨滿足，一般會使用第三方服務；需要用戶及時處理的消息則使用push推送。
• 彈窗；主要作為用戶前端操作反饋的及時通知，如訂閱成功、直播預約成功等。
• 站內信；作為主要應用消息的推送方式，可以把消息有效且準確地推送給目標用戶，并在消息中心儲存；應用類所有業務皆可使用此渠道。

然后我們再去劃分哪些業務的消息使用哪種渠道展示給用戶；如直播業務中會涉及到的消息渠道：

1. 直播創建后，運營在后臺手動推送給目標用戶，可以使用PUSH及站內信的方式展示給目標用戶直播信息；
2. 直播預約前，用戶在直播模塊的前端頁面點擊「預約直播」按鈕，系統觸發tost彈窗/站內消息提示用戶預約成功；
3. 直播開播前，系統在設置的時間節點自動發送給預約用戶push消息，提示用戶直播開始。

5. 消息推送的內容（how）

消息的內容從功能設置上分為：只讀與可操作。

• 只讀，即當前消息用戶在瀏覽后不需要做更多的操作，主要以了解為主；如申購基金成功提醒；
• 可操作反饋，即當前消息需要用戶瀏覽，且在瀏覽后做相應的后續操作；如補倉提醒。

消息分類，需要和業務深度結合去進行消息分類的劃分，目的是可以讓用戶用最短路徑瀏覽到同類的信息，大概率可分為系統消息和業務相關消息，如果有社區，還會有互動消息之內的聚合。

四、客戶端消息構建方案

通過梳理，此次主要需要對APP的應用級的消息進行重構，我們先明確優化渠道：push推送、站內信。

并通過業務側的調研，消息主要的問題是新業務不斷疊加，因為沒有進行系統的規劃，造成了現有業務消息冗雜、消息分類不明確，所以我們需要通過對業務消息進行分類合并，重新梳理消息的類型的劃分，并從前端展現形式上對消息類型作出明確的劃分。

1. Push推送前端展示現方案

Push的前端展示樣式主要有：標題+摘要、標題兩種展現形式；在不同的業務條件下，這兩種展示都能夠使用，所以要求我們設計后臺的時候需要注意字段的擴展。

我們要注意的是由于Android和iOS機制不同，此處區分兩個平臺講解。

1）Android

國內Android系統均為定制過的ROM，需將APP與各大手機廠商均有合作添加產品白名單，或將APP加入手機自帶的安全工具白名單，這樣才能保證推送不會丟失，因為和各大手機廠商對接的成本太高，一般情況下我們會接入第三方服務商（如：極光），各廠商字符規則如下：

2）iOS

iOS的推送需要通過蘋果官方服務器進行推送，跟進程存活沒有關系，前提是用戶開啟推送通知權限。

2. 站內信的優化

站內信的優化我們從兩方面入手，首先需要業務方對消息進行整合分類整理，劃分出明確的類型，從類型上減少用戶識別路徑；其次對于消息的入口、消息列表的展現形式，縮短用戶查看消息路徑。

1）消息入口

金融類的產品，消息入口常見的展現形式有底部主要導航 tab、頂部圖標入口兩種形式：

• 底部主導航特點：此類設計說明消息模塊在此產品中，用戶的使用頻率比較高，并且通過消息展示夠讓用戶做出對主要業務影響的操作。
• 頂部圖標入口特點：一般會用在產品需要消息及時觸大用戶，且不做為主要業務，設置在頂部的優勢，可以靈活地設置在需要消息支持的業務模塊的頂部。

作為金融屬性的產品，信息的及時披露對于用戶的交易和服務都是非常重要的，所以我們在設計消息入口的時候，會選擇靈活性和即時性都兼顧的產品設計，這兩種設計都可以對于重要的消息類型可提供數字 badge 作為未讀消息數量的提示。

2）消息列表

消息列表為筆者這次改造的重點區域，從消息入口點擊后跳轉到消息列表，由于業務的增加，造成消息類型不明確，消息等級錯亂，通過競品調研，主流金融類產品的消息列表為以下兩種形式，消息分類合并或者分 tab 的方式。

兩種模式的區別在于，如果消息分類比較多，還有二級消息分類的情況，則使用分類合并的產品設計，列表的展示比較簡潔，用戶可以清晰地獲取消息分類信息。

此外如果消息的二級分類列表，也可以使用二級分類列表，則可以使用tab交互方式，列表的排列順序可以按照業務重要性質進行默認排列，信息詳情按照時間的倒敘排列；大家可以按照自己的產品的具體情況設計產品方案。

3） 消息列表詳情

消息列表詳情，主要的功能使用戶不用點開消息詳情，對主要消息內容有所了解，主要有以下幾種類型：

1. 標題+時間戳+內容概要（消息內容的固定字數）：一般會用在消息頻率很高，消息內容比較長的消息或者消息字數比較少的消息列表詳情，如新聞類資訊或者交易提醒，只讀取固定字數的消息內容，需要用戶點擊進入查看更多消息內容，交互特點為未讀讀時，文字為高亮狀態，點擊查看后為變灰；
2. 標題+時間戳+內容概要（消息的關鍵內容）：對于消息內容可提取主要的概要字段的消息可以使用此列表詳情，提高用戶獲取消息內容的效率，使有效信息可以及時觸達用戶；如收益情況等；
3. 標題+時間戳+圖片+內容概要（消息的關鍵內容）：一般活動消息使用此列表詳情，消息頻次比較低的消息也可以使用，增加活動圖片可以烘托活動氣氛，增加用戶點擊欲望。

特別說明一下時間戳的規則，一般使用12或24小時制格式為標準。

• 接收24小時內，時間格式顯示展示為：時:分，如 11:02 ；
• 接收超過24小時，且在今年的范圍內，時間格式顯示展示為：月-日 時:分；如12-12 11:02；
• 接收今年以前，時間格式顯示展示為：年-月-日 時:分；如，21-12-12 11:02。

五、總結

本文是筆者在工作中對消息通知系統重構的詳細介紹，金融類的消息通知需要及時地將狀態、內容的更新觸達到用戶，用戶則可以根據收到的消息做后續判斷。如果沒有及時將重要消息觸達到用戶或者濫用消息，則失去了消息通知的初衷。

特別是針對涉及復雜任務流程的產品，消息類型繁雜，難以全面盤點消息類型，消息系統的設計就顯得尤為重要。希望通過這篇文章讓各位在設計消息通知系統的時候能夠有所借鑒。

本文由@大大大大大浪 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議