本文筆者將結合自己日常工作中的情況，為大家進行分析，如何用Axure輸出一份結構清晰的PRD？
現在，已經有很多PM習慣用Axure直接輸出prd。但是一些PM通過Axure輸出的prd卻不是那麼完美，畢竟它不像傳統的word文檔輸出，有明確的目的、範圍、背景、功能需求、非功能需求等。
如下圖：
WORD輸出的文檔，最大的優勢就是有一個清晰的目錄結構，一眼過去就能大致明白整個項目的基本內容。但是WORD輸出文檔的缺點在於閱讀效率低下，且開發們都特別討厭長篇大論的文檔，通常情況下他們是拒絕查看的。
所以，用Axure輸出prd成了現在大部分PM的首選，但是用Axure輸出存在的缺點便是目錄層級結構不清晰。如何用Axure輸出一份程序員愛看的prd文檔，就成了首要問題。
下面，筆者將結合自己日常工作中的情況，為大家進行分析。
一、規範的目錄結構框架
在正式開始畫原型之前，我們首先應該用Axure把prd的架構搭建出來，而不是一開始就動手去畫原型，最終輸出的內容也只有最基本的交互原型，其他內容都沒有。
一個好的prd框架結構應該至少包含以下內容：產品簡介、產品概覽、產品架構、產品原型、非功能性需求，如下圖：
著重說說以下3點：產品簡介、修訂歷史、全局說明。其餘內容請讀者自行預覽項目查看：https://3zuiql.axshare.com
1.1 產品簡介
通過產品簡介，讓UI、開發、測試等相關人員迅速的熟悉產品的相關背景、產品描述、目標等，加深對產品本身的理解，有助於工作的開展。
有的小夥伴會好奇，公司通常情況下都會有產品啟動會，會上已經說清楚了這些內容，產品還有必要多次一舉再輸出這些內容麼？
答案是必然的，因為產品啟動會並不能確定所有人員都到場了，也不能確保會上所有人員都認真聽了（誰知道某個開發是不是在會上偷偷勾搭UI妹子呢…..），更不能確保產品開發中途沒有新的成員加入，所以輸出一份好的產品簡介是十分必要且重要的！
下面說一下產品簡介頁面應該包含哪些內容：
- 產品簡介：一句話說明產品核心的功能，兩三句話說明產品大概的內容；
- 目標用戶、使用場景：闡述一下什麼人在什麼情況下會使用該產品；
- 項目背景、痛點：簡單說明一下為什麼我們要做這個產品，目前存在哪些痛點；
- 產品目標：產品要解決的問題，最終實現的目標，能達到什麼樣的效果。
詳細內容各位讀者可以根據自己實際情況做一定的調整，總之一句話：讓所有參與人員通過查看頁面內容能夠迅速的理解該產品的基本情況！
1.2 修訂歷史
任何PM寫prd，都不能保證考慮全面所有場景，更不能保證在開發階段中prd不做任何變更。冒著被開發打的風險，給大家說一句：產品不改prd就好比開發寫代碼沒有bug一樣。
所以有改動是必然的，改動不可怕，但是在項目正式啟動之後，每一次改動必須要有記錄（無論改動多小），讓項目成員知道你又在搞事情，搞了些什麼事情~~~
修訂歷史必須包含：修訂的日期、當前版本號、修訂說明、修訂作者。另外，建議提供鏈接，通過修訂記錄可以直接跳轉到具體的修訂頁面。
1.3 全局規則
一定要有全局規則！一定要有全局規則！一定要有全局規則！重要的事情說三遍。
為什麼強調一定要有全局規則呢？
對於相同或者類似的規則，通常產品只會在一處標明。如在A頁面列表標註：排序按照記錄生成時間逆序排序，在B頁面同樣存在列表時，則未進行專門說明。按照產品理解，我前面已經寫清楚了按照逆序排序，所以此處同理應該逆序排序。
然後事實是：開發分模塊，每個開發人員只關心自己要開發的頁面，他或許壓根沒關心你在另外的頁面寫了什麼。所以，對於此類情況，我們應該寫進全局規則裡，因為全局規則是所有開發人員必須去查看的頁面。
全局規則具體包含哪些內容呢？
答案：只要是需要所有開發人員查看，且適用於整個系統的都可以寫進全局規則中，包括：交互說明、屏幕適配、全局字段說明等等。比如：字段‘郵箱’，在系統中多個地方出現，我們只需要在全局規則寫明1次字段‘郵箱’的規則限制即可，而不需要在‘郵箱’出現的每個地方都進行重複編寫規則。
同時一些特殊的說明也需要在全局規則頁面備註好，讓開發一目瞭然，如：下文中2.2。
二、注意事項
2.1 如何清晰地書寫邏輯規則
用Axure輸出，大家習慣性的在原型旁邊進行規則的備註。方式多種多樣，有：牽線、標號等等。
以下是個人總結出來的方式，詳細內容請看下圖（個人經驗，不喜勿噴）：
2.2 區別開頁面邏輯規則與原型上的文字
通過全局規則，說明什麼是頁面本身內容，需要在頁面顯示的，什麼是頁面邏輯規則。
如下圖：紅線圈住的內容是頁面中的元素，需要在頁面進行最終的顯示；而下面黃色部分為邏輯規則說明，只是提供給開發以及測試等人員查看，不需要實際顯示在頁面中。
2.3 修改的內容要有跡可循
關於prd的修改，很多小夥伴會說，我有修訂歷史頁面，專門記錄修訂的內容啊。
且筆者前文也提過prd架構包含修訂歷史，如下圖所示：
這不是清楚明白地寫了哪些內容更改，什麼時候更改了嗎，為什麼還要說有跡可循呢？
然而實際情況卻是這樣的，開發會很生氣的找到你，說：這一頁原型內容這麼多，難道還讓我通篇讀完對比到底哪兒修改了啊？
對於這種情況，如果不做特殊說明，開發們是很難找到你修改的位置，所以具體該如何做呢？
即在有修改的頁面進行詳細的備註，包括：修訂日期、修訂前內容、修訂後內容。
如下圖：
當然對於修訂的規範，我們應該在整個系統保持一致，且在全局規則進行說明。
這樣，開發們就能清楚明白的瞭解到你修改的部分到底在哪兒了，而不用挨個查找頁面上的元素。
三、小結
歸根結底，prd的目的就是提供相應的依據，為了讓UI、開發、測試等工作有條不紊的進行，所以prd一定要在做到結構清晰的基礎上簡潔明瞭。
究竟如何輸出一份好的prd還需要各位讀者結合自身實際情況多思考，總結出適合自己、適合自己公司的一套才是最重要的。
題圖來自 Pexels，基於 CC0 協議
閱讀更多 人人都是產品經理 的文章
