中文人妻精品一区久久,婷婷亚洲久悠悠,99国产精品成人片

搜索

APP

起點課堂會員權益

職業體系課特權

線下行業大會特權

個人IP打造特權

30+門專項技能課

1300+專題課程

12場職場軟技能直播

12場求職輔導直播

12場專業技能直播

會員專屬社群

榮耀標識

發布

注冊 | 登錄

PRD1.0分享：全面通用的移動端產品需求文檔

浪子

2017-01-16

178 評論 190291 瀏覽 2355 收藏

28 分鐘

花了大概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是需要把自己放空，通過很多非正常交互流程去模擬和梳理的。比如購買流程不可逆，此時用戶想點返回了，哪一步是可以到上一步，哪一步到不了上一步，這些就是交互設計的細節。