一：剖析需求，提出問題

　　在做需求分析的時候，產品經理的一個大忌就是，拿來就做，不問問題。不問問題有兩種可能性：種可能性是需求已經提的很完善了，沒有什麼問題可以提；第二種可能性是需求分析不到位。

　　舉一個例子，曾經有一個業務部門需求是，將原本 T+1 的金融產品贖回到賬體驗改為 T+0 實時到賬。但是該需求並沒有提出具體的實現方式，只提出他們可以先墊一部分錢給投資者。我們在分析這個需求的時候，先要明白，這個需求的要務是，無論如何，投資者應該在贖回的當前就拿到贖回款。

　　衍生出的波待解決問題較為巨集觀：

　　一旦 T+1 變為 T+0，原來的 T+1 產品是否還存在？

　　是重新建立一個 T+0 的產品還是把原來 T+1 的產品改為 T+0？

　　這個 T+0 產品將會是系統中的 T+0 產品還是未來多個同型別產品中的個？

　　這一波問題找到答案後，我們將會對 T+0 贖回這個業務的邊界有大致的瞭解。如果是孤例，那就是一個功能模組級別的任務。如果將來會大規模開展，那我們應該從現在就開始考慮功能的擴充套件性（然而市場總是變化快，開始說只是先做做，後來要大批次上的情況也很多，這主要看產品經理自己的判斷是否準確了）。

　　波問題找到答案後，將會進入第二波問題的提出：

　　這個業務將由哪幾個部門協同合作？

　　誰領導，誰協同？

　　資金從哪個賬戶出款，何時出款？

　　是否有回款，什麼條件觸發回款？

　　這些流程的各個節點，誰推進，誰稽核，誰被通知？

　　這些問題答案就是是能夠完成產品設計的關鍵素材，這個維度的問題應該問到不能再問的原子級別。問題是否問完的檢驗標準就是，產品經理是否自己能夠流暢的口述整個流程的資訊流和資金流的流轉過程，有一處不明白，那一處就會成為實現時的坑。

　　第三波問題也非常重要，這個層次的問題主要在系統層面。例如：

　　由哪幾個系統協同完成這個需求？

　　系統和系統之間是如何互動的？

　　資料一致性如何保證？

　　一旦一個系統掛了，另一個系統如何回滾或容錯？

　　在這一波問題中，可能需要技術同事作為顧問，但問答並不需要太細，因為當前只是處在需求分析，並未上手設計。

　　三波問題，百分之七八十有了答案之後，我們可以寫出一個較粗的需求分析報告，給業務部門進行確認。

　　二：用例先行，框定邊界

　　如果有做後臺的產品經理不知道用例，那是一個很大的遺憾。因為沒有用例，就沒有整個系統。簡而言之，只要能完成預先設定的用例，無論系統實現得多麼差，都起碼是一個合格的系統。

　　如何寫用例在這裡不多講，個人認為知名的參考資料是《大象-thinkinginUML》。寫好用例的意義在於，劃分清楚，在當下需要實現的版本中，哪些需求是需要實現的，哪些不需要。這點很重要，如果不劃分清楚，很有可能出現在需求檔案的撰寫中，不斷加新需求，使版本計劃延期，版本功能變得不可控。

　　三：按角色分模組，按功能分模板，按模板做頁面

　　後臺產品的原型設計，在很多人眼中，似乎不那麼注重互動，就是一堆 “某某管理” 的操作頁面。我們見到的大多數國產後臺產品，例如各種 OA 系統，流程管理後臺，ERP 後臺，資料管理後臺等，大多數做的潦草而匪夷所思。

　　那麼，我們應該如何來做頁面級的功能設計呢？只有一條宗旨，降低學習成本，提高使用效率。

　　假設該產品已經沿用多年，除非有顯著的簡化和易用性新設計，一般不應改變原有互動邏輯，不管您覺得該邏輯有多麼白痴。原因很簡單，這個產品的多使用者很有可能是一些初中都沒畢業的客服中心人員，很有可能是一些很少跟電腦打交道的人，他們並不是我們這樣天天研究各種網際網路產品的人，當我們做好原型之後，應該自己模擬多使用者去試試，到底能不能完成既定工作，而不是沉浸在自己應用了各種所謂高階的互動設計概念的飄飄然中不可自拔。

　　接下來，繼續進入正題。

　　在模組設計時，為什麼會有 “這個管理” 、 “那個管理” 模組，到底是誰在管理，管理的目的是什麼？這個模組的工作之前（前置流程）是什麼？做完這個模組的工作之後（後置流程）是什麼？這些都需要考慮清楚。

　　個人的建議是以一個或一類角色的工作作為一個大型的模組，以該類角色中不同的分工作為子模組來處理。這樣一來，這類角色可以集中處理工作，而不需要在整個系統的不同模組之間跳來跳去的這裡點點，那裡點點，一不小心就忘了操作。

　　這裡也舉個簡單的例子。

　　見過有些產品設計，將某些業務的申請和稽核做在一張頁面裡，我個人是很反對這種設計的。這種設計的個壞處是，這倒逼了技術實現必需將許可權設定到按鈕級，增加了工作量；第二個壞處是，對於操作員和稽核員，無法區別展示不同內容，大家看到的資訊必須是完全一樣的，畢竟您們共享了一張頁面，因此擴充套件性也是差的。

　　再說說按功能分模板。

　　每張頁面都有它自己的功能，沒有一張頁面是什麼功能也沒有的。一般頁面的功能可以粗略的分為：綜合展示頁面（dashboard 類頁面）、表單工單類頁面-即填入一些資料並儲存的頁面、列表類入口頁面-即展示資料表格並帶有一些索引連結的頁面（例如產品列表，投資者列表等）、資料查詢類頁面-即帶有搜尋區和結果區的頁面、詳情主頁類頁面-即展示某個物件全部資料的頁面（例如個人資料、賬戶詳情等）。除此之外，彈窗也有一些模板，在這裡不一一列舉。

　　如果我們能夠預設一些模板，並在頁面設計中儘量複用這些模板，不但可以節省我們的工作時間，也可以讓多使用者的學習成本進一步降低，因為對大多數人來說，觸類旁通比完全從頭開始學習容易得多。

　　當然，這是一個循序漸進的過程，我們自己應該在一次次的產品迭代中，也對我們的頁面模板庫進行迭代，不斷重新整合、分拆，以適應新的業務和進一步最佳化原有業務。

　　當我們完成了以上三步，可以說大部分的產品設計工作已經完成，但是這僅僅是設計階段，這些工作還不能達到可以提交開發的階段。