生成需求，產(chǎn)品經(jīng)理可以繼續(xù)寫入需求文件。由于設計師參加了以前的需求分析工作，此時， 對產(chǎn)品情況有一定的了解， 用戶情況和設計方向。需求文件是設計人員，更像是關于彼此的產(chǎn)品功能列表，幫助提醒設計師接下來做什么。

　　這就像準備宴會，您需要為庫克提供詳細的食譜。但，設計師不像廚師。每次他面臨新內(nèi)容。所以不僅需要食譜，它還需要清楚地寫作每個菜是什么。inpt是什么，還有很多。當然， 前提是雙方都經(jīng)過非常詳細地傳達。每個人都了解彼此的想法和期望。

　　需求文件不僅適用于設計師，面臨團隊的開發(fā)和測試人員，這是項目成員參考的重要依據(jù)。

　　●需求文件中應包含什么？

　　需求文件需要什么？這不能概括，應根據(jù)具體項目情況酌情考慮。選擇最適合當前情況的文檔格式。在正常情況下，幫助文檔應包括產(chǎn)品定位， 需求內(nèi)容， 優(yōu)先事項， 等等。 之前提到，并詳細描述需求。以下是標準需求文件的內(nèi)容的示例。

　　文檔修改和審計記錄：需求文件如果有修改，需要一個簡短的記錄，如圖5-9所示。

　　目錄：最好提供作為內(nèi)容的目錄。

　　[專業(yè)建筑站]

　　背景描述：為什么這款產(chǎn)品/模塊， 市場市場， 業(yè)務目標， 產(chǎn)品定位， 等等。

　　用戶類型和功能：簡單描述目標用戶狀態(tài)或現(xiàn)有用戶。

　　項目計劃：什么時候開始，什么時候完成。

　　信息結(jié)構(gòu)：在這里，您可以輕松理解內(nèi)容或頁面的級別，如圖5-10所示。可以由設計者和產(chǎn)品經(jīng)理完成，也可以由產(chǎn)品管理器獨立完成。設計師參考。

　　整體業(yè)務流程描述：適用于涉及更多操作的產(chǎn)品/功能，需要業(yè)務流程圖，幫助設計師和[網(wǎng)站施工價格列表]項目成員了解特定的業(yè)務邏輯。例如， 廣告系統(tǒng)，當廣告被占用時，用戶是否接受相關位置; 如果不被接受，如何處理賬戶金額，還有很多，如圖5-11所示。

　　詳細描述：每個要求的詳細說明。將有一些解釋，例如文檔。如圖5-12所示。

　　●隨后的需求文件迭代

　　如同設計， 有必要不斷修改它。需求文件需要不變

　　闖入蝴蝶 - 用戶體驗設計師的增長路徑

　　正確的， 迭代。

　　首先， 我們必須意識到那個人的文件不能達到一次。沒有人可以保證所有問題都會很清楚。一般來說，完成要求文件后，需要審查。主要看看是否存在明顯的漏洞， 不合理的地方，技術是否有任何困難？你可以按計劃完成嗎？審查后，根據(jù)每個人的意見，產(chǎn)品管理器將重新修改3次文檔迭代。

　　此外，在需求階段有一些更詳細的事情并不容易考慮。對特定設計階段將有更多的深入思考。但有些產(chǎn)品經(jīng)理已理解每個人，一些UI原理圖將添加到需求文檔中。設計師可以用它們作為參考，但不要受到影響太多。

　　到底， 有必要注意。設計師不應嚴格按照需求文件設計。產(chǎn)品經(jīng)理認為角度和設計師不能完全相同，更多的需求文件更加反映在業(yè)務中， 產(chǎn)品要求， 職能， 等等。和設計師需要走更多[網(wǎng)站建設在哪里]考慮目標用戶的特征， 使用場景， 痛點， 等等。這些信知名營銷型網(wǎng)站建設首選息已集成，這是設計的主要基礎。如果設計師參與以前的產(chǎn)品定位， 需求采集和分析過程，它將意識到用戶的情況。

　　所以，網(wǎng)站施工專業(yè)人員的互動設計師的設計結(jié)果通常提供低于需求文件提供的內(nèi)容。如信息結(jié)構(gòu)， 任務流程， 內(nèi)容， 界面形式， 等等。只是與有效的溝通溝通。產(chǎn)品經(jīng)理通常是可接受的。這相當于交互設計階段中的文檔的迭代。產(chǎn)品經(jīng)理可以在設計完成后糾正需求文件。還可以讓設計師對原型上的相應修改進行評論。這條路， 開發(fā)人員只能看到原稿。