這就好像在準備宴席前，你需要提供給廚子一份詳細的菜譜。不過，設計師不像廚子，他每次面對的都是全新的內容，所以不僅需要提供菜譜，還需要寫清楚每個菜都是什么，需要什么配料，等等。當然前提是雙方之前已經經過非常詳細的溝通，彼此都明白對方的想法和期望。
需求文檔不僅面向設計師，也面向團隊中的開發和測試人員，是項項目成員參考的重要依據。
● 需求文檔應該包含什么內容?
需求文檔到底要寫什么內容，這個不可一概而論，應該根據具體的項目情況酌情考慮，選擇最適合當前情況的文檔格式。在常規情況下，幫求文檔應該包含前面提到的產品定位、需求內容、需求優先級等，以及關于需求的詳細描述說明。下面是關于標準需求文檔的內容示例。
文檔修改與審核記錄:需求文檔如有修改，需要簡要記錄，如圖5-9所示。
目錄：如內容過多最好提供目錄。
背景描述: 為什么要做這個產品/模塊、市場行情、業務目標、產品定位等。
用戶類型和特征: 簡單的描述目標用戶情況或現有使用人群的情況。
項目時間安排: 何時啟動，何時完成等。
信息結構: 這里可簡單理解為內容或頁面的層級，如圖5-10所示?？梢杂稍O計師和產品經理配合完成，也可由產品經理獨立完成，設計師做參考用。
整體業務流程說明: 對于涉及操作較多的產品/功能，需要業務流程圖，幫助設計師和項目成員理解具體的業務邏輯。比如一個廣告投放系統，當廣告排期被占用時，用戶是否可接受相關位置；如不接受，系統如何處理賬戶金額，等等，如圖5-11所示。
需求詳細說明: 每一條需求的詳細說明。一個文檔里會有若干條這樣的說明，如圖5-12所示。
● 需求文檔的后續迭代
如同設計稿需要不斷修改一樣，需求文檔也需要不斷的
破繭成蝶-用戶體驗設計師的成長之路
修正、迭代。
首先要認識到，需求文檔不可能一次到位。誰也不能保證一次把所有的問題想清楚。一般來說，在完成需求文檔后，需要進行需求評審。評審時主要看需求有沒有明顯的漏洞、不合理的地方，在技術上有沒有實現難度，能不能按期完成等。評審過后，產品經理會根據大家的意見重新修改文檔迭代3次以上是很正常的現象
另外，有一些較細節的東西在需求階段不容易考慮清楚，要到具體的設計階段才會有更深入的思考。但一些產品經理為了方便大家理解，會在需求文檔中增加一些UI示意圖。設計師可把它們作為參考，但不要過多地受其影響 。
最后一點要注意的是，設計師不要嚴格按照需求文檔來做設計。產品經理的考慮角度和設計師不可能完全一樣，需求文檔更多的是體現業務、產品要求、功能等內容，而設計師還需要更多地去考慮目標用戶的特征、使用場景、痛點等。這些信息綜合起來，才是設計的主要依據。如果設計師參與了之前的產品定位、需求采集與分析過程，就會對用戶的情況比較了解
因此，深圳網站建設專業的交互設計師產出的設計結果一般都會和需求文檔提供的內容不太一樣，如信息結構、任務流程、內容、界面形式等。只要經過有效的溝通，產品經理一般都是可以接受的。這相當于是在交互設計階段對文檔進行了迭代。產品經理可以在設計完成后再修正需求文檔，也可以讓設計師把相應的修改部分注釋在原型稿上，這樣開發人員只看原型稿就可以了。
本文地址：http://murenxiang.com.cn//article/2742.html
