適用於移動端產品的浪子PRD文檔V1.0

花了大概1年整理出一份全面通用的移動端產品需求文檔，包含了我多年產品經驗以及對業務的理解，對技術原理的涉及。命名為浪子PRD1.0，請查看全文後再直達源網址。

提供Axure原型文件點擊下載，在線查看唯一更新網址。

這份PRD雖然內容很全面通用，但是還不夠系統結構化。所以才命名為1.0。首先希望對大家有幫助，其次希望大家給我提建議，然後可以不斷迭代到2.0、3.0……

營銷出身，先做運營，後轉產品，一直研究技術原理。做過B端、C端產品。做過PC client、Web產品、H5 app、原生app、多平台產品。現在做移動端社區電商APP的商城模塊。相信這樣的經歷和大家應該可以共鳴。

從網上學到了很多產品文章，最終自己也算是略有心得，所以特此回饋給大家。

先預覽一下PRD的結構

?

一、畫原型的步驟

?

二、PRD撰寫原則

其實我覺得這個特別重要，但是偏理論了。

大原則

業務優先於需求，需求優先於功能，功能優先於交互，交互優先於UI。

PRD的目標

旨在對APP項目的業務架構&產品流程&功能需求做詳細的介紹，為產品後續的需求、設計、開發、測試、上線提供依據。

• 向項目組成員(項目經理、開發、測試、運營)傳達產品的業務信息與需求細節。
• 管理需求，進行歸檔，為後續需求迭代與變更提供依據。
• 實現項目的規範化管理。

PRD的撰寫說明

• 只有一種輸出物，在線原型。
• 只用原型傳達思想和表意，不過度考慮視覺呈現。
• 邏輯確定後不經常改動，如有必要上線前統一和前端對照並修改。
• 內容文案是否經得起推敲，頂部標題以及按鈕文案以及各種小提示是否簡潔清晰。
• 內容結構：一級目錄使用"一"，二級目錄使用"1"，三級目錄使用"③"。
• 元件樣式和交互的通用規則，請寫到全局規範。其他寫到對應的元件邏輯中。
• 寫的邏輯禁止不確定字樣(也許/可能/maybe/考慮/好像/類似/暫時/待定/等等/像/真的/？)
• 所有變數統一使用紅色表示並且配上說明，比如滿x元減x元。
• 英文單詞盡量小寫，易識別。除非是約定俗成的詞語，比如iOS、Android。
• 雙引號&單引號&小括弧不使用全形，只有半形。

需求描述原則

• 表述清楚需求的位置是在什麼位置，比如"x"頁面、還是"x"頁面的"x"元件。
• 需求是新增"x"功能、還是修復"x"bug、還是優化"x"功能。

技術處理原則

• 某些場景下技術上可以考慮合併多步操作，以減少客戶端對於異常情況的判斷。比如確認訂單頁面的保存地址並返回運費。
• 某些警告框應該當做頁面來處理數據埋點以及交互，單獨說明。
• 盡量解耦到每一個頁面，每一個警告框，而不是多個頁面之間關聯性太強。

PRD的核心模塊

• 頁面，寫在Axure的Pages中。生成原型後請點擊左側Pages進行查看。
• 交互，寫在Axure的Interaction中。生成原型後請點擊左側Pages中的鏈接圖標進行展示和隱藏。
• 邏輯，寫在Axure的Notes中。生成原型後請點擊左側Notes後查看，或者點擊右側元件旁邊的圖標進行查看。

元件的邏輯有5種，具體如下：

• 功能邏輯：詳細講解該功能的邏輯。
• 交互邏輯：對頁面之間的相互跳轉進行說明。
• 視覺邏輯：對顏色，對圖標的要求。
• 業務邏輯：講一下該功能對應著什麼業務。
• 技術邏輯：有些邏輯可能用技術語言描述更清楚一點，以及對技術有特殊的要求。

關於命名

• 動作，狀態的命名一定要區分，比如刪除是動作，已刪除才是狀態。
• 動作的命名一般是"操作+名詞"，比如修改文章。
• 條件的命名一般是是否怎麼樣。
• 功能的命名要麼是名詞，比如購物車；要麼是動賓短語，比如確認訂單。

三、PRD閱讀指南

?

四、產品工作流程

?

4.1、發布原型

?

4.2、製作H5

