前段時間寫過一篇《產品新人寫PRD時應該避免的坑》朋魔，收到一些反饋，問題主要是兩個方面：一唾戚、沒有技術背景柳洋，很多方面考慮不到，怎么辦叹坦？二熊镣、寫PRD時，怎樣考慮的更加全面一點？今天主要就這兩個問題绪囱，談談我自己的看法测蹲。

問題一：沒有技術背景，寫PRD時很多方面考慮不到鬼吵，怎么辦扣甲？

我也是完全沒有技術背景的。對產品來說齿椅，沒有技術基礎琉挖，無疑是有劣勢的。但是媒咳，這種劣勢并非不能彌補粹排。

PRD本質上也是一種產品，寫好PRD和做好一款產品的思路是一樣的涩澡。

第一顽耳，不忘初心。

“不忘初心”的意思是妙同，不管是提交一個新的產品方案射富、還是思考頁面上一個按鈕的位置，你都要時刻提醒自己做這件事的目的是什么粥帚，是增加活躍胰耗、提高停留時長還是增加購買的轉化率？這很重要芒涡，因為我發(fā)現柴灯，很多時候，做著做著就開始糾結于細節(jié)费尽，而忘記了”初衷“赠群？現在每當我和別人就不同方案爭執(zhí)不下時，我都會提醒自己“來旱幼，讓我們回到最初做這件的目的上……”查描。

插個題外話，很多情況下柏卤，不同的方案都是隱藏著不同的前提假設冬三，見過太多無效且浪費時間的爭論，原因就是只糾結于方案的細節(jié)缘缚，卻忘記了這兩種方案基于是不同場景假設和用戶假設的勾笆。一句話，在前提假設沒有統(tǒng)一的情況下忙灼，爭論的唯一作用就只是練口才而已匠襟。

第二钝侠，調查用戶需求。

PRD的用戶就是看文檔的人酸舍，去問你的用戶帅韧，他希望得到什么？他喜歡什么樣的方式啃勉？他覺得哪些地方要改進忽舟？比如，只要一逮到機會淮阐，我就會不厭其煩的跟測試叮阅、開發(fā)講：”你覺得原型和PRD有問題時，一定要告訴我捌亍浩姥！“”文檔怎么寫，你們看起來會舒服一點状您？“”親勒叠，你覺得我用word寫，還是Excel寫比較好膏孟？“……各個公司的文化和偏好不同眯分，PRD也應該做相應的調整。使用PRD的人覺得好柒桑，才是真的好弊决。

第三，搜集用戶反饋魁淳，不斷改進飘诗。

和產品一樣，PRD也是有迭代的界逛，要想著每個版本都要做的更好一些疚察，從語言表述、模塊劃分仇奶、排版方式一點一點的改進，然后聽大家的反饋比驻。

第四该溯，總結

在上述兩個步驟中，你可能搜集到了很多的細小的改進意見别惦，這些可能并不影響大局狈茉，但產品人的專業(yè)性就體現于你對細節(jié)的把握。很多知識點掸掸，方方面面氯庆，很瑣碎的蹭秋，說不定過兩天你就忘記了，所以這些細微的地方一定要記下來堤撵，仁讨。強烈推薦使用腦圖進行記錄（腦圖深度愛好者，離開腦圖沒法活）实昨，然后定期的總結洞豁、歸納，你一定會收獲很多荒给！

最后記住一點：別人沒有教你的義務丈挟，不教你無可厚非，教你就是情分志电！

問題二：寫PRD時曙咽，怎樣考慮的更加全面一點？

這也是讓我苦惱很久的問題挑辆，我也經常在朋友圈長吁短嘆：“我考慮問題什么時候才能面面俱到例朱、滴水不漏呢？”以前有試過把所有的注意點都用腦圖整理下來之拨，然后茉继，每寫到一個模塊就對照一遍，后來發(fā)現很麻煩蚀乔，也很費時間烁竭。臨時抱佛腳用處不大，關鍵還是平時要多積累吉挣，總結的內容也要撑伤海看，多看就印象深刻睬魂，用的時候自然能夠想起來终吼。

作為方法論的愛好者，我喜歡歸納做事情的步驟氯哮，每做一次總結一次际跪，這樣可以做到心中有數，而且慢慢就知道哪里是坑喉钢、哪里容易出錯姆打。

我描述一個頁面一般是按照以下步驟考慮的：

1、前置條件：

描述頁面顯示為此種狀態(tài)的前提條件肠虽。比如幔戏，QQ的群管理員和普通成員點擊同一個按鈕，進入的頁面就可能是不同的税课。

前置條件可以概括為：某種用戶角色（要提前準確定義APP中的各種用戶角色）在某種情況下闲延，點擊某個頁面的某個按鈕痊剖，進入了此頁面。

2垒玲、退出機制：

如何退出此頁面陆馁？常見的有：左上角的返回按鈕，返回上一層侍匙；按手機返回鍵（安卓）也返回上一層氮惯。

3、顯示機制及排序機制：

1）描述頁面上有哪些控件想暗、展示了哪些內容妇汗。

想象你和一個 陌生人介紹這個頁面，選擇一個能有邏輯的描述這個頁面的方法说莫，比如從上到下杨箭、從左到右、從重點到一搬储狭、從特殊情況到普通狀態(tài)等互婿。

2）當頁面需要展示很多內容時，就要考慮排序機制了辽狈。

