本文由作者 嘮呵?于社區發布

前段時間，由于項目的開發周期卡得非常緊，在極端的高壓下，我一個多月內連續設計了三款B端產品，累積寫了好幾萬字的需求文檔，畫了數百個頁面，每個B端產品都涉及多方角色和系統的交互，業務邏輯非常復雜，回顧那段時間過的，真是生不如死，差點就憋出抑郁癥。

但是好在我熬過來了，苦盡甜來，也算是學到很多的東西。

以前做產品的時候，沒有那么嚴格的上線時間點，有充裕的時間思考，哪怕有很多思考得不周全的地方，也可以花很長的時間去彌補，所以問題都被悄無聲息地掩蓋了，但是，經過前段時間高強度的壓迫輸出，需要在極短的時間內做出高質量的方案，問題便展露無疑。

比如，

明明老早就已經想好的功能，后面寫需求的時候卻忘記了，直到測試的時候才想起來。需求都已經寫好了，正打算好好休息，跟朋友happy一下，卻突然想到還有一些異常流程沒有考慮到，導致前面已經梳理好的所有流程和頁面都需要重新改動，那一刻我的心是崩潰的。需求評審時，程序員直接指出了一堆異常場景，而這些場景此前自己完全沒考慮到，頓時一陣語塞，好不尷尬。有些功能想得太粗，只是簡單帶過，導致開發還需要來主動問具體的實現邏輯是什么，產品經理的專業性受到了嚴重的質疑。

之所以會出現上面出現的各種窘境，最主要的原因還是在于自己寫需求的方式不對，都是想到啥寫啥，沒有遵循一定的流程和步驟。

寫需求過于隨意，則容易過早地陷入細節中，沒有做好頂層設計，后面自然會漏洞百出，在開發面前百般出糗，長此以往，一定會讓研發同事或者其他團隊成員認為你不專業，后續推進必然會存在障礙。

于是，我花了很大一部分時間對此前做的項目進行全面的總結回顧，也找了很多書和文章來看，總算形成了一種行之有效的需求寫作方法論，以這套方法論寫需求會感覺非常順，指哪打哪，不會像以前一樣寫著寫著突然感嘆自己從哪里來，到底往哪里去的迷茫感。

我打算把這套需求寫作方法共享出來，如果大家有遇到跟我一樣的問題，希望這個方法能幫助到你們。

為了讓這套方法更容易被吸收，我以一個簡單的點餐小產品作為案例在全文中穿插著進行講解。

01

系統用例圖

系統用例圖是指由參與者，用例以及它們之間的關系構成的用于描述系統功能的視圖。

它是我們寫需求的第一步，是根據業務用例圖分析得到的，針對于業務用例圖的用戶行為分析后，從系統側去建立對應的模塊。

業務用例圖在這里就不細說了，它是我們在調研用戶需求的階段輸出的產物，展現形式跟系統用例圖基本一樣，不同之處只是在于它更注重用戶的需求是什么，是從使用場景去考慮的，而系統用例圖也更加注重需求對應的系統功能是什么，用戶能通過這個系統做些什么。

系統用例圖是產品最頂層的設計，它構畫出了產品整體的架構，后續所有的流程和頁面設計都需要圍繞它進行展開，所以應該非常地重視它。

它的目的簡單來說就是這么兩點:

1.系統有哪些用戶角色

2.每類用戶角色能使用這個系統做些什么

你可以把系統用例圖理解成我們熟知的功能清單，它相當于形象化地展示出每種角色享有哪些功能，并將功能與角色一一對應起來。

比如我們要講解的點餐小產品，它有兩類角色:

1.顧客

2.廚師

顧客可以用產品做什么？他可以用來點餐，以及查看已點餐品的狀態。

而廚師可以做什么？他可以查看顧客已點的餐品以及餐品的桌號，還可以操作餐品的狀態，操作餐品的狀態又可以往下細分，包括開始做餐，餐品售罄，餐品出餐。

那么，我們的系統用例圖大概可以畫成這樣:

用例的層級需要分清楚，比如顧客需先查看已點的餐品，才可以往下查看餐品的狀態，廚師需要先查看已點的餐品，才可以往下繼續查看餐品的桌號以及查看餐品的狀態，不同的用例是有先后順序的，這一點需要注意。

在這一步，相當于把整個小產品的骨架給搭建起來了，這一步一定要考慮得非常周全，當然，細小的骨頭暫時可以缺失，后面在畫細節的時候能發現并彌補回來就可以了，不會影響大局，但是千萬不能缺了撐起整個骨架的關鍵骨頭，不然后面的流程圖也會跟著缺失，流程圖一旦出問題，則導致整個產品都會接連出問題，后面改起來一定會非常痛苦，這一點我可深有體會。