?

查看大圖

4.3、PM到UI

?

4.4、項目開發

?

4.5、處理BUG

?

所有問題都需要填寫注釋。

• 修復：簡要填寫問題原因，並說明如何修復
• 外部原因：寫清楚來源
• 無法重現：寫大概需要哪些條件
• 問題重複：填寫重複問題的bugid
• 功能設計如此：把功能邏輯鏈接到這裡
• 是問題但不修復：補充不修復的理由
• 下版本解決：填寫大概解決時間，並在解決後指派給提出者驗證

4.6、軟體測試

?

4.7、UAT測試

?

五、PRD全局清單

?

六、內稟原則

內稟規則是什麼？指業務實體本身具備的內在規則，並且不受外部以及用例交互的影響。這類規則應該實現到你的實體類中，根據面向對象的封裝原則，內稟的邏輯一定不要讓它暴露到外部。不論你的業務實體是EntityBean，JavaBean，POJO還是COM+。

操作者是誰？程序員

如何獲得？需要對每個業務實體的屬性進行羅列，並找出它們的規則。最主要的來源是業務執行者，需求人員應該更多的去與他們交流。

6.1、時間

日期：yyyy-mm-dd

周幾：周一/周二/周三/周四/周五/周六/周日

時分：hh:mm

時分秒：hh:mm:ss

發佈於什麼時間：

• 適用於消息列表/消息詳情/動態列表/視頻列表/直播列表等feed流，詳見下方流程圖
• 當前時間取本機時間，有精力的話前端童鞋可加判斷，如果發現本地時間和伺服器時間不一致，需做統一。

其他：

建議服務端按照時間戳來存儲，並且格式是yyyy-mm-dd hh:mm:ss

?

6.2、距離

一、絕對距離如何顯示

• xm，當距離＜1000米，比如356m
• xkm，≥1000米，比如5km
• 最小值是1m，最大值9999+km。

二、地理位置如何顯示

顯示格式"省份城市"，比如江蘇南通，如果取不到顯示"未知"。注意直轄市只顯示"直轄市名稱"。

6.3、賬號

什麼是賬號？

用戶的唯一身份id

如何處理搶登？

當用戶使用手機a登錄了賬號，又去用手機b去同一賬號，從而形成搶登。

第一個手機收到推送，顯示警告框"該賬號已在其他手機登錄，如非本人請趕緊登錄然後修改密碼。"和確定按鈕，點擊確定按鈕回到App首頁並重新載入。

其他

• 身份證號必須是15或18位
• 手機號必須是11位

?

七、交互規則

交互規則是什麼？產生於用例場景當中，規定了滿足什麼條件後業務將如何反應。比如當提交一份訂單時，哪些數據是必須填寫的，用戶身份是否合法。當然也包括一般理解上的業務流程流轉規則等，比如金額大於一萬元的訂單被定為VIP訂單進入特殊流程等。

交互規則實際上還有兩個是比較特殊的，一個是前置條件（入口條件），即Actor滿足什麼條件才能啟動用例；另一個是後置條件（出口條件），即用例結束後會產生哪些後果。通常這部分規則是複雜多變不穩定，所謂的需求經常變更絕大部分來自於此。因此將這些規則單獨列出來並給予關注和管理是很有必要的。同時這部分規則通常在系統中以Control類去實現，MVC模式/SOA架構中的BPEL也是如此。既然需求無可避免的要變更，那麼將交互規則單獨提取出來，並設計成為擴展性很強的結構就是一種有效的應對手段。

操作者是誰？交互設計師or產品經理

如何獲得？從用例場景而來，每一個場景，每一個交互的過程可能都隱含著規則。需要與客戶多討論。交互規則最主要的來源是業務提出者和業務管理者，最好不要去找業務執行者。

7.1、狀態切換

?

7.2、常用輸入欄位

?

7.3、邊界問題

需要處理的異常邊界

異常處理一般來說，pm還是會非常重視的。比如購物車商品減到0需要提醒用戶二次確認是否把商品從購物車去掉、或者用戶輸入的密碼不符合規範，需要提醒用戶調整。這些很多異常情況，pm是需要把自己放空，通過很多非正常交互流程去模擬和梳理的。比如購買流程不可逆，此時用戶想點返回了，哪一步是可以到上一步，哪一步到不了上一步，這些就是交互設計的細節。

