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

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

營銷出身，先做運營，后轉產品，一直研究技術原理。做過B端、C端產品。做過PC client、Web產品、H5 app、原生app、多平臺產品?，F在做移動端社區電商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種，具體如下：

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

關于命名

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

其他說明

• PD指產品經理，產品設計師
• PM指項目經理

三、PRD閱讀指南

四、產品工作流程

4.1、發布原型

4.2、制作H5

查看大圖

4.3、PD到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從在后臺回到前臺，請展示上次打開應用的快照然后自動刷新該頁面。

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

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

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方，比如環信、極光、融云…

前后端數據延遲：

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

客戶端與服務器交互失?。?/strong>