畫畫的時候，會先想，我要畫一棵樹，然後在圖紙上打底稿，用鉛筆勾畫樹幹、樹枝，等到樹的形狀都勾勒出來了之後，再在上面塗上顏色，用不同的顏色繪製樹幹，樹枝，樹葉和花朵。
而產品設計的過程，正如畫畫的過程，現有一個產品目標，再由目標確定大致的功能內容範圍，進行產品的信息框架的構建，核心使用流程的搭建。在這些工作的基礎之上開始繪製有形的，用戶可使用的交互界面。再最後進行界面的美化，最終完成了產品的整體設計過程。
但是有一個問題一直困擾了我很久:
在產品設計的過程中，如何綜合使用需求規格說明，以及產品原型？
我所在的公司基本都是面向政務的B端項目型公司。
在我轉行做產品人員的第一家公司，領導教會我們的是，在產品目標、用戶目標的識別之後，通過用戶角色，用戶故事來構建應用場景，然後在此基礎之上，進行信息框架設計、業務流程設計，再進行詳細的產品原型界面設計。這個過程跳過了需求規格說明書的編寫過程。真正需要需求說明書的時候，往往是在驗收的時候，爲了應付驗收而編寫的“應付式”文檔。
在我去的另一家公司，則這個公司的有個做了十幾年的開發經理，在和他合作的過程中，他要求我們無論如何都要寫需求說明書，在裏面寫明業務目標，並畫好系統的核心業務流程，定義好各類表單，表格的格式。而至於原型，則可有可無，他更願意通過需求說明書來指導開發來完成任務。
都是爲了讓開發，客戶，公司其他部門的成員能瞭解到需求是怎樣的，以及需求如何落地，轉化爲產品，提供給到用戶進行使用。但是不同的公司配合的模式千差萬別，很多情況下，都是由公司生產部門團隊裏面有話語權的人來掌控這個產品設計的流程。
不知道會不會有人和我有一樣的煩惱，怎樣的產品設計的過程，纔是一個高效，高質量的過程。
我自己也嘗試過在產品的設計過程中同時運用需求說明書與產品設計，補足各自的缺點。
需求說明書優勢：
- 更豐富的文本說明，能闡釋清系統的背景和目標
- 線性地描述，可以更好地表達業務流程，模塊、功能之間的關聯關係
需求說明書的劣勢：
- 不能直觀地體現用戶使用系統的交互過程
- 用戶可讀性差，一般人都很難有耐心把一份需求說明書完整仔細地看完
產品原型的優勢：
- 圖形化界面，受衆視覺感知性更強，能使受衆更快地理解“產品是什麼，做什麼”
2.直觀地體現用戶使用系統的交互過程
產品原型的劣勢：
- 在表達模塊，功能之間的關係，以及表達系統業務流程方面，顯然不夠流暢
- 一般很少在產品原型上花大量的精力描述背景和目標。
但是同步的操作真的很讓人頭疼。兩份文檔在對於產品的定義的內容，有很大一部分，特別是功能點，功能規則的描述，總是有大量的重複，這就造成了，本來想要配合兩者的優勢來提高產品設計的質量，卻導致：
- 一旦發生業務規則，交互規則變化，兩邊的文檔都需要更新
- 開發人員不知道以哪一份文檔爲主，或者總是有一份文檔是沒有實際效用的。
所以，是不是兩者沒有必要在一個項目中同時使用，應該有所區分，在不同的場景下使用不同的方式呢。
有說敏捷迭代的軟件開發模式就用原型；而瀑布流模式就用需求說明書。而也有說法是C端產品偏好用原型，B端產品偏好用需求說明書。
這個問題其實一直都有困擾着我，直到今年，遇到了以傳統軟件工程的設計思想指導做系統需求分析的趙哥，交流了幾次他對需求定義的理解，需求捕獲的理解，以及需求說明書裏面的建模過程的理解等，才受到了啓發，找到了兩個文檔之間的分工和合力。
產品角度的分工：
需求分析的過程產生了需求說明書
用戶體驗設計過程產生了產品原型及視覺界面
技術角度的分工：
需求說明書是系統架構設計，類對象設計，數據庫表設計的前置條件。
原型設計是功能模塊開發，前端頁面開發的前置條件
未完待續...