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