編輯導讀：消息模塊幾乎每個產品都會擁有，而消息模塊的設計是一個產品成長過程中必備的一個環節。特別是針對高頻業務消息的分發，消息模塊是業務模塊的中間件，與不同的第三方、業務系統聯動，保證企業核心業務流程的正常運轉。本文以消息中臺的思路設計方案，最終落地消息中心方案，以消息收發為基礎應用，為不同業務線提供支撐。
當我們的團隊集中度在一個產品時，我們的消息系統其實可以做到很簡單，簡單來說，核心目的是為了在適當的時間以合理的內容告知用戶他應該知道的消息。
如果將消息獨立一個系統，那麼消息本身不存在應用價值，但是在業務線中，與其他業務流程進行組合，那麼一個消息的價值可能就是一個量級的轉化。
那麼在一家成熟的企業來說，一個產品遠遠是無法支撐龐大的商業模式，所以想要提升自身的發展，無過於開源和節流。
開源即展示新的業務線，拓展新的產品線，都是一家企業打開了新挑戰，對未來是存滿不確定性的。而節流則對資源的合理利用，梳理現有業務流，剔除重複資源，減少重複勞動力。
那麼在整合消息相關資源時，我們會發現最直觀的問題：不同的產品線消息模塊重複建設，從效率層面來看，本身可以通過一條流程走完的消息流，6以多分支的方式，各自做各自的工作，形成了應用資源和開發資源的浪費。
由於每個產品線的消息模塊都是一個自成一體的系統，所以在業務人員或開發人員來說，都是一件頭痛的事情，因為團隊同時要對多套系統進行維護。
那麼我們要如何通過一個消息中臺來分發不同業務線的消息呢？下面筆者將詳細分享自己對於消息中心從0到1的設計經驗（以下內容數據方面有一定的模糊處理，僅供參考）。
一、業務背景
1. 業務調研
想要對消息業務有所了解，我們需要先找到一個突破點，即日常工作職責中必須用到消息的職能部門。我們要對業務進行調研更多是對於一個流程、一套閉環工作進行了解，如果是需求調研更多是為了解決一個點的問題，而我們現在要對於整個流程進行了解和整理。
業務調研的流程，首先是要明確為什麼要做，原始驅動力是什麼？然後明確我們最終的目標，然後以目標反推哪些人與之相關。
知道要去找哪些人後，我們要先提前把問題想好，避免大眼瞪小眼的尷尬。把你不了解的、不熟悉的都記錄下來，通過深入訪談或者會議進行溝通，訪談時採用提示引導法。通過你的問題引出他的想法以及問題。然後梳理不同角色的調研結果，通過結果總結分析問題。
前期調研方式和調研問題決定了我們後續對於消息中臺的定義和設計，所以這裡一定要仔細分別調研時的會談價值，分析時同時要基於企業不同產品線考慮，儘可能做到多角度分析比對。
同樣，如果你對消息沒有概念，對系統沒有認知，只是知道這套系統具體功能是做什麼的，這樣是遠遠不夠的。你需要對外進行調研，我們可以適當進行競品調研，這裡可以推薦大家幾個消息平臺作為學習參考，這裡僅介紹國外產品，國內的產品大家搜尋引擎找一下都可以找到。
由於很多人確實沒有對消息觸達和架構這塊並沒有經驗，而且也沒有做過開發工作，所以是需要多學習一下競品的流程與模式。當然，學習參考並不代表抄襲，因為別人有的你也抄不來，抄過來了也不代表適合你。但是我們做任何一個產品的時候都要保持敬畏之心，對競品了解是最基礎的。你可能會認為：人家做都也不怎麼樣呀，都沒有上市。但我要告訴你，當你在了解其他產品時，有一條底層邏輯要謹記，任何一個消息推送類產品只要存在市場上，那肯定有它所具備的優勢。
除了對外調研，內部的調研同樣不可缺少，這裡可以提供大家幾個方向問題，幫助大家在調研消息業務時，進行業務方面的了解。
請麻煩描述一下目前我們的消息推送全流程是如何實現的，與哪些第三方渠道對接？
目前業務方面對於消息的主動觸達方式有哪些？頻率如何？有沒有遇到什麼問題？
你們在使用公眾號推送/郵箱推送/App Push/站內信推送時是如何進行推送渠道的篩選的？不同的渠道對應的是哪些業務場景？
目前我們的消息業務是否可以滿足現有應用場景和客戶群體，對於更多有助於公司業務提升的場景中，我們有哪些不足點可以進行優化？
在沒有消息渠道觸達客戶時，我們目前是如何與客戶進行溝通的？溝通的結果如何？是否有相關的數據支撐呢？
通過幾個常規性的問題，幫助我們了解最基礎的業務流程，即使你對公司現有對業務流程非常熟悉了，我建議你也需要走一遍業務溝通，因為我們其實帶著問題的同時，並不是說只需要知道這麼幾個問題，而且通過非常規的提示引導法將我們的溝通對象進入思考狀態，讓對方逐步把細節闡述出來，然後我們從細節開始分解核心進行梳理。
2. 業務背景
在調研過後，我們對基礎業務有來一定的了解，對消息的閉環流程同樣也做到來略知一二，那麼我們要開始梳理整個業務背景。
整體業務背景是你做這件事最原始的論點，而業務數據就是你的論據。以數據結合背景闡述我們即將要做的事情。
首先我們要明確消息是用來做什麼的，在實際的業務場景中，消息分對內與對外兩大類型。
內部消息屬於單獨在我們不同業務系統裡進行分發，我們需要將不同的消息分發給對應崗位的小夥伴。
對外消息是產品與用戶溝通對話的方式，外部消息有很多不同類型，但是最終目的是一致的，都是為了觸達用戶，讓用戶及時收到節點信息。
例如電商平臺最常見的訂單退款情況，當發生訂單退款時，公司內部應由哪個職能部門去處理，我們應該將這類消息告知該部門下的哪個小夥伴。
當專門處理退款的小夥伴解決這個問題後，如果拒絕退款的情況下，我們要第一時間告知我們的客戶，讓用戶知道自己的訂單已經處理完畢，處理後通知的效率也影響用戶對產品的好感。
比如Apple的訂單取消郵件通知，只要你收到了郵件，打開了郵件，對方的數據就會同步接受，從數據中知道了你看到了這個消息。
如果訂單正常處理，同意了退款，那麼該訂單退款業務扭轉到了財務部門。同樣，財務部門相關小夥伴也需要收到消息，及時告知，及時處理對其審核，同樣處理完成後，也需要對外給予用戶不同類型的消息通知。
那麼到這裡我們已經了解消息對於產品業務的重要性，那麼為什麼我們要推出消息中心呢？
例如我們公司目前處於快速發展階段，由於公司業務線正在快速拓展，不同的產品線也正在逐步增加，與此同時，不同的產品線均需要通過消息模塊來觸達客戶。
原來我們均以功能的概念在設計，那麼業務資源和開發資源會存在大量的重複消耗，而且在維護方面也存在諸多問題，同時需要維護多套系統業務。
為了適應公司的業務發展以及未來不同場景下的消息應用，我們將引入中心概念，以中臺作為業務定義，推出新的消息中心。拆解模塊之間的職能，解決重複造輪子，反覆改問題的現象。同時將不同的消息渠道整合，為不同的業務線提供不同場景的應用支撐。
用幾句話概況一下目前現狀，問題概況以及實際影響，最終推出消息中心，在闡述背景時，儘量要結合企業目前的戰略計劃，比如目前企業的不同業務線都在中心化推送業務發展，那麼我們這叫順勢而為。反之就需要從其他角度切入，說出最恰當的理由來支撐團隊做這件事。
3. 問題原因與數據
消息應用背景明確後，那麼我們需要論證，但是口說無憑，噹噹靠你的嘴巴很多情況下無法說服團隊成員。那麼你就要拋出一些與業務方更貼切、更實際的問題。比如為什麼現階段我們要做消息中心？
產品營銷體系已搭建完成，缺乏統一觸達渠道，無法及時觸達用戶；
不同業務系統的消息通知能力獨立分散，對不同業務系統的消息無法管控；
消息數據價值未被挖掘，消息相關數據仍然未掌握在平臺，無法通過消息數據優化質量；
這些問題看上去都很重要，我們對問題也要進行簡單拆分，問題分兩類，一類屬於未來預測型問題，另外一類屬於資源合理型問題。
未來預測型問題，就是要把以後發展中會遇到的問題前置，將可見的問題拋出，這類情況更適合高速發展期的企業，比如產品營銷體系目前已搭建完成。我們的運營會通過營銷活動來提升客戶活躍度。
當我們舉行一場聖誕節活動時，一場大型活動對不同價值的客戶有不同的營銷策略，那麼在活動開始前，我們會通過郵件通知客戶。
比如我們分發了20萬張優惠券，20萬張優惠券分發後，均以郵件通知和簡訊通知觸達，如果沒有及時的數據反饋，那麼最終我們無法知道這10萬封郵件最終會有多少的打開率與點擊率。而10萬封簡訊會被多少用戶攔截拒絕亦或者打開。
平臺觸達用戶的消息是很容易體現活動效果或推廣效果，通過最終的效果反推未來的客戶營銷策略，如缺失了這部分的一體化消息，會影響用戶後續的消息關注度。
就像這封Quora的郵件，消息反饋的設計可以整理為三個角度：首屏數據、內容數據、整體數據。單單通過一封郵件內容，推送給幾十萬個用戶即可獲得到海量的用戶數據，從中我們可以分析出不同類型用戶的喜好，對此我們可以從數據進行優化，滿足用戶的需求。
那麼資源合理型問題更適合想要進行節流方向的產品方向，直接從現有的案例來引導，目的在於建立消息資源的重要性。
例如目前我們企業整體還沒有屬於自己的消息平臺，營銷郵件和營銷簡訊都是通過第三方來進行發送。而由於業務的快速發展，單單郵件就需要發出2000萬封左右，在不計算人工成本的情況下，每月第三方的消息推送工具費用達到$50000，對於企業自身來說，這就是一種資源的浪費。
從簡單的一句話中，我們就知道這個問題的影響面以及價值，而這些數據都需要通過實際與業務、銷售、運營進行調研得出，通過實際的數據集合反饋問題。
在整個業務背景中，我們不僅在前期調研數據，了解實際問題。而且我們要拋出企業現階段的問題，問題不多但是要尖銳，特別是價值敏感性人群會對這部分問題特別感冒。結合企業戰略為方向進行取捨。
二、方案目標
1. 方案目標
怎麼理解方案的目標？方案目標即最終要達到的目的。在設計目標時，儘可能與企業目前戰略目標一致。正如任正非說的「力出一孔，利出一孔」，戰略聚焦是公司有組織能力的體現。
任何一套業務都要與戰略保持一致，當然，戰略目標也在變化，唯一不變都就是變化，所以我們也要適應變化，比如我們現階段都戰略目標是為了實現市場佔有率達到20%，而目前市場佔有率只有10%，如何從消息中心層面幫助整個企業提升效益，這就是我們要做的。
我們目標設計時，需要考慮三個核心；
可落地性強；
可預期設計；
基於現有數據設計；
一句話來概況就是這個目標要高且完成率要儘可能高，這裡的目標僅僅指的是長期目標，長期可實現的目標作為消息中心的方案目標。
2. 整體架構方案
在了解方案背景以及實際問題後，我們就需要拋出方案。而方案中最核心的就是架構，消息中心架構代表了整個方案組合內容，往往架構代表整個骨架，而這個骨架已囊括了未來我們大多數設計和應用場景。
這裡我們要拋出的是整體的業務架構，至於後面的功能架構和技術架構不需要在此處體現。
消息中心整體由App Push服務、系統通知服務、微信推送服務、簡訊服務、郵件服務、瀏覽器推送服務、聊天室系統、工單系統、內部消息系統九個基礎模塊支撐。
以上僅僅是筆者在設計消息時，公司目前的消息相關業務架構以及未來設計，不同的產品業務肯定會有更多更加靈活的組合方式。
這九大基礎模塊中，每個消息都對應不同的場景，比如：
App push：針對現有A產品線的服務支撐，通過定期定向定量的推送促進客戶打開率以及活躍度，同時B產品線以及C產品線的App正在進行構建中，後期同樣也可以支撐這兩條產品線。
微信推送服務：截止2020年底，目前國內微信擁有11億多用戶量，而針對國內業務我們除了簡訊服務觸達，微信推送目前是主流渠道之一，而且微信推送包括小程序推送和公眾號推送，這兩類幾乎不需要成本，對於國內用戶多觸達率更高。雖然微信推送會有內容方面的限制，但是我們的推送大部分都是基於與用戶的互動業務消息，是用戶願意主動接受的消息。
同樣，我們在設計消息架構的時候，必須要考慮的是消息的重疊度，即A類消息與B類消息的觸達場景重疊度。
比如我們設計A類消息時，必須要考慮這類消息推送的頻率以及人群，這是這類消息的價值點，避免重疊度是為了最大程度降低公司重複資源以及對同類客戶的打擾。因為過於頻繁的打擾客戶，不僅會降低品牌好感度，甚至客戶會拒收或者屏蔽平臺的任何消息。
那么九大服務用來為不同的產品線作為服務支撐，包括項目A和項目B，產品A和產品B，CRM系統、MPC系統……
簡單來說，消息中心為不同業務應用平臺提供消息系統的支撐，幫助不同業務系統完成基礎消息的閉環流程。
不同的消息對於不同的業務線有哪些具體效益，我們可以舉例說明，比如產品A是一個國外SaaS電商平臺，那麼針對國外的用戶群體，我們調研了A、B兩類客戶群體。
通過分析這兩類客戶群體，我們發現行為模式中有一些共通點。由於網際網路發展周期原因，目前仍處於PC網際網路時代後期。
PC網際網路時代中郵件是主要通訊方式，所以我們針對這類用戶的通知，特別是偏向業務相關、營銷相關的通知會以郵件為核心，作為高頻觸達的手段，有效與我們的客戶進行雙向的溝通。
而另外一方面，PC中必然包括了瀏覽器，而Chrome長期佔據國外瀏覽器市場的近70%，幾乎達到了壟斷的地位。
所以針對這類客戶觸達，我們會首先考慮用瀏覽器推送進行重要業務消息的通知。由於這類通知是單向的通知，無法與客戶進行雙向溝通渠道，所以這類消息我們會降低發送頻率，提升推送質量，保證有效觸達。
同樣，我們也考慮到瀏覽器市場的豐富多樣性，所以根據2019年某市場分析數據，處於第二位的火狐瀏覽器以及Edge瀏覽器各佔據近10%，所以後續我們也會根據最終觸達效果考慮增加不同瀏覽器的推送。
後期我們會將以上九大基礎服務產生的業務數據進行整合，以消息類型緯度對數據進行分析，通過企業內數據中心反饋的數據，對最終的推送效果進行二次、三次優化。
消息的優化肯定是基於大量的數據，而不同的公司業務線不同，數據來源也會不一樣，比如我們的數據是全部來源於數據中心，由數據中心進行初步的數據清洗，然後我們負責通過接口進行調用、查看、匯總。如果沒有數據中心，那麼大部分消息數據會存儲在消息中心，由於消息中心進行數據的匯總整理；
最終我們會通過消息數據來優化觸達率、點擊率、打開率、轉化率、停留時長等等，實現對消息的內容、頻次、人群精準推送。
三、方案拆分
1. 階段拆分
方案的階段拆分是一件極為痛苦的事情，因為實際上你的方案要做的是一個大方向的事情，但是在階段拆分時，你要開始細化，細化到每一階段應該完成什麼。
在這裡，根據消息中心的目標，我們拆解成三個階段：
產品打磨期：確定產品PMF（Product Market Fit 產品市場匹配度）幫助我們快速調整產品方向。最終驗證產品開發與應用的設計是否成立可用。
產品發展期：通過消息結合業務系統挖掘客戶價值，通過不斷放大客戶價值，組合不同職能團隊，將消息體系進一步完善，做到精細化運營客戶。
產品迭代期：通過市場反饋形成關鍵數據指標，倒推產品提升核心漏鬥數據，提升每個業務數據指標，降低每個流程的斷點率與流失率。
那麼我們將三個大階段繼續拆分，拆分成不同的版本，比如第一階段的產品打磨期，我們將會拆解成幾個大版本，每個大版本再拆解成3-5個不同的小版本；
我們在設計版本迭代時，根據現階段的目標不同可以酌情進行調整，但是便於我們的任務可執行可落地，我們必須進行多次拆解。
產品規劃中內容有一定刪減（僅供參考）
每個階段都應該有對應都階段性目標，這裡需要再次說明都是，每個階段性目標都要以大版本迭代為核心。
以小版本進行迭代有很多優勢，比如我們可以增加階段性產出價值，並且同時降低試錯的成本，不斷通過內部使用進行迭代，特別是首個版本上線後，除了主線外，我們還需要另外有一個快速更新對版本，這裡筆者稱之為快速版本。
快速版本是為了解決大版本之間存在的問題，並且保證系統在穩定的線上環境時可以正常處理業務，保障業務之間的抗風險能力。以快速版本作為產品快速迭代形式更新，既能減少每個小版本之間的摩擦又可以提高整體產品的質量。
2. 版本拆分規劃
首個版本其實是最簡單的，因為我們的目標是最明確的，做基建，打地基。首個版本我們要明確在有目標且只有一個目標的大前提下進行拆分。
將每個小版本的需求通過表格的形式羅列起來，通過表格你可以清晰的看到在某個版本計劃下，我們應該做哪個模塊下的哪些需求功能，這些需求的優先級如何。
那麼對應的需求功能具體可以實現什麼，預期完成時間是什麼時候，具體有誰來做。最終技術實現時間預估在什麼時候，這些信息內容都可以通過表格一目了然。
當然，這些表格裡面的內容除了你自己看，也需要定時定期的更新，因為你自己要根據表格裡面的內容對自己未來一段時間的工作進行規劃排期。而我們的老大可能也需要看到你的進度，那麼你的這張表就是你的預期產出時間以及未來的時間點。
首先要明確解決的問題，完成該目標後，我們可以解決什麼問題。例如我們v0.11版本要完成消息中心整體架構的搭建，並完成對產品A業務系統的整體消息支撐。
由於產品A屬於面向世界的產品，所以不僅僅是針對國內的客戶，更多是觸達到國外客戶，所以我們會把現有的郵件服務遷移到消息中心，集中一個中心對外出口推送郵件。
如果只有一套郵件服務，其實這個問題還好解決，那麼如果我們有多套業務，如何解決這個問題？事實上，如果你對消息了解，你就應該知道一種推送方式其實有多種形式可以接入。
比如第三方郵件平臺服務、自建郵件服務、郵件代發服務……那麼如何選擇？結論是：根據自身業務應用場景選擇，在設計消息模塊時最忌憚「拍腦袋」行為。每一步都要為未來都應用考慮，且每一步都會造成企業成本，如果一步做錯，後續會影響整條業務線的消息。
所以當你不知道如何選擇的時候，我們可以先把自己的方向列好，然後把每個方向的市場優劣勢都曝光出來，儘量在優劣勢中進行判斷。但是這裡極有可能會被自己都主觀判斷和認知所影響，所以在完成整理後，可以與同事、小夥伴探討幾分鐘。
最終從幾個方案中選擇最合適的，這裡不管是郵件服務，還是App push、瀏覽器推送…都是有不同的解決方案的，作為產品人應該學會找到所有的方案然後從中挑選對於不同產品下的最佳應用方案。
在確定方案後，接下來就要明確方案核心流程，方案核心流程必須要有多個角色，因為一個中心肯定會給予多個業務系統做支撐，所以我們的核心業務流程要保持一致。
如上圖，這裡我們可以拿著一個客戶觸發業務節點，這麼一個基礎的場景，把整個方案的基礎邏輯闡述清除。具體描述比如：
我們通過客戶端觸發業務節點，然後不同的業務系統會接受到客戶端傳遞的參數，然後業務系統由自身去組裝業務節點的參數，通過不同的參數發送到消息中心。消息中心接到相關指令後，進行基礎的校驗，校驗通過後開始對消息類型進行判斷，比如剛剛所說的郵件服務，郵件需要走第三方的通道，所以我們需要組裝第三方需要的參數，然後通過第三方消息平臺發送，第三方會返回發送的結果給我們。然後我們對數據進行最終對存儲與校驗。那麼最終消息會由第三方發送給我們的客戶端，完成消息的觸達。
核心業務流程其實很簡單，但是對於不懂相關業務的小夥伴來說可能會有些勉強，所以我們需要用簡單易懂的文字幫助不同認知階級的人理解。
基於核心業務流程理解後，我們也需要有更具體抽象的當前階段的規劃業務流程，比如說我們的郵件是怎麼發送怎麼創建的？我們的瀏覽器推送是如何發送如何創建的？
細化到一個業務流是如何執行的，那麼你需要把具體這個業務流是如何走通整理出來，有一套完整的閉環，從消息的創建到消息的編輯。
在實現流程閉環時，我們始終要記得本階段、本版本下我們的任務是什麼，不需要做太多優化、美化的任務。
如果當前階段我們只是完成消息的觸達，那麼我們的核心任務就是如何把這個目標實現。因為我們在規劃時候無法做到十全十美，肯定會有一些細節是沒想到的，所以我們就需要用一個個小版本堆積起來，然後做到統一處理。
對於當前版本規劃已經明確後，我們這一階段對任務就完成了，以上工作需要細心梳理，每個細節都可能成為你方案被失敗打回重塑的理由。
3. 原型設計
以上我們完成了消息中心近60%的工作，那麼剩下40%就需要你在原型中體現，我們就要著手拆解原型，對原型進行優化設計。
設計原型前，我們需要先與前端溝通，了解一下我們前端的技術棧有哪些，比如你們公司前端目前的前端技術架構採用Ant-design（比較常見的Ant-design、Layui、element），那麼你可以去網上找一下對應的UI框架元件庫。
大部分設計架構在網上都是可以找到Axure的元件庫，可以之間載入到Axure使用，好處就是你的前端很很容易可以看懂你需要的模塊，減少重複的工作量。
在原型設計中，我們落實到每個細節，方案要大而廣，具有前瞻性視角。原型要小而細，落實到每個細微之處。
筆者採用的是Ant-design，比如在消息列表頁面，左側是簡單的logo、一級菜單和二級菜單，右側是核心消息列表（功能頁面），這種架構在多數國內的管理結構中都是比較合理的。另外需要注意的是，即使是在有框架的情況下，請不要發揮你天馬行空的想像力，因為我們是內部使用效率優先，要學會適度適應每個人的接受能力，每個人的認知水平不足，如果你的原型設計過於「華麗」，有一定可能會降低入手門檻。
如果我們採用元件庫做原型基礎設計，那麼我推薦你加上交互，比如我們的列表頁面有一個失效按鈕，是為了防止消息的異常情況下進行攔截，那麼這種高危操作是需要進行二次確認的，所以我們點失效的時候，就要出現對應的提示內容，需要我們輸入失效的原因。
在設計時，同樣我們也會考慮在負面操作時，對【確認】按鈕進行失焦處理，將焦點集中在【取消】按鈕，這樣會一定程度上引起操作人的二次思考，降低出錯機率。
原型中除了基本的交互，還有具體的開發說明，當然，這點可以後置補充。
多數情況下，我們一開始不需要對細節進行補充，在技術評審的時候需要補充相關的細節，需要注意的是，我們在做一個消息中心（任何一個模塊）時，我們都要對細節把控到位。
只要是在工作環境中，開發說明決定最終你與技術後期溝通的頻率，但是作為開發出生的筆者，在國內工作時經常會看到某些產品人的說明是這樣的。
從產品的角度可能沒錯，但是從開發的角度來說，心裡不禁感嘆：這是個啥？
如果你真的是在一家正規公司上班，有正規的團隊，正在帶領團隊從0到1設計產品時，請按照標準的開發說明進行標準，包括每個欄位的長度、校驗格式等等。
舉個例子，比如這是我們的消息推送頁面，那麼我們這裡有8個地方需要說明（內容已經過一定刪減）。
針對這8個數據，我們要進行統一說明，每個說明點可以將你可以想到的內容以及需要注意的點都進行簡單的細緻的描述。
具體的說明格式其實並沒有一個標準，每個人都有自己不一樣的習慣，比如我們是有數據字典，所以我們會有相應都數據編號。然後對應都數據欄位的說明，都會放在數據說明，相應的交互說明也需要寫入。
如果你在設計初版系統時，你不一定需要按照筆者這樣做，因為筆者這樣做也不一定是對的，僅僅是因為筆者自己也是一位獨立開發者，曾經也在團隊協作中深受其害，所以對說明要求會略多。但是我們的目標是一致的，都是為了提高團隊效率，降低溝通成本。所以你需要把每個細節都說明清楚，這都是你未來與開發溝通，甚至討論爭論的原因。
原型部分網上的文章眾多，筆者就不一一贅述，萬變不離其宗，事就是這麼個事，基於方案架構和流程的前提下，只要你把這個事說清楚了，你不管是用Axure、墨刀還是Word、Photoshop，我相信都是可以達到完成原型設計的目標。
四、總結反思
1. 聽取意見
當你完成整個消息中心的設計後，請謹記，要聽取他人意見。學會聆聽，因為完成這件事其實並不難，因為你在網上也可以找到很多細節可借鑑，但是你借鑑的不一定適合團隊。所以你可以與主管、老大討論，聽取意見。
因為消息中心是需要長期與多部門、多產品協調溝通的，如果你一開始在做的時候就沒有與其他人多討論，那麼後期由於業務拓展，很有可能整體架構很容易被推翻重構。
當然，關於團隊的意見，筆者也有個題外話。筆者在這個階段經常會發現身邊的小夥伴會存在兩個極端，要麼從來不聽取他人的意見，即使聽了也不改，改了心裡也是不服氣的。要麼對別人的話言聽計從，幾乎不需要自己思考，別人說啥就啥，別人說要改什麼，他立即按冀索圖解決某件事。
這兩者都不能解決問題，前者很容易積累情緒，造成團隊分裂。後者很容易長期變成「工具人」，有些人說，工具人有啥不好的，不需要思考也挺不錯的。但是往往到了35歲以後，往往會有焦慮圍繞著這些人，因為這些人在過往的工作中並沒有學到什麼，沒有建立自身知識儲備。
2. 結語
對於消息中心來說，根據實際業務線的豐富度，相應應用場景也會更加複雜，所以我們在設計消息的落地場景時，對於不同場景的適用性挑戰也會增大。但殊途同歸，基於整個企業戰略去做更多思考，總歸會讓價值落地。
筆者也在不斷的復盤和總結中完成這一次整體架構的設計，當然，這僅僅只是開啟，因為我們目前也僅僅完成了第一版的產品設計工作。基於現有規劃的未來，肯定還會遇到更多的難題，但這也是身為產品的樂趣之一，希望能與正在看這篇文章的你共同成長。
#專欄作家#
SenYi，公眾號：產品體驗派，人人都是產品經理專欄作家。樸實無華的跨境電商產品人，致力於挖掘產品價值與商業化觀察。
本文原創發布於人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基於 CC0 協議