?

7.4、交互常見十二狀態

?

八、全局規則

全局規則是什麼？通常與所有用例相關，而不是與特定用例相關。所以應該抽象出來讓系統去負責這些特性的實現。比如Actor要給朋友發圖片以及在朋友圈發圖片用例必須獲得相應的授權，或者用戶在系統中的所有操作都要被記錄下來等等。

授權，事務，備份等這些全局特性都是由系統框架去實現的，具體的功能中只是調用而不再實現它們。

操作者是誰？架構師or產品總監

如何獲得？很難從用戶處調研得來，通常這方面是用戶的盲點。主要是由有經驗的系統分析員，或架構師以及客戶方的IT部門，從業務特點、應用環境、行業規定、法律規章等等方面去總結，再求得客戶方的認可。

?

8.1、啟動

自動刷新的時間差取決於你們的業務本身，但是也需要考慮伺服器的承載問題。

iOS系統有後台喚醒自動刷新的方法，時間差由系統決定，僅需RD調用此方法即可。

Android可以根據判斷此次打開和上次刷新的時間差，超過產品設定的時間差就自動刷新。

說明哪些地方從後台切換回前台時需要進行數據更新。

只列出需要考慮的場景，iOS只有系統級別的事件處理。當APP從在後台回到前台，請展示上次打開應用的快照然後自動刷新該頁面。

以上事件中，刷新當前頁面之前加一個鉤子，判斷該頁面是由經常更新的模塊或者列表構成，具體可諮詢pm。

鉤子的具體解釋最好百度一下，有點像預先留下伏筆然後通過這個判斷是否需要回調刷新頁面數據的事件。

?

8.2、授權

?

查看大圖

8.3、手勢

?

8.5、頁面

?

8.4、頁面類型

?

8.5、啟動頁

8.6、閃屏頁

?

8.7、故事板

?

8.8、主界面

?

8.9、頁面狀態

?

8.10、頁面間轉場

?

8.11、頁面載入類型

?

查看大圖

8.12、頁面刷新類型

?

8.13、圖片

?

查看大圖

九、非功能性需求

9.1、網路需求

處於不穩定網路狀態：比如在走動中，地鐵火車上

當切換網路時：比如有無wifi連接/有無有線網路/手機wifi和有線網路互切/飛行模式

視頻播放場景：比較特殊，點擊查看詳情

9.2、數據需求

新舊數據衝突：

1、重要

• 客服告訴客戶什麼時候數據遷移完成，能否接受。
• 用戶主動，停止服務，告訴用戶可以保存到什麼時候，讓用戶自己主動備份。
• 用戶被動，數據遷移到哪裡去，給個能找到數據的入口。

2、重要但又不那麼必要

• 導出數據給到客戶
• 客服和客戶進行協商
• 只要敢就可以沒有

數據內容過期/刪除/違禁後如何展示/產品售罄下架：

1、內容過期

• 告訴用戶過期時間，比如微信紅包
• 相關內容關聯推薦
• 專題類/活動類的下次開始什麼時候

2、刪除

手段同內容過期

3、違禁後如何展示

告訴用戶我們產品的態度，違禁原因，保護產品生態人人有則，即使用戶之前看過/收藏過，這是原則。

數據內容展示/更新機制：

• 冷啟動數據(極其不常用，不想影響安裝包大小)，打在安裝包里，不變的產品架構可以先緩存進去
• 需要說明哪些地方需要手動刷新？哪些地方需要自動刷新？(再次進入頁面時刷新；設定一個時間值每隔一段時間刷新)一個時間值哪些地方是手動+自動刷新
• 說明哪些地方從後台切換回前台時需要進行數據更新？
• 需要說明哪些內容需要實時更新，哪些需要定時更新？
• 說明數據展示部分的處理邏輯，是每次從服務端請求，還是緩存到本地。
• 用戶更新或者上傳操作時，是否顯示進度。
• 數據多維度排序規則
• 時間，信息流淚產品，微博/微信
• 流覽/贊/收藏，推薦/搜索常用

數據處理：

• 閃退後數據是否丟失
• 卸載刪除軟體數據如何處理
• 數據安全
• 數據存儲極限/跨平台同步
• 數據被移除時會發生的情況
• 數據過多或者過少數據需求導致布局和UI的改變
• 在不同時段/不同數據許可權數據推薦顯示機制
• 如何處理大量數據
• 數據同步被打斷
• 數據或架構更新時會造成影響
• 無效數據的處理

