起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品經理如何基于需求迭代產品（下篇3）：產品的整體設計之邏輯層和交互層
產品的整體設計包括業務層、系統層、邏輯層和交互層等四個層面。上一篇《產品經理如何基于需求迭代產品（下篇2）：產品的整體設計之業務層和系統層》講了前兩個，本文主要是講述整體設計中的邏輯層和交互層，以及局部設計。
整體設計
邏輯層：實體建模、角色結構、邏輯流程
邏輯層顧名思義，就是邏輯上的東西，是系統和業務的內在邏輯。邏輯明確才能開發出來，邏輯不明確只是空中樓閣。邏輯層分實體建模、角色結構和邏輯流程，實體建模是說明系統里有哪些主要內容流轉，角色結構是說明系統有哪些人使用，邏輯流程是說明系統是怎么運作的。下面進行具體描述。
1、實體建模
實體，一般是指能夠獨立存在，作為屬性定位基礎的東西。業內的實體概念具有此哲學思想以外，還是一個特定的軟件模塊。例如電商中的sku、品類、訂單等均可稱為實體，只是有些實體重要有些不重要。
實體建模，就是從業務流程抽象出實體，部分流程以實體為中心，便于理解和管理。例如抽象出訂單實體，就可以根據流程管理訂單的生命周期（狀態）。
實體建模注意兩點：實體的屬性與生命周期和實體間的關系。
（1）實體的屬性與生命周期
一開始，選擇哪些是主要實體的時候，重點要看業務流程中流動的是什么東西，有時候表面上看不出來，就需要思考共同點和本質。舉個例子，在業務流程上，管理員會在一段時間內安排給用戶一系列工作，工作是批量安排的，并沒有明顯的實體，通過思考后抽象出【任務】的實體，【任務】又分【母任務】和【子任務】，前者指管理員設置的任務，后者指用戶自己的任務。
每個實體都會自己的屬性，訂單會有訂單號、狀態、賣家ID、買家ID等等，屬性是用來做判斷或者與其他實體關聯的，訂單的狀態就是做判斷，賣家ID和買家ID則是與其他實體關聯，把主要的想到即可，具體。生命周期其實也是一種屬性，單獨拿出來為了凸顯它的重要性，要包含實體的所有生命周期，否則會出現異常。
（2）實體間的關系
某種實體關系（矩形=實體，菱形=關系，橢圓=實體的主要屬性）
實體間的關系是指實體的邏輯關系，包括實體和實體的關系以及實體屬性和實體的關系。實體和實體之間是一對多、多對多、多對一還是一對一，例如一個帳號可以有多個訂單，一個訂單有多個SKU。實體屬性和實體的關系，例如上面例子的【母任務】創建后才會產生【子任務】，而【子任務】又有完成、歸檔的概念，因此【母任務】創建后某些屬性的修改就要注意。一般來說，實體和實體都是互相獨立的，【子任務】這種算是特殊情況。
2、角色結構
每個系統必定有角色，只是角色多少的區別。此處的角色，是系統邏輯層面的角色，而不是功能模塊層面的角色。例如電商后臺的用戶都是公司內部人員，分各部門，在系統邏輯層面角色就是內部人員，在功能模塊層面各部門就是不同角色，通過賬號-角色-權限來控制。
系統邏輯層面的角色劃分是非常清晰的，角色所對應的場景是完全不同的，按需為角色設計賬號體系、選擇合適端（PC客戶端、APP、PCweb端、mobileweb端等）、設計風格等一切和產品相關的東西。角色由業務場景所決定，針對角色（目標用戶的另一層意思）設計產品要基于場景和核心訴求。例如boss直聘中在一個APP端中包含boss和牛人兩種角色，入口是一致的可切換，賬號體系打通，boss的核心訴求就是招到合適價位的牛人，牛人的核心訴求就是找到心儀的崗位；滴滴分乘客端和司機端，入口不一致，賬號體系部分打通，乘客的核心訴求就是打到心儀的車，司機的核心訴求就是跑滴滴賺錢。
把握角色的核心訴求，作為指導思想和綱領，指導需求規劃和產品設計，這也是內聚性的體現。無論角色、模塊、功能、系統、實體等等都能用一句宗旨總結是干嘛的，那這句宗旨就是指導思想、綱領和邊界，做之前都先想想符不符合宗旨，有宗旨才有高內聚。宗旨是可以調整的，但是不能隨便調整，要想清楚想明確。
角色與流程密切相關。角色就是操作的人，是流程中非系統自動以外所有操作的執行者，確定了角色才能確定流程，確定了流程才能確定角色所需功能，這樣才有交互層的東西，角色的重要性毋庸置疑。
3、邏輯流程
邏輯流程就是要把實體、角色和功能（操作/判斷/子流程）之間的關系想清楚想通透。每個模塊包含哪些功能都會在梳理邏輯的過程中找到答案，也可以順便理清楚模塊和功能的優先級，后續可補充到產品規劃中。
邏輯流程以不同的目標為中心會呈現出不一樣的流程，以業務為中心的流程重點講述的是業務的過程，以實體為中心的流程重點講述的是實體的生命周期（狀態），以操作為中心流程重點講述的是交互和判斷（也可以到交互層再畫）。
廣告規劃流程（業務流程）
極其簡單的訂單狀態流程圖
兌吧積分商城交互流程圖（更注重開發層面）
以業務為中心的流程就是要把上述的實體、角色和功能（操作/判斷/子流程）集合到一張圖上。要體現出以下兩點：1.每個角色在業務中的作用，其實就是每個角色的主要功能或者操作 2.核心功能，與業務直接相關的功能或者操作，例如點擊【去支付】訂單生成等，如果非核心功能流程太多可以直接用子流程代替。
以實體為中心的流程要體現出實體的生命周期，設計實體的生命周期的時候要符合客觀事實，系統中很多地方的判斷都是要根據實體的生命周期的。要體現出以下點：1.包含實體的所有生命周期，絕對不能遺漏 2.什么操作/判斷會調整實體的生命周期，邏輯合理描述清晰。
主要的流程可以畫出來給開發看，其他可畫可不畫，但是腦子中一定要有邏輯，否則就不是個稱職的產品經理。
交互層：模塊功能、頁面結構、界面原型
交互層有很多文章講了，這塊太基礎了我就不多說，就只講最重要的兩點：
1. 交互層必須要基于業務、系統和邏輯層進行設計，否則就只是空中樓閣，模塊功能中，具體哪個模塊是來源于系統層的模塊抽象，要有哪些功能是來源于邏輯層的邏輯流程。頁面結構中，放在哪個端和邏輯層的角色結構密切相關，具體怎么放和邏輯層的邏輯流程密切相關。
2. 應該在業務層、系統層和邏輯層已經通過需求方、研發團隊、運營團隊等相關人員的評審之后，才開始設計交互層。因此，在產品設計的四大層面中要多和團隊、用戶等相關人員交流，而不是閉門造車，車都造出來了發現有問題要推倒重來，那麻煩可就大了。
局部設計
局部設計是指在平常功能性非大版本或者非重構的迭代，多以增減修改某個功能/模塊、體驗等不觸碰核心業務邏輯的迭代為主。下面說明下注意事項。PS：具體還是得看需求和實際情況，每個公司和產品都不一樣的。
1. 明確修改的層級
明確改動處于業務層、系統層、邏輯層、交互層四層中的那一層，層級越高一般涉及到的東西就越多，越是要謹慎小心。
2. 梳理改動相關的舊邏輯
根據層級往下羅列與改動相關的邏輯、功能、交互、組件等，先抽離出與改動相關的系統，再從系統中抽離出與改動相關的模塊，再從模塊中抽離出與改動相關的功能和交互，
必須和技術負責人、架構師、后端工程師等成員進行溝通，清除技術層面的問題，并商量解決，有些問題是產品看不到但是技術看得到的。必須和測試等成員溝通，核對改動的影響內容，對用例查漏補缺。必須和設計師溝通，核對改動的交互和視覺細節，明確目標用戶和使用場景。
3. 梳理改動相關的新邏輯
根據梳理出來的舊邏輯和目標用戶的使用場景，根據新需求逐一填上新邏輯，和完形填空一樣。如果需要在別處新增，就需要從那個模塊的所有邏輯中入手，基于使用場景和用戶路徑等設計新的邏輯。數據、實體相關的要考慮舊數據如何處理，例如消息多了個已讀未讀狀態，舊數據是默認為已讀還是默認為未讀。
4. 相關問題方案和改動在發版前告知其他部門
?在改動的方案出來之前，要和需求方及相關人員多溝通；在改動的方案出來之后，要抄送給需求方及相關人員一份，保證信息同步，共同決策。
在發版前，把每個部門相關的文檔，例如需要給客服部門的QA要提前準備好，并發送給各個部門的對接人員，提前準備。
5. 發版后跟進新改動的問題和數據反饋
版本發布后，告知各方并進入反饋階段。持續跟蹤新改動的相關問題和數據反饋，以便明確版本效果，如果發現邏輯和設計漏洞要迅速處理，大的漏洞不要出現，否則會造成很大損失。預先進行小規模的ABtest很有必要。
《產品經理如何基于需求迭代產品》系列的四篇文章終于寫完了，本系列更注重的是產品架構設計的內容，希望大家能夠有所收獲。
在寫文章的時候，發現有很多內容還可以寫，例如某垂直領域知識、某小模塊的細節設計、通用的方法論等，我也會持續輸出的，請大家持續關注，敬請期待。
相關閱讀
產品經理如何基于需求迭代產品（下篇01）：產品設計的高內聚低耦合
產品經理如何基于需求迭代產品（下篇2）：產品的整體設計之業務層和系統層
作者：Vency，公眾號 Vency不二或者vencybu2
本文由 @Vency?原創發布于人人都是產品經理。未經許可，禁止轉載。
已經反復讀了好多篇，每一次讀，感覺理解的更深入一些。我是個UI設計師，計劃培養成具備產品思維的UI設計師。謝謝您的分享！?。?！
對你有幫助就好~~~加油加油！ ??