一、在產品的整個開發流程中，PRD的作用有以下幾個方面：

• PRD指導其他部門進行工作的準備工作

測試根據PRD寫測試用例；開發經理根據PRD寫開發文件；UI根據PRD和原型設計。

• PRD承擔字典的工作

測試人員可能更多的是根據測試用例工作，而開發看的更多的是開發文件。但當大家發現某個細節在測試用例或者開發文件描述不清楚或者難以理解時，就會翻出PRD查詢相關內容。PRD在這個時候是承擔了一個字典的功能。

• PRD是打架必備。

測試和開發的天然屬性決定了他們之間微妙的關係，很多時候bug的定義是似是而非的，很多時候涉及到使用者體驗的問題，而使用者體驗有帶有很大的個人主觀性，此時矛盾就出現了。

當測試和開發就某個問題爭論的面紅耳赤，幾乎要幹架時，最後一句壓場的話就是“別瞎bb，看PRD！”，此時要是PRD上有關於此問題的詳細描述，那開發要麼找產品經理改需求，要麼只能自己改程式碼了。
要是PRD上沒有相關內容，那開發就可以傲嬌的說“需求就是這麼寫的，你要改，先去找產品改文件！”。
所以一般來說，測試是希望PRD寫的越詳細越好，這樣他們的bug才提的有理有據，而開發希望提出的需求能夠邏輯嚴密，但不太希望產品經理將所有的細節都規定死，畢竟產品對於技術的瞭解並不深。所以產品要注意把握好度，這點我自己還在不斷的思考之中。

二、做到一下這些，瞬間覺得文件簡潔了許多

剛開始寫PRD的時候，不知道有些功能可以整合在一起說明，每次都羅裡吧嗦的全部重新說一遍。
比如，分享功能，應用裡很多地方都涉及到了，每一次涉及分享，我都會把分享的機制從頭到尾說一遍，其實這就很囉嗦，文件的文字本來就夠多了。
所以，建議將一些在軟體裡反覆涉及的功能提煉出來統一說明，當後續涉及到的時候，簡單闡述一下就行，不用再重頭說一遍。

我的經驗是，對控制元件及一些通用的機制進行統一說明，會使文件簡潔省力一點。

在文件的一開始，最好有一個單獨的模組說明應用內使用的控制元件，說明這些控制元件的型別以及每個控制元件對應的操作方式，在這個模組統一說明之後，在其他模組涉及此控制元件時，只要簡單闡述一下就ok了。

下面列舉了一些常用的控制元件。

模組一：控制元件說明

輸入框
●若輸入框有預設提示，點選輸入框，彈出軟鍵盤。
●當輸入框內不為空(空格除外)時，預設顯示消失。

軟鍵盤的彈出及退去機制
●當輸入框內必須輸入的為數字時，彈出數字軟鍵盤。其餘時候，彈出文字軟鍵盤。
●當在軟鍵盤以外區域，點選或者向下滑動時，軟鍵盤退去。

小黑塊提示
●顯示*秒，然後自動消失。

選擇彈框
●彈框上有操作按鈕。
●點選彈框以外的區域，彈框消失。

手機返回鍵(安卓)
點選手機上返回鍵，返回上一層，並彈出相應提示。

Home鍵
按home鍵，程式改為後臺執行，再次開啟軟體時，則回到按home鍵時的頁面。

在文件的一開始，最好有一個單獨的模組說明應用內使用的控制元件，說明這些控制元件的型別以及每個控制元件對應的操作方式，在這個模組統一說明之後，在其他模組涉及此控制元件時，只要簡單闡述一下就ok了。下面列舉了一些常用的控制元件。

同樣，很多通用的機制也能整合在一起，比如載入機制、快取機制、網路判斷、中斷機制等， 以下是我自己整理的幾個通用的功能。

模組二：通用功能

快取機制
每一步操作、每一個頁面切換之後，都要想得到的資料需要快取麼？快取到哪裡？清理快取的時機是什麼?

網路判斷
●一般當涉及到下載或其他很耗費流量的操作時，會進行2/3G網路還是wifi網路的判斷，當判斷出是非wifi狀態時，會進行提醒。
●其他需要向後臺請求資料時，只進行簡單的網路狀況是否良好的判斷，當網路狀況不良時進行提示。

中斷機制
除退出登入外，要考慮出現什麼情況會導致使用者中斷操作。中斷操作會有什麼影響，比如是否要儲存操作進度等等。

常見的幾種情況如下：
●來電
●Home鍵，退到後臺執行。
●按返回鍵(安卓)
●頁面上有暫停使用的功能，比如倒計時、音訊播放過程中的暫停按鈕。

雖然APP千差萬別，但不管設計原型還是寫PRD時，只要涉及到頁面和控制元件，有些東西還是相通的，下文整理了一些要考慮到的方面。

頁面的相關注意點

●此頁面的使用場景是什麼，使用者進入此頁面目的是什麼?我們設計此頁面的目的的是什麼?我們希望使用者長時間停留此頁面麼?
●前置條件：有幾種方式進入此頁面;不同的身份進入此頁面時，操作許可權有差別麼?
●退出此頁面的機制。常見的有：左上角的返回按鈕，返回上一層;按手機返回鍵(安卓)也返回上一層。
●操作手勢：比如在左右側抽屜，左右劃通常可以返回主介面;比如頂部有切換Tab，是採用左右劃切換還是點選切換;還比如有些應用雙擊可放大頁面，兩個手指按住並同時向中間滑動，表示縮小頁面，比如長按可能會彈出複製及貼上的選擇框。
●身份不同、頁面的顯示內容不同