數據版權：

用的別人數據是否有數據來源等版權說明

?

9.3、性能需求

耗電情況：

不停與伺服器交互數據，尤其是首頁各個業務都想顯示自己的數據，產品經理要權衡克制。

流量：

• 不停與伺服器交互數據，尤其是首頁各個業務都想顯示自己的數據，產品經理要權衡克制。
• 多用wifi條件下自動緩存，設置上限即可。
• 是否需要提供流量包。

大並發：

• 整體最大能支持多少人同時訪問
• 指定功能最大能支持多少人同時訪問
• 大促活動最大能支持多少人同時訪問

需要考慮：

• 舊功能更新，根據以往數據和增量估算
• 新產品/新功能，O2O根據線下的量進行估算
• 新產品/新功能，給的流量入口的進行估算

訪問速度：

訪問速度達到多少

其他：

前端閱讀頁面以及列表頁面，需滾動流暢，滾動閱讀時不停頓不卡頓。後台數據處理能力應滿足幾十萬用戶的操作使用。更改與設置密碼與手機號時，後台應立即發出簡訊。

9.4、安全需求

是否已加固：

APP安裝包是否加固過，是否符合應用市場的安全規則。

是否已混淆代碼：

APP安裝包是否混淆過代碼，以防被競品開發者破解其代碼。

是否符合法規：

產品需符合網路安全部的相關規定。

數據安全性說明是否完整：

輸人的密碼將不以明文形式進行顯示，備份應該加密，恢複數據應考慮恢復過程的異常通訊中斷等。

9.5、兼容需求

考慮不同屏幕的兼容性：

原則是根據主流機型給出優先順序。

考慮不同系統的兼容性：

比如iOS系統中目前主流系統有iOS8、iOS9、iOS10三大類。

Android系統中就更分散了。

考慮是否支持橫豎屏切換：

如果支持，也存在屏幕內容兼容問題。

9.6、後台需求

介面數據：

第3方SDK

內部數據

Push消息：

什麼時間向什麼要push什麼內容消息等等，一定要考慮伺服器。

自己做，還是採用第3方，比如環信、極光、融雲…

前後端數據延遲：

有時前端功能與後端、伺服器因時延會導致進度不匹配

客戶端與伺服器交互失敗：

任務提交失敗與伺服器通訊失敗

新數據覆蓋舊數據：

如果涉及到修改底層欄位或者表結構，該怎麼兼容老版本的客戶端。

9.7、其他需求

簡訊通道

登錄註冊/支付狀態一定要走高速通道，活動類可以走低速通道。

支付通道

直接對接支付寶、微信。還是採用中轉的ping

郵件服務

採用自己開發的，還是第三方的webpower…

分享

點對點分享和分享到朋友圈文案和圖片顯示。

各種服務電話

最好在產品裡面留一個用戶聯繫官方的渠道，不管是電話還是郵件還是私信。

十、APP開發前期準備

框架生成：

• 製作需求溝通確認
• 管理平台開戶
• 雙版本APP框架輸出
• APP內容架構組織

設計製作：

• APP界面設計
• APP素材收集與加工
• APP圖標設計
• APP內容製作上傳
• 客戶確認

測試調優：

• APP內容測試
• APP性能測試
• APP功能測試
• APP視覺測試

APP發布：

• APPstore發布
• 主流安卓市場發布
• APP下載頁(web/wap)
• 二維碼生成
• APP應用手冊
• 企業APP交付

10.1、用戶環境

?

10.2、開發環境

?

10.3、單頁&多頁H5應用

?

10.4、Web&Mobile區別

?

10.5、Native&H5的區別

?

十一、版本記錄

?

11.1、里程碑

?

11.2、發布準備

?

十二、項目概覽

?

12.1、使用SDK

?

12.2、分享APP

?

12.3、項目數據

?

十三、總結

如果覺得有用，請點贊。如果覺得有問題，請評論。查看以上所有內容可以點擊我的原型地址浪子PRD。

作者：浪子，關注公眾號langzisay查看全部文章，浪子PRD系列http://51prd.com/。

推薦閱讀：