本文主要內(nèi)容是關(guān)于互聯(lián)網(wǎng)產(chǎn)品策劃過程中的設(shè)計方法總結(jié)，是我這幾年實戰(zhàn)留下了的些許心得，通過問答的形式，來說明產(chǎn)品設(shè)計和項目過程中需注意的問題，可作為自檢思考工具。

包括內(nèi)容：需求分析、文檔輸出、體驗細節(jié)優(yōu)化、異常防錯處理等。

第 1 問：需求優(yōu)先級應(yīng)該如何排布？接下來應(yīng)該優(yōu)先啟動哪個需求

根據(jù)美國哈佛大學(xué)教授雷蒙德·弗農(nóng)(Raymond Vernon)的《產(chǎn)品生命周》理論，產(chǎn)品周期可分為：導(dǎo)入期–成長期–成熟期–衰退期?；ヂ?lián)網(wǎng)產(chǎn)品在這個四個階段，對應(yīng)的產(chǎn)品規(guī)劃重點：拉新、活躍留存、付費、自傳播優(yōu)先級比重也不同。

啟動需求之前，先問自己，你所負責的產(chǎn)品，當前處在哪個生命周期階段，當季度、當月的項目重點是什么？你可以根據(jù)產(chǎn)品當前的周期，來選定需求的優(yōu)先級，一般可將需求分為4類：P0.重要且緊急，P1.重要不緊急，P0-P1.緊急不重要（性價比高的可提至P0），P2.不緊急且不重要。跟進產(chǎn)品當前重點需要解決的問題，來確定產(chǎn)品研發(fā)方向，以及當前需啟動的需求。

第 2 問：如何做需求過濾，形成需求池？

大部分關(guān)于產(chǎn)品經(jīng)理的文章，都在寫此部分內(nèi)容，一般都會問：用戶是誰，需求目的是什么，滿足用戶哪方面訴求或心理需求，比如：懶得、虛榮、貪婪等……最常引用的是《馬斯洛五大需求理論》，但大部分都說的比較虛。

我個人認為，一個產(chǎn)品面向的用戶群是相對固定的時候，不需要花太多時間在問用戶是誰，用戶有什么特性。這一點上，我挺認同張小龍的理論（雖然他不一定說過），一個真正好的產(chǎn)品，無論用戶是誰，都會用的順手，都覺得好用。在產(chǎn)品設(shè)計過程中，特別是APP類的設(shè)計，功能的簡潔，大氣，操作普適性，我會比較認同。當然，在界面設(shè)計上做的有個性不能說是錯，但個性不等于花哨，也不等于流程隱晦繁瑣。

在過濾需求時，除了問需求目的之外，結(jié)合階段目標，研發(fā)性價比也是非常重要的。來自用戶反饋的過于具體的需求，需要多思考有沒有更好的路徑來達到用戶訴求。例如，游戲公會會長，想在游戲過程中，也可以及時審批會員申請，因此提出希望游戲過程中，可暫時返回到管理頁面進行操作。這個需求看似合理，但其實經(jīng)過簡單評估后，會發(fā)現(xiàn)，研發(fā)成本非常高，且會長離開游戲房間后，需考慮一系列如自動操作、超時托管等處理，且若會長長時間不回來，是否會對一起游戲的對手造成不好的體驗等等，都是需要考慮的點。因此，需要發(fā)散考慮是否有更好的辦法來實現(xiàn)會長的這個訴求，比如說，可以增加副會長來協(xié)助會長管理，或在游戲中增加快捷操作入口，都是可以考慮的方案。滿足需求的方式不止一種，要權(quán)衡性價比和功能可能造成的后果，來決策。

有時候，因為競品做了某些功能，無論是團隊抑或是boss都會有想要快速跟上競品的想法，最終需求會落到產(chǎn)品經(jīng)理手上。對于此類需求，我個人比較不建議照搬競品功能。原因有2：

1、你與競品的用戶群屬性、產(chǎn)品周期、運營模式必定有差異，照搬很大可能會水土不服；

2、每一個產(chǎn)品、功能肯定都有做的好的地方和做的不好的的地方，學(xué)其精華去其糟粕才是王道。習(xí)慣于抄襲，不是什么好事。產(chǎn)品需要有自己的調(diào)性，哪怕只是微創(chuàng)新。