當然，很多時候用例圖和流程圖的思考順序是相互交叉的，沒有絕對的先后順序，因為你在思考用例圖的時候其實就已經把流程熟稔于心了，如果腦里沒有流程，你也無法把用例圖很全面地畫出來，而畫流程的時候，又經常會回過頭來補充之前用例圖沒有考慮到的部分，所以，寫需求的過程，不是線性的，而是折線型的，需要來回地進行修補。

02

普通流程圖

普通流程圖是我們最常見的流程圖，每個人在工作中或多或少都會接觸一點，這里的“普通”主要是為了區別于后面要講的跨角色或系統流程圖來說的，它讓你更側重于業務的流程與步驟，而不要分散精力去關注哪一步是誰做的(這一點是跨角色或系統流程圖最為關注的)

比如點餐小產品，它的業務流程是這樣的:

1.顧客點餐

2.廚師看到餐品

3.廚師將餐品狀態改為開始做餐

4.廚師開始做餐

5.廚師將餐品狀態改為餐品出餐，然后把餐品貼上桌號

6.送菜員拿餐

7.送餐品上桌

流程圖可以這么畫:

? ? ? ? ? ? ? ? ? ? ? ? ??

流程圖中，雖然不同的步驟是由不同的角色做的，但是并沒有明確地在圖中標注出來，只是文字一筆帶過，這一步不需要關注到具體的角色，只需要關注業務流程，從大體上去描述業務是如何運轉的，如果過早地陷入細節中，反而會讓你考慮得不夠周全，導致漏掉一些關鍵的節點，也會讓開發人員看得云里霧里，無法清晰地看出業務的全貌。

由于我舉的例子只是一個小產品，所以流程比較簡單，如果你設計的是一個復雜的產品，那么，流程的鏈條則會長很多，而且可能需要畫多個流程，包括主流程和子流程，最好把流程的層級關系也標記出來，這樣才便于自己或者開發更加理解業務的邏輯。

03

跨角色或系統流程圖

跨角色或系統流程圖，主要是梳理清楚角色或系統各自的分工和模塊相互之間的串聯，它是我們畫完普通流程圖之后第一步要做的事情，相當于是對普通流程圖的進一步地解釋。

很多做C端產品的朋友很少接觸到這種流程圖，因為簡單的業務邏輯其實只要普通流程圖就足以描述清楚，不需要特意區分角色就能看得明白，但是一旦涉及到N多角色多系統之間的交互，如果沒有用合適的圖形語言來思考和表達，則很容易導致邏輯混亂，不但自己拎不清，則會讓看的人摸不著頭腦。

對于跨角色的流程，我們一般用泳道圖來表現，就拿上面的點餐流程來說，可以畫成這樣:

上面表現的主要是不同角色之間的交互流程，它更注重的是不同角色之間交互的邏輯，而對于那些比較復雜的產品，還可能涉及到不同系統之間的交互，我們需要關注它們在哪些地方需要產生交互，交互的數據是什么，這個直接影響開發人員對接口的設計。

比如互聯網金融產品的授信流程，我們需要體現出我方產品是如何與第三方征信機構進行交互的:

用戶提交的信息會通過接口傳到第三方的征信機構，第三方的征信機構返回征信的結果。

這種圖叫做時序圖，通過描述對象之間發送消息的時間順序顯示多個對象之間的動態協作。它可以表示用例的行為順序，當執行一個用例行為時，其中的每條消息對應一個類操作或狀態機中引起轉換的觸發事件。

簡單來說，就是展示不同系統之間哪些地方需要對話，是如何對話的，對話的順序是什么。

跨角色或部門流程圖展示不同角色或部門之間的交互邏輯，時序圖展示不同系統之間的數據傳遞，根據產品形態的不同，我們可以互相搭配著用。

04

異常流程圖

上面所涉及到的流程，考慮的是作為一個用戶最主流的場景，通常不會涵蓋其他異常的場景。

比如，一個用戶在登陸時，一般來說都會輸入正確的手機號，輸入正確的圖形驗證碼，獲取短信驗證碼，然后輸入并登錄，這是一個最主流的場景，而對于一個產品設計者考慮的則不僅僅是這些，還需要考慮到一些非主流的場景，比如驗證碼輸錯，手機號格式不對，沒有輸入圖形驗證碼等各種情況。

比如上面的點餐流程，主流的場景就是，用戶點餐，廚師看到餐品，開始做餐，出餐，然后服務員拿餐，最后送餐上桌，但是，異常場景也有可能會出現，用戶點餐的時候，這個菜品沒有了，或者用戶點餐后，廚師在做菜過程中發現原材料不足了等等。

