產(chǎn)品的整體設(shè)計包括業(yè)務(wù)層、系統(tǒng)層、邏輯層和交互層等四個層面。上一篇《產(chǎn)品經(jīng)理如何基于需求迭代產(chǎn)品（下篇2）：產(chǎn)品的整體設(shè)計之業(yè)務(wù)層和系統(tǒng)層》講了前兩個，本文主要是講述整體設(shè)計中的邏輯層和交互層，以及局部設(shè)計。

整體設(shè)計

邏輯層：實(shí)體建模、角色結(jié)構(gòu)、邏輯流程

邏輯層顧名思義，就是邏輯上的東西，是系統(tǒng)和業(yè)務(wù)的內(nèi)在邏輯。邏輯明確才能開發(fā)出來，邏輯不明確只是空中樓閣。邏輯層分實(shí)體建模、角色結(jié)構(gòu)和邏輯流程，實(shí)體建模是說明系統(tǒng)里有哪些主要內(nèi)容流轉(zhuǎn)，角色結(jié)構(gòu)是說明系統(tǒng)有哪些人使用，邏輯流程是說明系統(tǒng)是怎么運(yùn)作的。下面進(jìn)行具體描述。

1、實(shí)體建模

實(shí)體，一般是指能夠獨(dú)立存在，作為屬性定位基礎(chǔ)的東西。業(yè)內(nèi)的實(shí)體概念具有此哲學(xué)思想以外，還是一個特定的軟件模塊。例如電商中的sku、品類、訂單等均可稱為實(shí)體，只是有些實(shí)體重要有些不重要。

實(shí)體建模，就是從業(yè)務(wù)流程抽象出實(shí)體，部分流程以實(shí)體為中心，便于理解和管理。例如抽象出訂單實(shí)體，就可以根據(jù)流程管理訂單的生命周期（狀態(tài)）。

實(shí)體建模注意兩點(diǎn)：實(shí)體的屬性與生命周期和實(shí)體間的關(guān)系。

（1）實(shí)體的屬性與生命周期

一開始，選擇哪些是主要實(shí)體的時候，重點(diǎn)要看業(yè)務(wù)流程中流動的是什么東西，有時候表面上看不出來，就需要思考共同點(diǎn)和本質(zhì)。舉個例子，在業(yè)務(wù)流程上，管理員會在一段時間內(nèi)安排給用戶一系列工作，工作是批量安排的，并沒有明顯的實(shí)體，通過思考后抽象出【任務(wù)】的實(shí)體，【任務(wù)】又分【母任務(wù)】和【子任務(wù)】，前者指管理員設(shè)置的任務(wù)，后者指用戶自己的任務(wù)。

每個實(shí)體都會自己的屬性，訂單會有訂單號、狀態(tài)、賣家ID、買家ID等等，屬性是用來做判斷或者與其他實(shí)體關(guān)聯(lián)的，訂單的狀態(tài)就是做判斷，賣家ID和買家ID則是與其他實(shí)體關(guān)聯(lián)，把主要的想到即可，具體。生命周期其實(shí)也是一種屬性，單獨(dú)拿出來為了凸顯它的重要性，要包含實(shí)體的所有生命周期，否則會出現(xiàn)異常。

（2）實(shí)體間的關(guān)系

某種實(shí)體關(guān)系（矩形=實(shí)體，菱形=關(guān)系，橢圓=實(shí)體的主要屬性）

實(shí)體間的關(guān)系是指實(shí)體的邏輯關(guān)系，包括實(shí)體和實(shí)體的關(guān)系以及實(shí)體屬性和實(shí)體的關(guān)系。實(shí)體和實(shí)體之間是一對多、多對多、多對一還是一對一，例如一個帳號可以有多個訂單，一個訂單有多個SKU。實(shí)體屬性和實(shí)體的關(guān)系，例如上面例子的【母任務(wù)】創(chuàng)建后才會產(chǎn)生【子任務(wù)】，而【子任務(wù)】又有完成、歸檔的概念，因此【母任務(wù)】創(chuàng)建后某些屬性的修改就要注意。一般來說，實(shí)體和實(shí)體都是互相獨(dú)立的，【子任務(wù)】這種算是特殊情況。

2、角色結(jié)構(gòu)

每個系統(tǒng)必定有角色，只是角色多少的區(qū)別。此處的角色，是系統(tǒng)邏輯層面的角色，而不是功能模塊層面的角色。例如電商后臺的用戶都是公司內(nèi)部人員，分各部門，在系統(tǒng)邏輯層面角色就是內(nèi)部人員，在功能模塊層面各部門就是不同角色，通過賬號-角色-權(quán)限來控制。