比如被踢出群組後，在被踢出人的聊天頁面和其他人的聊天頁面，顯示內容是不同的;再比如，管理員和普通成員的操作許可權不同，所以進入同一頁面時，顯示的內容也不同。

預設框架（常常忘記！）
當頁面有好幾種狀態時(比如2張圖片和3張圖片時，頁面的狀態就是不同的)，要定義預設狀態，及定義頁面的預設框架。
進入頁面時先顯示預設框架，向後臺請求資料後，根據後臺資料，頁面再調整為對應的框架。

資料為空時的預設圖片（常常忘記！）
上一條定義了頁面的預設框架，但僅有框架是不夠的，還必須定義框架中的預設顯示圖片，此圖片會打包進入安裝包，網路狀況不好，向後臺請求不到資料時，就會顯示預設框架和預設圖片。

顯示機制、排序機制、重新整理機制
確定app要適配的螢幕大小，iOS支援到什麼版本，安卓要適配的解析度是多少。
然後要形成自己的直覺，適配的最小解析度的螢幕最多能放多少按鈕，現在的設計方案放在要適配的最小螢幕上，會不會太擠。
當某一行字數太多時，一定要想這麼多字放不放的下，放在一起好不好看。
是考慮翻頁還是瀑布流?

排序機制。
一個頁面顯示多少?按照哪些因素進行什麼排序?

重新整理機制。
一次重新整理多少？如何重新整理更多？自動重新整理還是手動重新整理？當刷不出新內容時給提示了麼？
常見的手動重新整理方式：右上角有重新整理按鈕，點選，手動重新整理。
常見的自動重新整理：再次進入此頁面時重新整理;設定一個時間值，每隔一段時間重新整理一次。

控制元件的相關注意點

●控制元件是指例如按鈕、選擇框、切換tab、滑動條等等之類的可操作的部件。
●控制元件的各種狀態出現的前提條件是什麼？不同身份進入頁面時，按鈕的狀態一樣麼？
●控制元件的狀態定義？比如，比如提交按鈕，要定義清楚什麼時候可點，什麼時候不可點
●控制元件的位置、大小是否合適？待操作按鈕在當前介面中是否明確?重要、頻繁觸發的功能按鈕是否在手機的可操作區域？
●控制元件的操作方式有幾種？每種操作的結果是什麼？使用者能找到隱藏的比較深的操作方式麼？需不需要加使用者引導？

常見的有：點選、長按、左右劃

操作過程中的狀態改變
●載入：狀態改變的等待時間是否超過2S左右，如果太長是否需要加入載入狀態
●讀取
●緩衝
●操作進度顯示：如進度條、

操作過程中的繼續操作
考慮按鈕操作過程中的繼續操作會造成什麼影響?操作進度需要儲存麼?需要進行提示麼?
常見的繼續操作：取消、切換、返回、點選其他區域、再次連續的點選此按鈕

操作過程中的中斷
（參考 通用功能 “中斷機制”）

操作之後
●是否出現了合適的提示？出現的提示的型別：選擇輕(tip/小紅點)、中(Toast)、重(提示框)優先級別是否恰當
●操作後按鈕狀態的變化
●操作後出現的各種結果：成功、失敗、空值

思考對操作之後出現的結果，再次進行操作，會出現什麼情況?
思考特殊情況對此按鈕的操作帶來的影響：
●此按鈕的操作對網路的要求是什麼?wifi還是2/3G網路?網路的判斷邏輯是什麼?網路不好時，進行合適的提醒了麼?
●此按鈕要求登入麼?如果未登入能進行操作麼?需要進行登入提醒麼?
●多次連續的點選，會造成什麼影響?是否給予反饋?
●操作之後得到的資料需要快取麼?快取到哪裡?清理快取的時機是什麼?
●一些操作實施後，引起的變化是什麼時候顯示出來?即可顯示?此刻不顯示，再次進入此頁面時顯示?還是此刻不顯示，再次進入應用時顯示?

比如，聊天記錄刪除後，返回聊天頁，是立即清空聊天記錄還是再次進入時清空?
總的來說，PRD屬於操作層面的技能，要儘量有理有據，邏輯嚴密。

曾聽到過一種說法：產品er的門檻在入行之後。深感認同，產品經理近年來是一個被炒得很火的職位，沒經驗、不會技術，不懂運營，都能成為產品，產品經理聽起來大小也算一個經理，貌似光鮮亮麗，可實際情況卻不是這樣。

小公司，技術為王，產品的許可權其實很小，大的戰略方向有boss定(對需求實現細節指手畫腳的boss真心很不少)，很多時候boss直接拍腦袋，這個按鈕擺這裡，那個按鈕擺哪裡，抄抄微信吧，抄抄陌陌吧……
有時候你真的會很沮喪，但沒辦法，想辦法說服別人，也是PM必備技能，學著用資料說話，儘可能的考慮周全，有理有據，首先自己要很確定，才能說服別人。