當然，我所講的異常流程圖跟異常場景還不是一回事，異常流程圖更加關注的是足以形成流程的場景，比如像上面所說的登錄的這種，一般不需要動用到流程圖去解決，只需要后續在寫需求文檔的時候，在具體的頁面原型上把邏輯說清楚就行。

那什么才是異常流程呢，通常指的是邏輯比較復雜，需要動用到流程圖表現出來的異常場景。

就拿現在很火的視頻會議來舉例。

比如，某視頻會議產品有兩種付費模式，購買會議次數或者購買包月或包年服務，某用戶此前已經購買了2次會議，但是他又不小心去點了購買包月服務，那么，此時系統則需判斷該用戶是否已經購買過包月或包年服務，即判斷他的會議有效期是否已經結束，如果還未結束，則需提示他無需重復購買，如果已經結束，系統還得繼續判斷他是否還剩沒有用完的會議，如果有，需提示他用完才可以繼續購買。

?

這種異常場景相對于上面所提到的登陸會復雜許多，通常需要用流程圖表現出來，才不容易出現差錯。

我們作為產品設計者，一定不要想當然地覺得用戶不會這么去操作就不考慮它，而是需要把所有可能會出現的場景都要考慮到，把體驗做到最好，減少用戶的損失。

05

頁面流程圖

上面的流程都想清楚之后，接下來就要進入到具體頁面的設計了。

但是，現在還不是畫原型圖的時候，一定不要一開始就陷入到頁面具體的元素中去，比如頁面有哪些字段，有哪些按鈕等等，而是應該從整體上去考慮。

比如點餐小產品，它的頁面流程圖可以這么畫:

當然，這里還沒有把所有的頁面都列舉出來，只是展示了個大概，方便大家理解即可。

在這一步，我們思考的是，產品總的有多少個頁面，頁面之間的關系是怎么樣的，它們是如何進行交互的，這樣我們可以從高處俯瞰整個產品的頁面架構以及頁面之間的關聯關系。

這個過程跟我們寫文章很類似，要先列好大綱，然后再針對具體某個論點展開論述，頁面架構其實就相當于文章的大綱，后面原型的設計則相當于論點的詳述，只有通過這種從宏觀到微觀，從抽象到具象的思考方法，才能緊跟產品的脈絡，不至于迷失方向，出現遺漏或差錯。

06

原型圖和需求文檔

當把上面的所有流程圖畫完后，接下來就是我們最熟悉的一步了:畫原型和寫文檔。

所謂畫原型，無非就是把頁面流程圖中所涉及到的每一個頁面，以及每個頁面里所有的元素，包括字段，按鈕，菜單等等，全部都畫出來而已。

而需求文檔簡單來說就是看圖寫字，把上面所畫的流程圖和原型圖一一進行文字說明，把自己腦里面的圖形思考付諸于文字，讓別人看得更加明白。

文檔中需要把流程圖的邏輯，以及每一個頁面上的元素，操作和跳轉邏輯講清楚，文檔的架構可以是這個樣子:

說到頁面上的操作和跳轉邏輯，除了一些頁面級的特別細微的點，大部分在上方的幾個流程圖中都已經說清楚了，在這里只要把邏輯對到頁面上的某個具體的元素上就可以了。

比如在異常流程圖中所提到的，如果這個人已經購買了會議次數，那么他在購買包月服務的時候就應該提醒他已經購買過了，而在原型圖中，就要讓開發知道，這個判斷是出現在哪個頁面的元素上。

比如，它是用戶在付費頁面上點擊付費按鈕的時候進行判斷？判斷后會出現提示嗎？提示是彈框還是只需要旁邊出現文字說明？這都需要一一說清楚。

07

用戶權限表

在文檔的結尾或者文檔的開頭，還需要附上各角色的權限說明，包括功能權限和數據權限。

功能權限：

數據權限：

總結

到這里，一整套寫需求的方法就講完了，這些都是我在做產品的過程中踩了無數的坑之后總結出來的，我自己感覺非常有用，當然，這套方法不一定適合所有人，它也不是一成不變的，我們可以把它看做一款產品，需要不斷地對它進行迭代優化，最終沉淀出最適合自己，最行之有效的方法論。

作者：嘮呵，就職于某大廠的B端產品經理，喜歡跟各類喜歡深度思考的人交流，歡迎勾搭探討，微信nxn123_

↘好文推薦：

王慧文清華產品課

產品經理跳槽面試大揭秘……

作為產品經理，你目前薪資多少呢？

點個“在看”吧

總結

以上是生活随笔為你收集整理的血泪总结！5000字产品需求写作方法论的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。