系統(tǒng)邏輯層面的角色劃分是非常清晰的，角色所對應(yīng)的場景是完全不同的，按需為角色設(shè)計賬號體系、選擇合適端（PC客戶端、APP、PCweb端、mobileweb端等）、設(shè)計風(fēng)格等一切和產(chǎn)品相關(guān)的東西。角色由業(yè)務(wù)場景所決定，針對角色（目標(biāo)用戶的另一層意思）設(shè)計產(chǎn)品要基于場景和核心訴求。例如boss直聘中在一個APP端中包含boss和牛人兩種角色，入口是一致的可切換，賬號體系打通，boss的核心訴求就是招到合適價位的牛人，牛人的核心訴求就是找到心儀的崗位；滴滴分乘客端和司機(jī)端，入口不一致，賬號體系部分打通，乘客的核心訴求就是打到心儀的車，司機(jī)的核心訴求就是跑滴滴賺錢。

把握角色的核心訴求，作為指導(dǎo)思想和綱領(lǐng)，指導(dǎo)需求規(guī)劃和產(chǎn)品設(shè)計，這也是內(nèi)聚性的體現(xiàn)。無論角色、模塊、功能、系統(tǒng)、實(shí)體等等都能用一句宗旨總結(jié)是干嘛的，那這句宗旨就是指導(dǎo)思想、綱領(lǐng)和邊界，做之前都先想想符不符合宗旨，有宗旨才有高內(nèi)聚。宗旨是可以調(diào)整的，但是不能隨便調(diào)整，要想清楚想明確。

角色與流程密切相關(guān)。角色就是操作的人，是流程中非系統(tǒng)自動以外所有操作的執(zhí)行者，確定了角色才能確定流程，確定了流程才能確定角色所需功能，這樣才有交互層的東西，角色的重要性毋庸置疑。

3、邏輯流程

邏輯流程就是要把實(shí)體、角色和功能（操作/判斷/子流程）之間的關(guān)系想清楚想通透。每個模塊包含哪些功能都會在梳理邏輯的過程中找到答案，也可以順便理清楚模塊和功能的優(yōu)先級，后續(xù)可補(bǔ)充到產(chǎn)品規(guī)劃中。

邏輯流程以不同的目標(biāo)為中心會呈現(xiàn)出不一樣的流程，以業(yè)務(wù)為中心的流程重點(diǎn)講述的是業(yè)務(wù)的過程，以實(shí)體為中心的流程重點(diǎn)講述的是實(shí)體的生命周期（狀態(tài)），以操作為中心流程重點(diǎn)講述的是交互和判斷（也可以到交互層再畫）。

廣告規(guī)劃流程（業(yè)務(wù)流程）

極其簡單的訂單狀態(tài)流程圖

兌吧積分商城交互流程圖（更注重開發(fā)層面）

以業(yè)務(wù)為中心的流程就是要把上述的實(shí)體、角色和功能（操作/判斷/子流程）集合到一張圖上。要體現(xiàn)出以下兩點(diǎn)：1.每個角色在業(yè)務(wù)中的作用，其實(shí)就是每個角色的主要功能或者操作 2.核心功能，與業(yè)務(wù)直接相關(guān)的功能或者操作，例如點(diǎn)擊【去支付】訂單生成等，如果非核心功能流程太多可以直接用子流程代替。

以實(shí)體為中心的流程要體現(xiàn)出實(shí)體的生命周期，設(shè)計實(shí)體的生命周期的時候要符合客觀事實(shí)，系統(tǒng)中很多地方的判斷都是要根據(jù)實(shí)體的生命周期的。要體現(xiàn)出以下點(diǎn)：1.包含實(shí)體的所有生命周期，絕對不能遺漏 2.什么操作/判斷會調(diào)整實(shí)體的生命周期，邏輯合理描述清晰。

主要的流程可以畫出來給開發(fā)看，其他可畫可不畫，但是腦子中一定要有邏輯，否則就不是個稱職的產(chǎn)品經(jīng)理。

交互層：模塊功能、頁面結(jié)構(gòu)、界面原型

交互層有很多文章講了，這塊太基礎(chǔ)了我就不多說，就只講最重要的兩點(diǎn)：

1. 交互層必須要基于業(yè)務(wù)、系統(tǒng)和邏輯層進(jìn)行設(shè)計，否則就只是空中樓閣，模塊功能中，具體哪個模塊是來源于系統(tǒng)層的模塊抽象，要有哪些功能是來源于邏輯層的邏輯流程。頁面結(jié)構(gòu)中，放在哪個端和邏輯層的角色結(jié)構(gòu)密切相關(guān)，具體怎么放和邏輯層的邏輯流程密切相關(guān)。