第 3 問：產(chǎn)品規(guī)劃怎么做？大需求如何進行版本拆解？要小步快跑嗎？

對于產(chǎn)品規(guī)劃來說，有一個清晰的階段目標以及明確的deline非常重要，這樣整個團隊的士氣才能被鼓舞起來。有了目標之后，版本拆解也很重要，2到3周是一個比較合適的迭代周期。需求文檔需在研發(fā)前2-4周確定好，并進入美術(shù)設(shè)計階段。

研發(fā)層面，一個迭代一周開發(fā)，一周聯(lián)調(diào)并進入測試，在測試階段，可開始下個迭代需求評審，評審之后，需要預(yù)留一個方案調(diào)整的時間。尤其是對于技術(shù)實力不夠強大的團隊，產(chǎn)品在某些時候，需要更多的考慮技術(shù)實現(xiàn)成本問題。當然，哪些東西可調(diào)整，哪些要堅持原則，這個點本文后面會詳細講解。

每個版本內(nèi)容包括：新功能+基礎(chǔ)功能+小優(yōu)化點+BUG修復(fù)（緊急BUG會獨立安排人力及時解決，不會排入常規(guī)迭代），這樣來保證產(chǎn)品整體迭代的均衡，不至于每天都在救火。

第 4 問：如何提升團隊效率？如何把更多時間花在產(chǎn)品設(shè)計上而不是跟進執(zhí)行上？

在給建議之前，我想說一下自己的一個研發(fā)團隊。我的上一任產(chǎn)品在交接時，跟我說，恭喜你，要入坑了。確實，用坑來形容，不為過。市場同事的評價很中肯：功能做完上線，完全不是我們想要的功能，用戶不會用，還把其他功能搞出一大堆BUG，然后又花了幾天回退。搞了兩個月，啥都沒搞成。確實，我接手后的第一感覺就是：亂。無論是產(chǎn)品邏輯、還是團隊管理，都非常亂。在爆BUG前，沒有人知道風(fēng)險點，也沒有提前預(yù)防；整個研發(fā)團隊每個人每天都忙于應(yīng)付線上不斷復(fù)發(fā)的BUG，像熱鍋上的螞蟻，但研發(fā)效率極低，且質(zhì)量不穩(wěn)定。

我們通過一個季度的不斷嘗試和總結(jié)，摸索到幾個比較有效的辦法，讓整個產(chǎn)品、研發(fā)團隊的效率和質(zhì)量得到提升：

1、信息高效互通，對應(yīng)負責人及時反饋：采用石墨共享《需求收集表》、《BUG反饋表》、《版本規(guī)劃表》。表格作為整個團隊信息互通的橋梁，包括：市場、運營、產(chǎn)品、研發(fā)等都可以隨時查看，每個人清楚我們當前還有多少BUG要解決，有多少需求待開發(fā)，市場的聲音怎么樣，每個需求的優(yōu)先級，以及后續(xù)需求規(guī)劃。

《需求收集表》、《BUG反饋表》：所有人均可在需求收集表、BUG跟進表表格中填寫自己的需求，和發(fā)現(xiàn)的BUG或體驗問題，產(chǎn)品經(jīng)理需每天查看表格，并備注每項需求、BUG的處理意見和進度。研發(fā)同事在保證完成自己分內(nèi)工作后，可自行認領(lǐng)想挑戰(zhàn)解決的陳年BUG（重要不緊急），并計入績效貢獻?！栋姹疽?guī)劃表》則由產(chǎn)品負責人來按周更新，我們一般要求產(chǎn)品負責人提前兩個月以上做好品規(guī)劃，拆解成季度、月度、周的計劃。在每個月最后一周，集中收集并確定下個月版本研發(fā)內(nèi)容，并事先同步給全員。所有團隊成員可直接查看最近一個月至一季度的需求規(guī)劃情況，可提前準備或預(yù)研。

2、強化開發(fā)者的全局思考能力，無論是團隊成員自發(fā)組織體驗產(chǎn)品，還是嚴格要求技術(shù)評審時每人都需要提問，都讓研發(fā)人員更熟悉產(chǎn)品需求。讓研發(fā)團隊的每個人都了解到產(chǎn)品全局的設(shè)計框架，也多了解其他人做的模塊，同時整個團隊對階段目標、產(chǎn)品現(xiàn)有全局功能邏輯有透徹了解。逐步提升研發(fā)人員的全局框架思維能力和產(chǎn)品思維能力。做到提前預(yù)防，而不是出了BUG再來救火，也避免很多低能的BUG出現(xiàn)。

