PRD 文件指的是產品需求文件（Product Requirements Document）。無論是 PM（產品經理／專案經理） 或是 UX designer（使用者體驗設計師），在開發一個數位產品，例如規劃 App, Website 的介面設計時會設計 Wireframe，PRD 文件就扮演了非常重要的角色，他能補足我們在 Wireframe 無法單純用設計畫面就呈現完整的細節資訊與規則，寫得越詳細，最後與 UI 設計師、工程師再交棒後做出來的成果，也才不會離你的想像有過大的差異！
PRD 是什麼？
UXUI 與 PM 的必備技能：撰寫 PRD 產品需求文件
以 UX Designer 使用者體驗設計師的工作內容舉例，Wireframe 會是花費大量時間執行的設計部分，如果想更了解可以看【Wireframe 是什麼？從目的、對象、流程抓住UXUI的設計精髓】，同時在設計完，之後我們會 Wireframe 旁邊，清楚的撰寫完整的 PRD 產品需求文件，規則越細，最後前端與後端開發的成果也就能越貼近我們設計期待。這篇我主要會介紹 PRD 文件的目的和意義，以及 10 個我在規劃 Wireframe 時會經常寫到的 PRD 規則。
UXUI 在設計 Wireframe 時，PRD 文件的目的和意義
- 確定需求：PRD 文件很大的目的就是確定產品的需求。我們在工作上，除了要非常精準的依據使用者輪廓、使用情境來設計 Wireframe，更需要透過詳細描述產品的功能和特性，幫助確定了 Wireframe 上無法用畫面就全部描述完整的設計規則，同時也可以幫助前後端工程師與團隊成員可以清楚了解我的設計目標與想法，因此在開發時可以在共同的背景下，設計目標才不會跑偏，同時 PM 與 UX 或前後端工程師意見相左的規則時，也能在執行前先進行討論。
- 溝通與合作：PRD 可以幫助各個團隊之間溝通和合作。它可以確保開發團隊、設計團隊、產品管理團隊和客戶等對產品的期望保持一致，減少認知落差所造成的可怕結果。
- 測試與驗證：同時 PRD 也可以作為測試和驗證產品的參考文件，並來撰寫測試腳本給測試人員做後期產品內部驗證。
- 追蹤進度：雖然多數我會是標注在 Wireframe 旁邊，所以本身不會具備進度追蹤功能，但有時會在共編的 Google Sheet 寫規則，以及 PM 多數時間會在 Google Sheet 上寫的 PRD，以利管理專案時可以與大家同步並可視化當前進度，可以透過角色畫分與完成狀態，追蹤產品開發進度的工具。
10 大 PRD 規則與範例，讓UX 的 Wireframe 更精準！
規則1 : PRD 欄位規則
針對個別欄位，例如像是下拉選單、輸入框、上傳欄位等，將其規則寫出來，有些是本身會給使用者看到的規則，例如密碼需要符合 8 碼並且有英文大小寫，亦或是上傳檔案得格式與限制，而有些規則無需特別寫在畫面上，則需要額外在旁邊做文件的說明。
👉🏽 PRD 範例：輸入電話的欄位，不能輸入到全形符號；如有國碼的電話輸入框，可以限定為 9 開頭或是 09 開頭亦可。
👉🏽 PRD 範例：如果有 OTP 的手機簡訊驗證，也就是常見簡訊或信箱形式的一次性密碼，可以寫上倒數計時五分鐘的機制，並且在過了 30 秒後，讓重新寄送的按鈕出現，並且會有一日的寄送上限次數，例如五次。
規則 2 : PRD錯誤判斷
有非常多的情況會跳出錯誤判斷，同時錯誤判斷也可以分為幾個類型，例如 Popup、特定欄位的提示、全頁的提示、Toast，會依據不同的情境跳出適合的提示方式，而欄位有了規則，就會有相對應不符合規則的情況下，會有的錯誤判斷，需要把所有的可能性都一併盤點。
👉🏽 PRD 範例：在填完送出後，有必填欄位未填寫，則在特定欄位跳出錯誤提示：「⚠️ 必填欄位，請檢查並繼續」。並在送出的按鈕附近跳出全頁提示：「⚠️ 尚有必填欄位未完成」
👉🏽 PRD 範例：密碼設定時，不小心輸入到注音符號，或是全形符號，則跳出此錯誤提示：「⚠️ 格式錯誤，請檢查並繼續」。
規則 3 : PRD 成功提示
有錯誤提示，當然就會有成功提示，目的是在做完這項事情後，若有些頁面本身不會有跳轉，或沒有明顯的差異時，需要透過簡單的Toast，讓使用者可以清楚知道自己做的事情有成功完成，才不會一直反覆點擊按鈕，或是又在操作同樣一遍的事情來消除自己是否成功的疑慮。
👉🏽 PRD 範例：申請表單填寫完成後，點擊送出，會轉跳到指定頁面之外，亦會跳 Toast 提示：「已送出」，像是 Gmail 在送出信件後，會返回信件列表並跳出「Sent」的 Taost，因此即便不會跳到你寄送的備份列表，也能清楚知道剛剛那封信已寄出，現在可以繼續往後處理其他封信。
規則 4 : PRD 狀態提示與內容
該資訊如有不同狀態，須清楚標示規則與預期呈現結果，確保使用者清楚知道當前狀態，狀態包含在主動送出的動作後會改變的狀態，或是基於時間、電量、正負值、或是處理的節點改變等，這些都會有不同狀態下，會有的個別呈現內容。
👉🏽 PRD 範例：如果在電量上需要做出提示充電的提醒，可以依據你的設計規劃，來決定在哪個區間需要做什麼顏色的狀態提示。例如在 1% – 20% 時以警示色，21% – 50% 為提示色等
👉🏽 PRD 範例：如果是在購物流程中，會遇到你點擊送出訂單，對方在處理訂單，以及最後收貨的狀態節點，每一間的節點設計都會不同，而宅配或是超取的節點設計也會有所不同，會依據各間電商的流程來做規劃，會有像是「確認訂單」、「處理中」、「已出貨」、「已送達」、「完成訂單」、同時也會有退貨的流程會有的狀態等等。在每一個狀態下，每一間電商會呈現的資訊、以及可以執行的動作都不同，例如有些電商在狀態進入處理中後，則不可以取消訂單，而是要走退貨流程，此時我們就會把所有狀態的頁面都做出來。
規則 5 : PRD 使用流程
我們將每個畫面都做完後，就會在這單元的最前面放入一頁是 User Flow，並把這單元所有頁面的關聯串起來，好處是不管是使用體驗流程複雜或是簡單，都能讓專案成員與開發的前端與後端工程師，還有設計師更了解前後關係與資料的關聯性；如果本身會遇到送出結果會有成功與失敗兩種不同的路徑時，我們也會把這兩條流程透過簡單的判斷式，來把成功流程以及失敗流程都完整呈現。
👉🏽 PRD 範例：在該頁面會有很多的按鈕 CTA (Call To Action)，我們會將個按鈕點擊後，或是輸入完後的前往方向或是呈現內容，透過關連線的引導來清楚說明每一個按鈕的互動關係。
👉🏽 PRD 範例：若遇到有藍芽連線配對時，就會遇到配對成功，以及配對失敗的狀態，以及連線過程中的畫面，我們會透過簡單的判斷式，並接續如果成功後的畫面引導，以及失敗後的畫面動作需要如何指引。
規則 6 : PRD 判斷流程
如果為系統判斷流程較複雜，可透過流程圖與判斷式來做標示，例如系統判斷「是」或「否」、「已是會員」或「尚未成為會員」等，都可以透過系統判斷式的方式來輔助說明你在設計上預期開發的邏輯判斷，流程圖也會有一些基本的框線意思，例如菱形會是系統判斷等，如果想更了解，可以看流程圖的介紹。
👉🏽 PRD 範例：例如今天有一個平台，他過去並沒有將第三方登入的帳號（Google, Facebook, LINE等）跟平台自己本身的號密碼註冊做帳號綁定，因此會遇到原本狀況是同一個人卻有兩個不同的消費記錄資訊，而後續更新希望整併這資料，就會需要做到較多的判斷式，並依據各個繁複的判斷流程，留下給使用者最好用的綁定過程，例如過程中會先判斷該瀏覽器是否有社群資料，並帶入相對應的社群頁面後進行授權，授權後會確認第三方是否綁定過，「是」則回原頁面，「否」則開始進入綁定頁面的流程，像是以手機號碼經過 OTP 驗證，作為該平台綁定的主要資料等，並依此繼續往後走所有綁定的機制。
規則 7 : PRD 極大值
如果資料長度會有所不同，例如金額、地址等，會需要做極值的呈現，與預留極值空間。
👉🏽 PRD 範例：例如在金融產品上，就必須預留該金額可能的最大值，來規劃該欄位的寬度是否預留適當，不能因為好看而只擺了理想值，導致後續超過時會破版，同時我們會出極值的畫面之外，也會將規則寫出來，以利後續接手的設計師看到時也會有同樣的概念，尤其有些本身會有小數點，像是股票相關的產品，因此這些小數點最多到幾位數也都會需要做呈現。
👉🏽 PRD 範例：而如果是以表格出現在手機、或是電腦上會超過螢幕的話，也可以有多種做法，可以是最基本的左右式滾軸，但不一定適合閱讀，或是使用者對該平台不熟悉則不知道具備滾軸資訊。因此也可以有一種做法是網站可以全攤的情況下，手機版則做成卡牌形式，或是手機與電腦版都以卡牌來設計，就可以以高度來取代寬度的問題。
👉🏽 PRD 範例：若資訊就是非常的多，且某些欄位長度不一的情況下，也可以直接限制該欄位的長度，並且將過長的內容示意出來，是要以 … 呈現或是其他方法，並且詳細看到完整的資訊，是透過 Hover 帶出資料，或是點擊進入後才能詳細看見，亦或是出現具備識別的資訊例如末五碼的方式等，都是可以解決資料太長的方法。
規則 8 : PRD 空值
尚未有資料前，也須考量空值的呈現內容，例如在空值狀態下是否有其他的引導，以及在空值情況下的文案與圖示畫面。
👉🏽 PRD 範例：在購物車尚未有任何商品時，是個可以設計的地方，例如可以出現「目前還沒有商品，快去逛逛」的按鈕提示，或是將近期正熱門的商品作為此頁引導，都可以讓這些看似基本的頁面，有了更多的巧思。
規則 9 : PRD 資料來源與規則
資料會有生成的來源與規則，須標示出來，以利合作的工程師知道資料來源在哪裡，以及設計上的規則限制。
👉🏽 PRD 範例：假如在建立一個產品模組，會先建立好類別，並在各類別下建立型號，最後個型號會綁上一組唯一的序號（例如 Serial Number），則建立後的資料，就可以知道來源來自過去這些路徑，並且在每一個環節所設定的資料，也可能決定了後面建立的內容欄位，例如在一開始建立類別時，決定了後續某些欄位是否必填，則後續建立型號時，就會帶出此類別必填欄位選項，資料之間都環環相扣，必須明確掌握資料何去何從。
👉🏽 PRD 範例：可以在規劃系統時先決定好建立一個商品時需要放的類別欄位，例如專門產品的活動模組，或是產品標籤管理、產品類別選擇等，當系統固定好欄位，並且把該欄位裡的選項都建立好後，使用者在上架商品時，就可以從這個欄位裡選到對應的標籤，可以更有效管理所有商品，不會到時候產品變多了卻難以找出所有共同標籤的困擾。
規則 10 : PRD 排序邏輯
當資料是不斷產出的形式，而不是靜態資料的話，就會有排序的邏輯，同時也可以做排序的工具來提供使用者查找資料，例如預設是新到舊排序，就需要寫出此規則，同時也能在提供使用者舊到新，或是多到少／少到多的排序，或是在狀態上的排序等。而決定排序的邏輯可以依據當前使用者體驗來決定。
👉🏽 PRD 範例：例如該頁面最重要的是審核新的申請單，那可以先以申請單的狀態先做第一波排序，例如「待審查」是排在最前，「審查中」次之等，而在「待審查」的項目中，再去排序裡面的新到舊。
PRD 工具
因為 PRD 時常會需要多人共同瀏覽，同時需要很好異動資料，所以 PM 用 Google Sheet 的方式會很方便進行管理，而我在 UX design 使用者體驗設計師這邊，除了建立在 Google Sheet 之外，也會直接繪製在我們的設計稿旁邊，所以無論是標注在 Figma 上，或是專門繪製 Wireframe 的 Axure 軟體，只要能夠清楚和專案成員溝通就沒問題囉！
以上是我在做 UX 設計時平常比較常在 Wireframe 旁邊會寫到的 PRD，PRD 對於開發數位產品時，不僅僅是一個靜態的文件，而且在整個產品開發過程中都扮演著重要的角色。這可以幫助 UXUI 設計師，以及 PM 在和團隊成員與前端後端工程師溝通產品的功能和目標，並確保他們的設計與產品需求一致，促進更好的溝通和合作。
延伸閱讀
- UXUI 設計顧問工作大開箱！6 大技巧提高你的設計價值
- 十大易用性原則是什麼？掌握 UX 核心技能，打造一流產品及服務
- 擺脫新手設計師！解析 6 大 Wireframe 實作技巧與軟體工具
- Persona 人物誌是什麼? 8 個要素與 4 個流程，讓你更理解目標消費者
- Wireframe 是什麼？從目的、對象、流程抓住UXUI的設計精髓
- UX/UI 設計師工作大解析：薪水行情、面試、職位內容