按照哪些因素進行排序慈参？是按時間倒序、熱度正序刮萌、推薦的內容排頂部驮配？還是其他更加復雜的排序方式？

還要考慮一頁顯示多少條信息着茸，以什么方式進行展示呢壮锻？翻頁展示還是瀑布流？

4涮阔、刷新機制

一次刷新多少條信息猜绣？如何刷新更多？自動刷新還是手動刷新敬特？當刷不出新內容時給提示了么掰邢？

常見的手動刷新方式：右上角有刷新按鈕，點擊伟阔，手動刷新尸变。

常見的自動刷新：再次進入此頁面時刷新；設定一個時間值减俏，每隔一段時間自動刷新一次。

5碱工、緩存機制

這個頁面要緩存哪些數據娃承？緩存到哪里奏夫？清理緩存的時機是什么？是定時自動清緩存历筝、還是讓用戶手動清理酗昼？

上面5大機制，可能在一個APP的很多模塊中梳猪，都是一樣的麻削，為了避免重復描述，建議在PRD的最開頭春弥，用一個單獨模塊來描述呛哟，以后在描述頁面時，一筆帶過就可以了匿沛。

6扫责、控件描述

建議用一個單獨的模塊說明應用內常見控件的類型以及每個控件對應的操作方式，在其他模塊涉及此控件時逃呼，只要簡單闡述一下就ok了鳖孤。此部分之前的文章已經寫過，在此就不詳述了抡笼。

1）觸發(fā)源：

此控件的觸發(fā)區(qū)域是哪一部分苏揣？同時思考，需要頻繁觸發(fā)的控件推姻，操作區(qū)域是否明確平匈？

2）觸發(fā)時：

觸發(fā)控件時常見的狀態(tài)有：加載狀態(tài)、讀取狀態(tài)拾碌、緩沖狀態(tài)吐葱。

比如視屏播放應用，點擊播放按鈕校翔，通常會出現上述幾種狀態(tài)弟跑。

3）觸發(fā)后：

觸發(fā)控件后常見的狀態(tài)有：

a、操作進度顯示防症。

例如孟辑，點擊“下載”按鈕，常常會顯示下載進度條蔫敲。

b饲嗽、按鈕發(fā)生變化。

比如互相不是好友的情況下奈嘿，頁面上的按鈕為“加為好友”貌虾，點擊，成功加為好友之后裙犹，“加為好友”按鈕就會變成“發(fā)消息”按鈕尽狠。

c衔憨、結果提示。

常見的提示類型：小紅點提示袄膏、能自動消失的提示践图、頁面上的文案提示、需要用戶選擇的彈框等沉馆÷氲常考慮這些提示的輕重程度是否合適，并且要對他們進行詳細的描述斥黑。

常見的結果類型：成功揖盘、失敗、空值心赶。比如扣讼，搜索功能。點擊搜索按鈕后缨叫，有可能找不到想要搜索的內容（空值）椭符、有可能找到很多條相關內容（此時要考慮排序）。

7耻姥、異常情況描述

1）異常操作：

比如销钝，連續(xù)多次點擊，是否給予反饋琐簇。

2）網絡狀況：

沒網絡時的提醒蒸健？是否需要網絡超時、網絡太慢婉商、從wifi切換到2G/3G的提醒似忧？

3）賬號相關：

登錄和未登錄時，對此按鈕的操作權限是否有差別丈秩？如果必須在登錄狀態(tài)下才能操作盯捌，就要增加登錄提醒。

如果同時支持iOS和安卓蘑秽，那安卓賬號和iOS賬號是否互通饺著？

4）數據相關：

要定義頁面的默認狀態(tài)，默認狀態(tài)就是進入頁面時肠牲，如果從服務器獲取不到數據時幼衰，頁面的顯示狀態(tài)∽忽ǎ考慮此時渡嚣，是否要內設置默認圖片。

5）版本相關：

版本的命名要規(guī)范⊙暇埽考慮版本是否強制更新扬绪？如果提交AppStore審核，版本上線時間要把考核時間考慮進去裤唠。

6）其他：

是否設置啟動頁和引導頁？

應用內文案是否需要做相應調整莹痢？

是否需要進行埋點种蘸，以便分析用戶行為？

消息推送的策略是什么竞膳？調用系統(tǒng)通知還是用第三方航瞭？

需要硬件交互么？需要請求GPS坦辟、相機需要等的使用權限么刊侯？

經過上述步驟，一個頁面基本就描述清楚了锉走，上述的描述方式和邏輯都是根據我自己的習慣總結而成滨彻，大家也要總結合適自己的方法。

最后挪蹭，再總結一下描述頁面的整個邏輯吧亭饵。

最后想說的是，有句話大家都知道-——“不要用戰(zhàn)術的勤奮掩飾戰(zhàn)略梁厉！”想要獲得戰(zhàn)略層的知識可能真的沒有捷徑可走辜羊，就算喬布斯手把手的教你也不一定有用，它需要你整個格局的提升词顾，需要閱歷八秃，需要你常年累月的思考。但阿七一直深信肉盹，戰(zhàn)術層是有捷徑的昔驱，不管PRD、原型還是交互垮媒，需要的都是勤奮舍悯，”學習別人的經驗、去糟粕取精華睡雇、自己動手萌衬、總結得失、提升經驗值“它抱，循環(huán)下去秕豫，進步就會很快。