產(chǎn)品經(jīng)理如何基于需求迭代產(chǎn)品(下篇3):產(chǎn)品的整體設(shè)計之邏輯層和交互層
產(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)載。
已經(jīng)反復(fù)讀了好多篇,每一次讀,感覺理解的更深入一些。我是個UI設(shè)計師,計劃培養(yǎng)成具備產(chǎn)品思維的UI設(shè)計師。謝謝您的分享?。。。?/p>
對你有幫助就好~~~加油加油! ??