中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文筆者將結合自己日常工作中的情況，為大家進行分析，如何用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 協議