上一篇文章主要講的是如何從零搭建起一個信息系統(tǒng)的方法，但實(shí)際上甚少有產(chǎn)品人員會參與到系統(tǒng)搭建的工作，因?yàn)橄到y(tǒng)架構(gòu)往往是在產(chǎn)品的初期，大部分的情況下都是已經(jīng)搭建好的系統(tǒng)再去根據(jù)不同的需求增加不同的流程或功能。那么這個時候再使用UML或SERU的方法就會造成每次都可能對系統(tǒng)架構(gòu)的重設(shè)計(jì)，需要重新去梳理一個子系統(tǒng)中整個業(yè)務(wù)的過程，不利于快速迭代的開發(fā)。在這里我提供另外一種適合快速建模的方法，我稱之為"點(diǎn)線面法則"。

在“點(diǎn)線面法則”中，有四個重要的組成部分，分別是：人物、場景、需求、功能。在業(yè)務(wù)流程抽象成任務(wù)流程中最關(guān)鍵的點(diǎn)就是把握好如何將人物，場景，需求轉(zhuǎn)化成功能。但有很多項(xiàng)目都試圖通過定義功能性需求和非功能性需求來確定需求，這些需求沒有說明一個用戶如何使用系統(tǒng)，也沒有說明一個功能在何種場景下必須運(yùn)行，這樣的抽象方法無疑到最后是不符合用戶預(yù)期的。所以在產(chǎn)品設(shè)計(jì)中，人物/場景/需求這三者應(yīng)該是不可分割的組成，這個組合在uml里面稱之為“user case 用戶案例”，任何只考慮需求或場景的設(shè)計(jì)都很容易陷入“我認(rèn)為式”或“老板式”的設(shè)計(jì)。“點(diǎn)線面法則”是把交互事件作為節(jié)點(diǎn)，用例作為一條線，再根據(jù)點(diǎn)與線的關(guān)系構(gòu)成頁面，顯現(xiàn)出從線到點(diǎn)，從線到面的設(shè)計(jì)原理。

實(shí)際操作中第一步讓我們先把線分清楚，每一條線是根據(jù)不同類型的用戶在不同的場景下的一種事件流程組成的，也就是說線是由用例組成的。用例是參與者在系統(tǒng)中執(zhí)行了一系列動作，這些動作將生成特定執(zhí)行者可見的價值結(jié)果。這里值得注意的是兩點(diǎn)，用例是有人物有場景有目標(biāo)的，也就是說它能夠在特定場景下為參與者帶來有意義的結(jié)果，例如"填寫表單信息"顯然對參與者而言是沒有意義的，所以這就不是一個合適的用例。第二個是對角色的劃分，很多人認(rèn)為C端產(chǎn)品沒有太多角色的劃分，其實(shí)以電商為例可以劃分為首次登錄的用戶、老用戶、從外鏈進(jìn)入的用戶等等，不同的用戶不同的場景都是能產(chǎn)生不同的用例的，在梳理的階段分得越細(xì)就越不容易出現(xiàn)遺漏或考慮不周的情況。

圖1 根據(jù)用戶和場景的不同建立不同的用例線

分清楚線之后我們開始豐富線里面的交互動作。用例場景是有步驟的（執(zhí)行了一系列動作）:也就是說，它是一個由一系列業(yè)務(wù)步驟組成的業(yè)務(wù)活動。業(yè)務(wù)活動是屬于線下的真實(shí)活動，我們需要把這個業(yè)務(wù)流轉(zhuǎn)化成線上的交互動作流。對于一個動作，實(shí)際上是沒有具體的劃分的，例如一張表單里面如果需要填寫兩部分的內(nèi)容，產(chǎn)品人員認(rèn)為表單的其中一部分有復(fù)用性需要區(qū)分，那么這個流程就可以拆分成兩個填寫的交互動作。只要是屬于交互動作，并且有足夠的理由支持能成為一個節(jié)點(diǎn)，那么這一個流程便是合理且符合實(shí)際業(yè)務(wù)情況的。

圖2 豐富用例線中每個場景的交互動作

在一個用例里動作也存在與其他用例的動作產(chǎn)生交互的現(xiàn)象，例如某機(jī)構(gòu)有銷售人員與財(cái)務(wù)人員，財(cái)務(wù)人員進(jìn)行記賬時就要獲取銷售的報價然后等待銷售與客戶完成交易，這就是銷售人員的用例與財(cái)務(wù)人員的用例產(chǎn)生交互的情況，所以在存在與別的用例產(chǎn)生交集的地方可以先把這里一系列的動作歸納為一個父級動作，在里面再進(jìn)行一系列子級動作的過程。同樣如果存在一個動作涉及到幾個交互動作也可以把它分為子級與父級的關(guān)系。比如"完成表單"是一個父級動作，新建、填寫、提交這就是屬于"完成表單"的三個子級動作。這里也類似我們在畫素描的時候，如果局部的地方需要畫一個箱子，我們就會把這個箱子的范圍先確定下來，整個局部都畫好了再去細(xì)化這個箱子里面的細(xì)節(jié)，屬于一個局部分總分的思想。最終把所有用例線的交互動作都表示出來就完成了這一環(huán)節(jié)的工作。

