作為設計師，了解産品經理提供的需求文檔是互動設計工作的重要前提與起點，然而對于很多設計師來說，需求文檔内容通常非常複雜，設計師們需要花費大量時間去消化、了解和歸納。本文作者結合公司示例，分析設計師如何通過需求文檔發現問題，一起來看一下吧。
在産品開發過程中，需求文檔作為産品重要的過程性文檔，是産品經理對産品需求的較長的描述和确認。
作為設計師，了解産品經理提供的需求文檔是互動設計工作的重要前提與起點。然而對于很多設計師來說，需求文檔内容通常非常複雜，設計師們需要花費大量時間去消化、了解和歸納這些内容。
本文将結合本公司實際案例，探讨需求文檔的重要性，分析設計師如何通過需求文檔發現問題，一起來看看吧~
01 産品需求文檔的定義
産品需求文檔PRD是英文“Product Requirement Document”的縮寫，翻譯為中文就是“産品需求文檔”，主要用于完整描述産品需求，向研發部門明确産品的功能和性能以及作為産品文檔歸檔。
它是産品項目由“概念化”階段到“圖紙化”階段的重要文檔。主要面向于開發、測試、項目經理、互動設計師、營運和其他業務人員。
02 産品需求文檔的構成
在産品設計期間，需求文檔的作用特别重要，因為它是我們了解産品所需功能、互動和設計元素的關鍵資源。文檔通常由多部分組成，這些部分通常是由不同的角度出發編寫，接下來我将結合文檔中的不同子產品講解我們可以擷取哪些知識點。下圖是我們公司産品需求文檔的示例。
需要注意的是，每個項目和團隊的需求都是不同的，是以在編寫産品需求文檔時，這些子產品可以根據具體情況進行适當的調整和修改，但即使調整仍需要說明每一個需求的目标、背景、相關方、前端互動等，因為缺少任何一個描述都會導緻需求了解的變形。是以要確定文檔的内容清晰明了，符合業務需求，并能夠幫助設計人員更好地了解産品的需求和規範。
03 産品需求文檔如何閱讀
通過上述産品需求文檔的簡單介紹，我們了解了它涵蓋了産品的所有細節和需求，它是我們互動設計工作的基礎，接下來我們将會深入探讨如何從這些子產品中擷取互動設計資訊。
1. 産品基礎資訊（需求編号資訊、流程上線分階段目标）★★★
這些資訊對我們來說雖然并不直接作用于設計，但了解這些資訊有助于他們更好地了解整個産品和産品開發的流程。
通過産品上線的分階段目标我們可以更好的了解産品釋出的整個流程，進而可以考慮不同階段的需求和目标。例如産品的釋出過程分為多個階段且每個階段的目标都不同，設計師可以根據不同階段的需求和目标進行跟進，以確定産品能夠在每個階段都能夠達到預期的目标。在設計過程中，設計師需要注意需求的優先級和時間表，更好地規劃設計時間。
2. 需求概述（應用目标、使用部門、應用場景描述、功能應用頻度、需求價值）★★★
1）應用目标
應用目标是指産品要解決的問題或達到的目的即該産品成立的理由。通過了解它，我們可以更好地了解産品的定位、産品的主要功能、使用者的需求以及産品的核心競争力。
2）使用部門
該部分主要講的是産品上線後會有哪些部門使用，在此我們通過部門資訊可以了解客戶的業務規模和部門設定，确定産品閱聽人和定位，通過這些部門的業務場景和工作流程知道和實施設計方案，確定産品的設計更加貼近使用者的實際需求。
在這裡如果結合使用者畫像的話效果更好，有關使用者畫像的具體使用可以參考我上一篇文章《深入了解企業使用者：建構高品質的使用者畫像》
3）應用場景描述
我們可以了解到使用者在什麼樣的場景下使用我們産品，應用場景的描述可以幫助我們粗略的把握産品的使用流程，了解使用者需求和痛點，進而設計出更加合理、順暢的互動流程。
4）功能應用頻度
功能應用頻度指的是使用者觸發産品各個功能的優先級和頻率，通過這些資訊我們可以确定每個功能的重要性和優先級。在設計中我們可以根據不同功能的應用頻度來确定該功能頁中資訊的排版位置以及互動方式，確定使用者更加友善的使用産品。
5）需求價值
需求價值與功能應用頻度息息相關，該子產品描述産品需求的重要價值。它有助于我們了解産品不同需求之間的優先級關系，輔助我們了解産品設計的關鍵點和方向明确産品的核心功能與需求。
3. 需求總體說明（資源管理範圍與粒度、流程概述、資料共享、子流程拆解）★★★★★
1）流程概述
流程概述涉及到産品和服務的整體設計，在設計前需要對業務流程有一個全面的了解，知道該産品的順利運作需要依托哪些流程，在設計過程中更容易形成閉環思維。
2）子流程拆解
子流程拆解部分，我們需要根據文檔中的總體目标、流程圖、環節及角色說明、關鍵功能點說明、界面原型、流程說明及表單設計這6個子產品提取相對應的知識點。
首先我們可以通過文檔中總體目标的了解，将其轉化為使用者的需求和期望，以及如何通過設計來滿足使用者的需求和期望。例如在某個産品文檔中，它的總體目标是：
為保障物聯網業務安全運作，防止不合規終端入網後造成業務故障和網絡安全隐患，需要對物聯網終端進行入網檢測。針對已具備部門入網許可證的終端，需求稽核方稽核後即可免測；針對不具備部門入網許可證的終端，需要由需求發起方發起終端入網測試請求，需求稽核方稽核後，由檢測執行方對終端作合規性檢測，需求稽核方對需求和結果予以稽核。
通過對上述總體目标的了解，我們發現這個産品的使用者主要是物聯網終端的供應商和使用者，他們希望能夠通過這個産品實作友善快捷的入網測試和稽核，以保證物聯網業務的正常運作和安全性。在設計使用者界面時，我們應該注重界面的友好性和易用性，采用簡單的操作控件，明确的導航路徑和細緻的提示資訊，使使用者能夠輕松地完成測試請求、檢測任務、稽核申請和查詢結果等操作。
看完業務的總體目标後，我們可以通過通過業務流程圖擷取以下知識點：
- 業務流程和角色：互動設計師可以了解到該産品的業務流程、操作執行者、資料流向等，以確定設計出來的使用者界面可以支援和反映這些流程和角色關系。
- 使用者路徑和操作：通過業務流程圖可以明确使用者的路徑和操作，進而判斷、優化和簡化使用者操作的流程、步驟和界面設計。
- 狀态和輸出：流程圖展示了每個步驟的輸入和輸出、狀态和資料變化等，這些資訊可以幫助互動設計師準确了解使用者操作後的實際結果，為設計合适的輸出、回報和提醒做出決策。
- 異常處理和錯誤回報：在流程圖中，也會包含不正常的流程分支和異常情況的處理，這些資訊可以提供給互動設計師來考慮界面如何設計友好的錯誤提示和回報機制。
環節及角色說明是指業務流程中各個環節的描述和角色的定義，是我們在工作中需要考慮的重要要素。
通過這些環節說明可以了解到需求的來源，意味着哪些使用者群體需要和系統進行互動、需要什麼樣的體驗和功能，有哪些特殊需求等。我們還可以了解每個角色在每個環節中要執行的功能和任務，在設計過程中根據不同的任務來合理安排每個界面元素的位置和互動方式，使得使用者能夠高效地完成任務。例如通過該角色在流程中需要進行的操作可以預測使用者日常工作中的痛點以及需要解決的需求。
關鍵功能點說明是指業務流程中的重點功能，是互動設計師在設計中需要考慮的一個重要環節。例如在該産品設計中，它的關鍵功能點為：
派單和重派，即在物聯網一體化支撐系統上派發工單；重派後的業務資訊更新曆史業務資訊，但曆史資訊仍要保留，可在處理記錄中檢視。
通過上述節點的了解，我們可以發現此次派發界面需要設計一個直覺清晰的界面，讓使用者可以快速、準确地輸入工單資訊，并進行派單操作。同時需要考慮到不同類型的工單，提供不同的下拉選項供使用者選擇。在重派階段考慮到工單在處理過程中可能會出現問題，需要提供重派功能。在重派後需要更新業務資訊，同時保留曆史資訊，使用者可以在處理記錄中檢視曆史資訊。
而在派單以及重派過程中我們還需要實時提示使用者工單的狀态資訊，以便使用者及時了解工單的處理情況。可以通過不同的顔色或圖示來區分不同的工單狀态，讓使用者一目了然。最後為了更好地了解使用者對工單派發和重派操作的滿意度，可以考慮設計使用者回報機制。在操作完成後，可以彈出一個視窗或跳轉到回報頁面，讓使用者對操作體驗進行評價，并及時回報問題和意見。
很多同學會有疑惑，為什麼不直接對着原型圖進行設計，看産品需求文檔其他子產品的資訊有什麼意義？
雖然雖然界面原型是互動設計的重要組成部分，但它僅僅是需求文檔中的一小部分。通讀産品需求文檔其他子產品的内容有助于互動設計師深入了解業務流程、使用者需求、接口需求、非功能需求等方面的細節，為互動設計提供更豐富的背景知識和上下文資訊，有助于我們更好地了解設計的目标和意義，進而設計出更加符合實際需求和使用者體驗的産品。
通過了解界面原型，我們可以獲得很多關鍵資訊，例如界面元素的類型、位置、布局、互動方式等等，這些資訊都是在深入了解需求文檔的基礎上才能得到的。此外我們還可以根據界面原型分析産品的使用者界面流程，了解使用者在使用産品過程中的操作路徑、可能出現的問題等等，這些都有助于互動設計師在設計中更好地滿足使用者需求和提高使用者體驗。
關于如何閱讀界面原型這裡就不再贅述。
4. 使用者需求★★★★
我們在閱讀完産品需求文檔的總體說明後，建議還要仔細閱讀使用者需求子產品。因為使用者需求子產品可以更加詳細地描述使用者的使用場景、需求和期望，這對于互動設計師來說是非常重要的參考材料。此外有時産品經理在需求總體說明中并沒有詳細說明使用者需求的細節，這時需要通過閱讀使用者需求子產品來擷取更多資訊，甚至可以補充産品經理在需求整理時的不足。
例如，産品需求文檔中在子業務流程中工單清單界面的功能需求如下：
- 待辦工單清單呈現字段及順序：序号、工單類别、工單标題、工單編号、目前環節、工單生成時間、工單到達時間；
- 單擊工單主題，呈現出工單詳情頁面；（具體呈現字段見各表單設計，界面效果參考GUI）
- 工單主題、工單編号等重要資訊要全部顯示；
- 待辦清單按工單到達時間、工單申請時間升序排序；
産品需求文檔中有關使用者需求中對于工單操作要求如下：
工單每一步操作、派轉，系統都應做記錄留痕的目的是：工單未歸檔時，相關上司可以看到工單處理進展，便于過程管控；工單歸檔時，可以看到整個工單處理的過程和曆時，便于事後分析。
結合上述文檔，我們在設計時需要考慮如何清晰明了地展示工單處理進展，以及如何友善使用者快速地擷取所需資訊。當工單狀态發生變化時，工單在處理過程中的狀态可能有待處理、進行中、處理完成等。設計時需要考慮如何讓使用者清晰地了解目前工單的狀态，以及如何友善使用者進行工單狀态的變更。因為涉及到相關上司檢視工單進展，我們還需要跟産品商量是否需要添權重限的配置設定，權限的管理等功能。設計時需要考慮如何友善産品管理者設定相關上司的權限，以及如何讓相關上司友善地檢視工單處理進展。
現在是不是可以發現通過閱讀産品需求文檔中的使用者需求子產品，可以幫助我們更加深入地了解使用者需求和期望，進而設計出更加符合使用者期望的互動方案。
5. 接口需求★★★
到這裡很多同學可能會覺得産品需求文檔到該子產品不需要我花心思閱讀了，其實不是這樣的。雖然在我們的設計過程中并不需要直接編寫接口代碼，但是我們需要了解産品需求文檔中的接口需求，并與後端開發人員緊密合作，確定我們的設計方案和互動流程能夠與背景資料傳輸保持一緻。
為什麼這麼說？
例如我們可以通過接口文檔擷取目前表格所需的資料格式、資料類型、資料的命名規範、資料的長度限制等等。這些資訊可以幫助我們了解需要向後端發送什麼類型的資料，進而能夠設計出符合後端要求的互動元件。再比如，接口文檔中可能列出了某個資料字段的長度限制為20個字元，我們就可以據此設計一個文本框元件，限制使用者輸入不超過20個字元。
下圖為騰訊某産品的接口文檔，我們可以清晰地看到不同資料的要求。
04 寫在最後
産品需求文檔的了解是互動設計師的一項重要工作，我們需要在閱讀時深入了解産品架構、梳理關鍵資訊。隻有通過深度解讀需求，才能更準确地把握使用者需求，并提升産品的使用者體驗和互動效果。
以上隻是我對閱讀産品需求文檔的粗略總結，希望該文章對你有所啟發，也歡迎感興趣的同學一起探讨~
今年的Flag就是要輸出互動設計系列課程，也期待大家對我的關注與監督。
咱們下期見~
專欄作家
江鳥，微信公衆号：江鳥的設計生活，人人都是産品經理專欄作家。8年網際網路行業經驗，擅長體驗設計思維、設計方法論、互動設計研究。
本文原創釋出于人人都是産品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協定
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。