3、提高每個團隊成員的owner心態(tài)，并配合及時獎勵機。每周研發(fā)組周會每人發(fā)言自己所發(fā)現(xiàn)的問題，簡單輕松，無所不談，同時設(shè)置月度研發(fā)標兵獎勵，對于有貢獻的同事進行及時鼓勵。事實證明，簡單的獎勵效果明顯，團隊上進心不斷被激發(fā)，甩鍋心態(tài)也漸漸被消除。

第 5 問：如何減少方案返工，提高方案合理性？

首先，在開始輸出需求方案之前，一定要先回答3個問題：

1、需求方提出這個需求的目的是什么，也就是這個需求為了達到什么效果，你們是否對需求出發(fā)點、需求目的、預(yù)期效果達成共識？你能否預(yù)估需求上線后的數(shù)據(jù)效果？

2、是否有競品已經(jīng)實現(xiàn)了此功能，至少看3個以上競品，且每個競品實現(xiàn)的細節(jié)差異點是什么樣的，他們?yōu)槭裁磿龀刹煌?或相同的樣子？你是否了解競品功能的市場反饋或數(shù)據(jù)？

3、核心流程是否有技術(shù)難點，是否需要提前對可行性進行評估或預(yù)研？核心邏輯選定，需與研發(fā)快速確定可行行、選定最高性價比核心方案，事先全局思考，切忌邊做邊改，做到一半，發(fā)現(xiàn)方案行不通，或者技術(shù)成本過大而放棄。

在方案輸出過程中，建議先做好競品分析，同時提前咨詢研發(fā)人員關(guān)于方案核心流程的可行性以及研發(fā)難度，這樣可以很好的幫助你判斷需求是否拆分版本，如何拆分版本，避免等到需求全部輸出后，在評審會上被徹底推翻。因此，事前溝通非常重要，它能幫助你獲取更多信息，并結(jié)合研發(fā)成本、時間規(guī)劃做出最合理方案。

第 6 問：如何提升方案可用性，易用性？

核心邏輯確定之后，方案的方向和主干基本確定，接下來就是細化方案，輸出文檔。在細化方案的過程中，主要會涉及到功能流程框架，頁面交互設(shè)計、細節(jié)處理等。下面總結(jié)幾個很重要的點，來提升易用性和用戶體驗：

1、把用戶假設(shè)成一個聰明但是很忙的人，不要指望讓用戶記住任何操作流程，而是隨時提供清晰的指引和盡可能自由的頁面跳轉(zhuǎn)入口。

2、用戶的高頻操作，應(yīng)盡量減少操作步驟，而低頻操作，則無需刻意關(guān)注步驟數(shù)，更應(yīng)該關(guān)注的是每一步的操作難度和界面信息是否易于理解。應(yīng)盡量降低選擇難度，別讓用戶花時間去理解。

3、一個頁面只突出一個重點，用大小，顏色，形狀來做分類，讓用戶一眼可分辨到重要信息。

4、扁平化和漸進披露相結(jié)合，視場景而定，而不是機械化執(zhí)行扁平化。流程扁平化的好處是，可以讓用戶提前感知流程，頁面跳轉(zhuǎn)的成本也比較低，但是比較考驗對頁面信息的整合處理，漸進披露是預(yù)先把次要信息隱藏，當用戶觸發(fā)了對應(yīng)操作，進入對應(yīng)流程，才給出相應(yīng)反饋或指引，好處是讓用戶更專注，減少理解成本。

5、頁面一致性也是這個道理，就我理解，一致性的是為了讓用戶形成習(xí)慣，進而減少理解成本。比如，確定操作永遠在右側(cè)，選中狀態(tài)永遠高亮，紅色代表嚴重警告等等。當用戶已經(jīng)形成統(tǒng)一認知，則會大大降低每一次操作的理解成本。但有時候設(shè)計師會過于信仰一致性，導(dǎo)致失去個性，我建議在不影響習(xí)慣的前提下，可適時打破所謂一致性的束縛，讓設(shè)計更加出彩。