圖3 完整得構(gòu)建出所有用例的交互流程

點(diǎn)線構(gòu)成面，這里所說的面其實(shí)是"頁面"。交互動作在系統(tǒng)中最直接的體現(xiàn)就是頁面的反饋，所以頁面的反饋是需要我們?nèi)ピO(shè)計(jì)的。上一步在確定節(jié)點(diǎn)的時候以動作去做一個劃分也是希望在這個階段可以把每個動作變成一次對頁面的交互，通常情況下一個動作(子級動作)一般對應(yīng)一個頁面的變化，所以在這個階段，我們把每一個節(jié)點(diǎn)轉(zhuǎn)化成頁面。在個時候還不是頁面最終呈現(xiàn)的效果，只是把每次動作的變化轉(zhuǎn)換成界面的變化，不需要考慮某些動作是在同一個頁面上操作的情況，只需完整地把結(jié)果頁面列出來即可。

圖4 把交互動作轉(zhuǎn)化成頁面的變化

最后我們需要把同類用例線的所有頁面進(jìn)行一個歸納和分層，確定頁面與頁面之間的層級關(guān)系。歸納是把不用用例的同類操作合并，分層是把不同流程的動作區(qū)分界面的層級以確定產(chǎn)品的架構(gòu)層級。這一步的目的是為了在表現(xiàn)層中提取內(nèi)在業(yè)務(wù)的聯(lián)系，也是基于所有構(gòu)成的用例中（業(yè)務(wù)流轉(zhuǎn)方式）取出最合適的頁面表現(xiàn)關(guān)系。

圖5 把所有用例的頁面變化相連接

圖6 歸納和整理同層級的頁面，提取核心 圖7 頁面分層，最終效果

總結(jié)一下整個過程就是"線-點(diǎn)-線-面"這樣的一個順序，先把用例線進(jìn)行全面梳理確定范圍，然后再細(xì)化每條用例線中的交互動作確定節(jié)點(diǎn)，再思考每條用例線之間的交互與聯(lián)系，從而把整體進(jìn)行頁面化，把流程最終轉(zhuǎn)化成頁面的關(guān)系，最終是一個通過頁面確定整個系統(tǒng)架構(gòu)的過程。這樣的方法是先把業(yè)務(wù)流程產(chǎn)生的用例轉(zhuǎn)化成交互流程，然后以交互流程為依據(jù)建立頁面與層級之間的關(guān)系，實(shí)際上整個過程都是在以業(yè)務(wù)流程為核心推動著系統(tǒng)架構(gòu)的設(shè)計(jì)，是一種自下而上的設(shè)計(jì)方法。先把底層的所有用戶、場景、需求產(chǎn)生的用例都梳理出來，再經(jīng)過向上一級的歸納提取把其中核心的業(yè)務(wù)流程模型建立起來。這樣的方法非常適合做快速的功能設(shè)計(jì)，能夠在較短的時間內(nèi)確定交互動作的流程，在這個過程中只注重交互的流程而不是交互的形式。

在功能設(shè)計(jì)的時候我們總是說要善于歸納總結(jié)，但是如果前期沒有想清楚所有的用例那么后期肯定是要不斷地去填坑，"點(diǎn)線面法則"能很好地幫助產(chǎn)品人員最大程度上規(guī)避出現(xiàn)這樣的情況。人物、場景、需求、功能這四者必須貫穿在整個設(shè)計(jì)思考的過程中，不斷去思考四者之間的關(guān)系，所謂萬變不離其宗亦算是這個道理。

---

justinlam。一個產(chǎn)品，半個設(shè)計(jì)。專注企業(yè)信息系統(tǒng)的研究與總結(jié)，擅長OA、CRM與ERP系統(tǒng)的架構(gòu)與規(guī)劃。愛好業(yè)務(wù)需求分析與互聯(lián)網(wǎng)產(chǎn)品設(shè)計(jì)。（知乎專欄：遇見產(chǎn)品）

本文由PMCAFF專欄作者?@justinlam?原創(chuàng)發(fā)布于PMCAFF產(chǎn)品社區(qū)（www.pmcaff.com），未經(jīng)許可，禁止轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的产品设计中的点线面法则的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。