產品設計中的點線面法則

上一篇文章主要講的是如何從零搭建起一個信息系統的方法，但實際上甚少有產品人員會參與到系統搭建的工作，因為系統架構往往是在產品的初期，大部分的情況下都是已經搭建好的系統再去根據不同的需求增加不同的流程或功能。那麼這個時候再使用UML或SERU的方法就會造成每次都可能對系統架構的重設計，需要重新去梳理一個子系統中整個業務的過程，不利於快速迭代的開發。在這裡我提供另外一種適合快速建模的方法，我稱之為"點線面法則"。

在「點線面法則」中，有四個重要的組成部分，分別是：人物、場景、需求、功能。在業務流程抽象成任務流程中最關鍵的點就是把握好如何將人物，場景，需求轉化成功能。但有很多項目都試圖通過定義功能性需求和非功能性需求來確定需求，這些需求沒有說明一個用戶如何使用系統，也沒有說明一個功能在何種場景下必須運行，這樣的抽象方法無疑到最後是不符合用戶預期的。所以在產品設計中，人物/場景/需求這三者應該是不可分割的組成，這個組合在uml裡面稱之為「user case 用戶案例」，任何只考慮需求或場景的設計都很容易陷入「我認為式」或「老闆式」的設計。「點線面法則」是把交互事件作為節點，用例作為一條線，再根據點與線的關係構成頁面，顯現出從線到點，從線到面的設計原理。

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

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

分清楚線之後我們開始豐富線裡面的交互動作。用例場景是有步驟的（執行了一系列動作）:也就是說，它是一個由一系列業務步驟組成的業務活動。業務活動是屬於線下的真實活動，我們需要把這個業務流轉化成線上的交互動作流。對於一個動作，實際上是沒有具體的劃分的，例如一張表單裡面如果需要填寫兩部分的內容，產品人員認為表單的其中一部分有復用性需要區分，那麼這個流程就可以拆分成兩個填寫的交互動作。只要是屬於交互動作，並且有足夠的理由支持能成為一個節點，那麼這一個流程便是合理且符合實際業務情況的。

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

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

圖3 完整得構建出所有用例的交互流程

點線構成面，這裡所說的面其實是"頁面"。交互動作在系統中最直接的體現就是頁面的反饋，所以頁面的反饋是需要我們去設計的。上一步在確定節點的時候以動作去做一個劃分也是希望在這個階段可以把每個動作變成一次對頁面的交互，通常情況下一個動作(子級動作)一般對應一個頁面的變化，所以在這個階段，我們把每一個節點轉化成頁面。在個時候還不是頁面最終呈現的效果，只是把每次動作的變化轉換成界面的變化，不需要考慮某些動作是在同一個頁面上操作的情況，只需完整地把結果頁面列出來即可。

圖4 把交互動作轉化成頁面的變化

最後我們需要把同類用例線的所有頁面進行一個歸納和分層，確定頁面與頁面之間的層級關係。歸納是把不用用例的同類操作合併，分層是把不同流程的動作區分界面的層級以確定產品的架構層級。這一步的目的是為了在表現層中提取內在業務的聯繫，也是基於所有構成的用例中（業務流轉方式）取出最合適的頁面表現關係。

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

圖6 歸納和整理同層級的頁面，提取核心

圖7 頁面分層，最終效果

總結一下整個過程就是"線-點-線-面"這樣的一個順序，先把用例線進行全面梳理確定範圍，然後再細化每條用例線中的交互動作確定節點，再思考每條用例線之間的交互與聯繫，從而把整體進行頁面化，把流程最終轉化成頁面的關係，最終是一個通過頁面確定整個系統架構的過程。這樣的方法是先把業務流程產生的用例轉化成交互流程，然後以交互流程為依據建立頁面與層級之間的關係，實際上整個過程都是在以業務流程為核心推動著系統架構的設計，是一種自下而上的設計方法。先把底層的所有用戶、場景、需求產生的用例都梳理出來，再經過向上一級的歸納提取把其中核心的業務流程模型建立起來。這樣的方法非常適合做快速的功能設計，能夠在較短的時間內確定交互動作的流程，在這個過程中只注重交互的流程而不是交互的形式。

在功能設計的時候我們總是說要善於歸納總結，但是如果前期沒有想清楚所有的用例那麼後期肯定是要不斷地去填坑，"點線面法則"能很好地幫助產品人員最大程度上規避出現這樣的情況。人物、場景、需求、功能這四者必須貫穿在整個設計思考的過程中，不斷去思考四者之間的關係，所謂萬變不離其宗亦算是這個道理。
推薦閱讀：