6、讓用戶有反悔機會。誤操作后，可恢復(fù)，且重要操作需二次確認，并強化感知嚴重性。

7、避免依賴文字說明，多用圖形化的方式讓用戶直接感知，而不是通過理解文字來感知。且文案使用的格式、主語建議統(tǒng)一，這有助于營造整體調(diào)性。另外一點，即按鈕文案的使用，建議明確告訴用戶該頁面的目的和功能，同時引導(dǎo)行為，而不是陳述性文案。用動詞+賓語的格式來引導(dǎo)用戶操作，如：“去購買”比“商城”更清楚，“去玩牌”比“游戲”更清楚。

8、需同時考慮多平臺的用戶操作習(xí)慣，如ios系統(tǒng)上的應(yīng)用，頁面需提供返回按鈕，而安卓上的應(yīng)用，按鈕應(yīng)避免過于靠近手機底部操作欄，以防誤操作。

第 7 問：如何讓策劃文檔更清晰易讀？

1、在開始描述詳細功能點之前，先說明該功能的核心功能邏輯，讓讀者先了解整個文檔核心。可借助腦圖（xmind）、表格（excle）、邏輯圖來輔助描述；

2、交互流程圖（axure）：將每個關(guān)鍵流程統(tǒng)一展示在一張交互圖上，并注解重點交互細節(jié)及規(guī)則，這樣讀者可以直觀感知頁面跳轉(zhuǎn)邏輯以及判斷邏輯，可以極大提升評審效率；

3、描述功能時，分模塊來劃分文檔會是比較好的做法，可避免重復(fù)。

第 8 問：需求文檔中，除了功能流程外，還需要考慮哪些內(nèi)容？

需考慮極限情況和異常情況處理：

1、列表為空情況處理，網(wǎng)絡(luò)異常拉取失敗處理，進行中強退考慮斷線重連、進行中強退后如何處理玩家進度；

2、數(shù)據(jù)超上限規(guī)則：保存數(shù)量上限、保存周期上限、分頁條數(shù)數(shù)量；

3、完整的編輯權(quán)限需具備：增、刪、改、查；

4、重連次數(shù)以及如何觸發(fā)重連：若進行3次重連嘗試依然失敗后，顯示重連按鈕，讓玩家手動觸發(fā)刷新；后臺推送失敗如獎勵發(fā)放，推送失敗，需讓玩家可以手動觸發(fā)領(lǐng)獎的地方；

5、加載頻率考慮：是否需要預(yù)加載，或者進入頁面時才加載，會影響到切換速度；

6、切后臺、斷網(wǎng)、玩家頻繁切到微信的場景，會造成APP短暫收不到正常數(shù)據(jù)推送。要考慮頁面數(shù)據(jù)是否會延遲，是否需真實刷新，或自動觸發(fā)刷新。

7、發(fā)放獎勵需考慮防刷機制，要做到即使出現(xiàn)功能BUG，系統(tǒng)也會在達到閾值時，自動預(yù)警或直接熔斷。防刷規(guī)則可簡單分為：

• 周期內(nèi)（每天、每小時、每分鐘、每秒）發(fā)放次數(shù)、額度上限閾值限制；
• 周期內(nèi)（每天、每小時、每分鐘、每秒）用戶行為（注冊、獲獎）頻率上限閾值限制。

8、完整的需求文檔，需配備配置后臺以及數(shù)據(jù)埋點需求，在功能上線后，可持續(xù)監(jiān)控跟蹤數(shù)據(jù)表現(xiàn)，進而分析效果以及迭代優(yōu)化方向。

總結(jié)

1、明確需求目的：拉新、活躍、留存、付費、體驗、逼格調(diào)性……開始需求輸出前，需提煉，過濾需求，避免機械照搬競品功能；

2、明確核心邏輯并先與研發(fā)商定可行性、性價比，若性價比過低，需快速調(diào)整方案，同時，輸出完整方案時，需完善考慮異常處理、防錯設(shè)計等細節(jié)，做到“帶腦子”做事；

3、確保研發(fā)人員對需求理解透徹，且能從全局角度設(shè)計技術(shù)方案，需求描述越清晰，越細致，研發(fā)效率越高；

4、大功能分迭代，分版本做，第一步先實現(xiàn)核心功能閉環(huán)，上線驗證并收集反饋，再啟動附加功能開發(fā)。