2. 應(yīng)該在業(yè)務(wù)層、系統(tǒng)層和邏輯層已經(jīng)通過需求方、研發(fā)團(tuán)隊(duì)、運(yùn)營團(tuán)隊(duì)等相關(guān)人員的評審之后，才開始設(shè)計交互層。因此，在產(chǎn)品設(shè)計的四大層面中要多和團(tuán)隊(duì)、用戶等相關(guān)人員交流，而不是閉門造車，車都造出來了發(fā)現(xiàn)有問題要推倒重來，那麻煩可就大了。

局部設(shè)計

局部設(shè)計是指在平常功能性非大版本或者非重構(gòu)的迭代，多以增減修改某個功能/模塊、體驗(yàn)等不觸碰核心業(yè)務(wù)邏輯的迭代為主。下面說明下注意事項(xiàng)。PS：具體還是得看需求和實(shí)際情況，每個公司和產(chǎn)品都不一樣的。

1. 明確修改的層級

明確改動處于業(yè)務(wù)層、系統(tǒng)層、邏輯層、交互層四層中的那一層，層級越高一般涉及到的東西就越多，越是要謹(jǐn)慎小心。

2. 梳理改動相關(guān)的舊邏輯

根據(jù)層級往下羅列與改動相關(guān)的邏輯、功能、交互、組件等，先抽離出與改動相關(guān)的系統(tǒng)，再從系統(tǒng)中抽離出與改動相關(guān)的模塊，再從模塊中抽離出與改動相關(guān)的功能和交互，

必須和技術(shù)負(fù)責(zé)人、架構(gòu)師、后端工程師等成員進(jìn)行溝通，清除技術(shù)層面的問題，并商量解決，有些問題是產(chǎn)品看不到但是技術(shù)看得到的。必須和測試等成員溝通，核對改動的影響內(nèi)容，對用例查漏補(bǔ)缺。必須和設(shè)計師溝通，核對改動的交互和視覺細(xì)節(jié)，明確目標(biāo)用戶和使用場景。

3. 梳理改動相關(guān)的新邏輯

根據(jù)梳理出來的舊邏輯和目標(biāo)用戶的使用場景，根據(jù)新需求逐一填上新邏輯，和完形填空一樣。如果需要在別處新增，就需要從那個模塊的所有邏輯中入手，基于使用場景和用戶路徑等設(shè)計新的邏輯。數(shù)據(jù)、實(shí)體相關(guān)的要考慮舊數(shù)據(jù)如何處理，例如消息多了個已讀未讀狀態(tài)，舊數(shù)據(jù)是默認(rèn)為已讀還是默認(rèn)為未讀。

4. 相關(guān)問題方案和改動在發(fā)版前告知其他部門

?在改動的方案出來之前，要和需求方及相關(guān)人員多溝通；在改動的方案出來之后，要抄送給需求方及相關(guān)人員一份，保證信息同步，共同決策。

在發(fā)版前，把每個部門相關(guān)的文檔，例如需要給客服部門的QA要提前準(zhǔn)備好，并發(fā)送給各個部門的對接人員，提前準(zhǔn)備。

5. 發(fā)版后跟進(jìn)新改動的問題和數(shù)據(jù)反饋

版本發(fā)布后，告知各方并進(jìn)入反饋階段。持續(xù)跟蹤新改動的相關(guān)問題和數(shù)據(jù)反饋，以便明確版本效果，如果發(fā)現(xiàn)邏輯和設(shè)計漏洞要迅速處理，大的漏洞不要出現(xiàn)，否則會造成很大損失。預(yù)先進(jìn)行小規(guī)模的ABtest很有必要。

《產(chǎn)品經(jīng)理如何基于需求迭代產(chǎn)品》系列的四篇文章終于寫完了，本系列更注重的是產(chǎn)品架構(gòu)設(shè)計的內(nèi)容，希望大家能夠有所收獲。

在寫文章的時候，發(fā)現(xiàn)有很多內(nèi)容還可以寫，例如某垂直領(lǐng)域知識、某小模塊的細(xì)節(jié)設(shè)計、通用的方法論等，我也會持續(xù)輸出的，請大家持續(xù)關(guān)注，敬請期待。

相關(guān)閱讀

產(chǎn)品經(jīng)理如何基于需求迭代產(chǎn)品（上篇）：需求調(diào)研的四個步驟

產(chǎn)品經(jīng)理如何基于需求迭代產(chǎn)品（下篇01）：產(chǎn)品設(shè)計的高內(nèi)聚低耦合

產(chǎn)品經(jīng)理如何基于需求迭代產(chǎn)品（下篇2）：產(chǎn)品的整體設(shè)計之業(yè)務(wù)層和系統(tǒng)層

作者：Vency，公眾號 Vency不二或者vencybu2

本文由 @Vency?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。