本文主要內(nèi)容是關(guān)于互聯(lián)網(wǎng)產(chǎn)品策劃過程中的設(shè)計(jì)方法總結(jié)，是我這幾年實(shí)戰(zhàn)留下了的些許心得，通過問答的形式，來說明產(chǎn)品設(shè)計(jì)和項(xiàng)目過程中需注意的問題，可作為自檢思考工具。包括內(nèi)容：需求分析、文檔輸出、體驗(yàn)細(xì)節(jié)優(yōu)化、異常防錯(cuò)處理等。
第 1 問：需求優(yōu)先級(jí)應(yīng)該如何排布？接下來應(yīng)該優(yōu)先啟動(dòng)哪個(gè)需求？
根據(jù)美國(guó)哈佛大學(xué)教授雷蒙德·弗農(nóng)(Raymond Vernon)的《產(chǎn)品生命周》理論，產(chǎn)品周期可分為：導(dǎo)入期--成長(zhǎng)期--成熟期--衰退期?；ヂ?lián)網(wǎng)產(chǎn)品在這個(gè)四個(gè)階段，對(duì)應(yīng)的產(chǎn)品規(guī)劃重點(diǎn)：拉新、活躍留存、付費(fèi)、自傳播優(yōu)先級(jí)比重也不同。
啟動(dòng)需求之前，先問自己，你所負(fù)責(zé)的產(chǎn)品，當(dāng)前處在哪個(gè)生命周期階段，當(dāng)季度、當(dāng)月的項(xiàng)目重點(diǎn)是什么？你可以根據(jù)產(chǎn)品當(dāng)前的周期，來選定需求的優(yōu)先級(jí)，一般可將需求分為4類：P0.重要且緊急，P1.重要不緊急，P0-P1.緊急不重要（性價(jià)比高的可提至P0），P2.不緊急且不重要。跟進(jìn)產(chǎn)品當(dāng)前重點(diǎn)需要解決的問題，來確定產(chǎn)品研發(fā)方向，以及當(dāng)前需啟動(dòng)的需求。
第 2 問：如何做需求過濾，形成需求池？
大部分關(guān)于產(chǎn)品經(jīng)理的文章，都在寫此部分內(nèi)容，一般都會(huì)問：用戶是誰，需求目的是什么，滿足用戶哪方面訴求或心理需求，比如：懶得、虛榮、貪婪等……最常引用的是《馬斯洛五大需求理論》，但大部分都說的比較虛。
我個(gè)人認(rèn)為，一個(gè)產(chǎn)品面向的用戶群是相對(duì)固定的時(shí)候，不需要花太多時(shí)間在問用戶是誰，用戶有什么特性。這一點(diǎn)上，我挺認(rèn)同張小龍的理論（雖然他不一定說過），一個(gè)真正好的產(chǎn)品，無論用戶是誰，都會(huì)用的順手，都覺得好用。在產(chǎn)品設(shè)計(jì)過程中，特別是APP類的設(shè)計(jì)，功能的簡(jiǎn)潔，大氣，操作普適性，我會(huì)比較認(rèn)同。當(dāng)然，在界面設(shè)計(jì)上做的有個(gè)性不能說是錯(cuò)，但個(gè)性不等于花哨，也不等于流程隱晦繁瑣。
在過濾需求時(shí)，除了問需求目的之外，結(jié)合階段目標(biāo)，研發(fā)性價(jià)比也是非常重要的。來自用戶反饋的過于具體的需求，需要多思考有沒有更好的路徑來達(dá)到用戶訴求。例如，游戲公會(huì)會(huì)長(zhǎng)，想在游戲過程中，也可以及時(shí)審批會(huì)員申請(qǐng)，因此提出希望游戲過程中，可暫時(shí)返回到管理頁面進(jìn)行操作。這個(gè)需求看似合理，但其實(shí)經(jīng)過簡(jiǎn)單評(píng)估后，會(huì)發(fā)現(xiàn)，研發(fā)成本非常高，且會(huì)長(zhǎng)離開游戲房間后，需考慮一系列如自動(dòng)操作、超時(shí)托管等處理，且若會(huì)長(zhǎng)長(zhǎng)時(shí)間不回來，是否會(huì)對(duì)一起游戲的對(duì)手造成不好的體驗(yàn)等等，都是需要考慮的點(diǎn)。因此，需要發(fā)散考慮是否有更好的辦法來實(shí)現(xiàn)會(huì)長(zhǎng)的這個(gè)訴求，比如說，可以增加副會(huì)長(zhǎng)來協(xié)助會(huì)長(zhǎng)管理，或在游戲中增加快捷操作入口，都是可以考慮的方案。滿足需求的方式不止一種，要權(quán)衡性價(jià)比和功能可能造成的后果，來決策。
有時(shí)候，因?yàn)楦?jìng)品做了某些功能，無論是團(tuán)隊(duì)抑或是boss都會(huì)有想要快速跟上競(jìng)品的想法，最終需求會(huì)落到產(chǎn)品經(jīng)理手上。對(duì)于此類需求，我個(gè)人比較不建議照搬競(jìng)品功能。原因有2：
1、你與競(jìng)品的用戶群屬性、產(chǎn)品周期、運(yùn)營(yíng)模式必定有差異，照搬很大可能會(huì)水土不服；
2、每一個(gè)產(chǎn)品、功能肯定都有做的好的地方和做的不好的的地方，學(xué)其精華去其糟粕才是王道。習(xí)慣于抄襲，不是什么好事。產(chǎn)品需要有自己的調(diào)性，哪怕只是微創(chuàng)新。
第 3 問：產(chǎn)品規(guī)劃怎么做？大需求如何進(jìn)行版本拆解？要小步快跑嗎？
對(duì)于產(chǎn)品規(guī)劃來說，有一個(gè)清晰的階段目標(biāo)以及明確的deline非常重要，這樣整個(gè)團(tuán)隊(duì)的士氣才能被鼓舞起來。有了目標(biāo)之后，版本拆解也很重要，2到3周是一個(gè)比較合適的迭代周期。需求文檔需在研發(fā)前2-4周確定好，并進(jìn)入美術(shù)設(shè)計(jì)階段。
研發(fā)層面，一個(gè)迭代一周開發(fā)，一周聯(lián)調(diào)并進(jìn)入測(cè)試，在測(cè)試階段，可開始下個(gè)迭代需求評(píng)審，評(píng)審之后，需要預(yù)留一個(gè)方案調(diào)整的時(shí)間。尤其是對(duì)于技術(shù)實(shí)力不夠強(qiáng)大的團(tuán)隊(duì)，產(chǎn)品在某些時(shí)候，需要更多的考慮技術(shù)實(shí)現(xiàn)成本問題。當(dāng)然，哪些東西可調(diào)整，哪些要堅(jiān)持原則，這個(gè)點(diǎn)本文后面會(huì)詳細(xì)講解。
每個(gè)版本內(nèi)容包括：新功能+基礎(chǔ)功能+小優(yōu)化點(diǎn)+BUG修復(fù)（緊急BUG會(huì)獨(dú)立安排人力及時(shí)解決，不會(huì)排入常規(guī)迭代），這樣來保證產(chǎn)品整體迭代的均衡，不至于每天都在救火。
第 4 問：如何提升團(tuán)隊(duì)效率？如何把更多時(shí)間花在產(chǎn)品設(shè)計(jì)上而不是跟進(jìn)執(zhí)行上？
在給建議之前，我想說一下自己的一個(gè)研發(fā)團(tuán)隊(duì)。我的上一任產(chǎn)品在交接時(shí)，跟我說，恭喜你，要入坑了。確實(shí)，用坑來形容，不為過。市場(chǎng)同事的評(píng)價(jià)很中肯：功能做完上線，完全不是我們想要的功能，用戶不會(huì)用，還把其他功能搞出一大堆BUG，然后又花了幾天回退。搞了兩個(gè)月，啥都沒搞成。確實(shí)，我接手后的第一感覺就是：亂。無論是產(chǎn)品邏輯、還是團(tuán)隊(duì)管理，都非常亂。在爆BUG前，沒有人知道風(fēng)險(xiǎn)點(diǎn)，也沒有提前預(yù)防；整個(gè)研發(fā)團(tuán)隊(duì)每個(gè)人每天都忙于應(yīng)付線上不斷復(fù)發(fā)的BUG，像熱鍋上的螞蟻，但研發(fā)效率極低，且質(zhì)量不穩(wěn)定。
我們通過一個(gè)季度的不斷嘗試和總結(jié)，摸索到幾個(gè)比較有效的辦法，讓整個(gè)產(chǎn)品、研發(fā)團(tuán)隊(duì)的效率和質(zhì)量得到提升：
1、信息高效互通，對(duì)應(yīng)負(fù)責(zé)人及時(shí)反饋：采用石墨共享《需求收集表》、《BUG反饋表》、《版本規(guī)劃表》。表格作為整個(gè)團(tuán)隊(duì)信息互通的橋梁，包括：市場(chǎng)、運(yùn)營(yíng)、產(chǎn)品、研發(fā)等都可以隨時(shí)查看，每個(gè)人清楚我們當(dāng)前還有多少BUG要解決，有多少需求待開發(fā)，市場(chǎng)的聲音怎么樣，每個(gè)需求的優(yōu)先級(jí)，以及后續(xù)需求規(guī)劃。
《需求收集表》、《BUG反饋表》：所有人均可在需求收集表、BUG跟進(jìn)表表格中填寫自己的需求，和發(fā)現(xiàn)的BUG或體驗(yàn)問題，產(chǎn)品經(jīng)理需每天查看表格，并備注每項(xiàng)需求、BUG的處理意見和進(jìn)度。研發(fā)同事在保證完成自己分內(nèi)工作后，可自行認(rèn)領(lǐng)想挑戰(zhàn)解決的陳年BUG（重要不緊急），并計(jì)入績(jī)效貢獻(xiàn)?！栋姹疽?guī)劃表》則由產(chǎn)品負(fù)責(zé)人來按周更新，我們一般要求產(chǎn)品負(fù)責(zé)人提前兩個(gè)月以上做好品規(guī)劃，拆解成季度、月度、周的計(jì)劃。在每個(gè)月最后一周，集中收集并確定下個(gè)月版本研發(fā)內(nèi)容，并事先同步給全員。所有團(tuán)隊(duì)成員可直接查看最近一個(gè)月至一季度的需求規(guī)劃情況，可提前準(zhǔn)備或預(yù)研。
2、強(qiáng)化開發(fā)者的全局思考能力，無論是團(tuán)隊(duì)成員自發(fā)組織體驗(yàn)產(chǎn)品，還是嚴(yán)格要求技術(shù)評(píng)審時(shí)每人都需要提問，都讓研發(fā)人員更熟悉產(chǎn)品需求。讓研發(fā)團(tuán)隊(duì)的每個(gè)人都了解到產(chǎn)品全局的設(shè)計(jì)框架，也多了解其他人做的模塊，同時(shí)整個(gè)團(tuán)隊(duì)對(duì)階段目標(biāo)、產(chǎn)品現(xiàn)有全局功能邏輯有透徹了解。逐步提升研發(fā)人員的全局框架思維能力和產(chǎn)品思維能力。做到提前預(yù)防，而不是出了BUG再來救火，也避免很多低能的BUG出現(xiàn)。
3、提高每個(gè)團(tuán)隊(duì)成員的owner心態(tài)，并配合及時(shí)獎(jiǎng)勵(lì)機(jī)。每周研發(fā)組周會(huì)每人發(fā)言自己所發(fā)現(xiàn)的問題，簡(jiǎn)單輕松，無所不談，同時(shí)設(shè)置月度研發(fā)標(biāo)兵獎(jiǎng)勵(lì)，對(duì)于有貢獻(xiàn)的同事進(jìn)行及時(shí)鼓勵(lì)。事實(shí)證明，簡(jiǎn)單的獎(jiǎng)勵(lì)效果明顯，團(tuán)隊(duì)上進(jìn)心不斷被激發(fā)，甩鍋心態(tài)也漸漸被消除。
第 5 問：如何減少方案返工，提高方案合理性？
首先，在開始輸出需求方案之前，一定要先回答3個(gè)問題：
1、需求方提出這個(gè)需求的目的是什么，也就是這個(gè)需求為了達(dá)到什么效果，你們是否對(duì)需求出發(fā)點(diǎn)、需求目的、預(yù)期效果達(dá)成共識(shí)？你能否預(yù)估需求上線后的數(shù)據(jù)效果？
2、是否有競(jìng)品已經(jīng)實(shí)現(xiàn)了此功能，至少看3個(gè)以上競(jìng)品，且每個(gè)競(jìng)品實(shí)現(xiàn)的細(xì)節(jié)差異點(diǎn)是什么樣的，他們?yōu)槭裁磿?huì)做成不同/或相同的樣子？你是否了解競(jìng)品功能的市場(chǎng)反饋或數(shù)據(jù)？
3、核心流程是否有技術(shù)難點(diǎn)，是否需要提前對(duì)可行性進(jìn)行評(píng)估或預(yù)研？核心邏輯選定，需與研發(fā)快速確定可行行、選定最高性價(jià)比核心方案，事先全局思考，切忌邊做邊改，做到一半，發(fā)現(xiàn)方案行不通，或者技術(shù)成本過大而放棄。
在方案輸出過程中，建議先做好競(jìng)品分析，同時(shí)提前咨詢研發(fā)人員關(guān)于方案核心流程的可行性以及研發(fā)難度，這樣可以很好的幫助你判斷需求是否拆分版本，如何拆分版本，避免等到需求全部輸出后，在評(píng)審會(huì)上被徹底推翻。因此，事前溝通非常重要，它能幫助你獲取更多信息，并結(jié)合研發(fā)成本、時(shí)間規(guī)劃做出最合理方案。
第 6 問：如何提升方案可用性，易用性？
核心邏輯確定之后，方案的方向和主干基本確定，接下來就是細(xì)化方案，輸出文檔。在細(xì)化方案的過程中，主要會(huì)涉及到功能流程框架，頁面交互設(shè)計(jì)、細(xì)節(jié)處理等。下面總結(jié)幾個(gè)很重要的點(diǎn)，來提升易用性和用戶體驗(yàn)：
1、把用戶假設(shè)成一個(gè)聰明但是很忙的人，不要指望讓用戶記住任何操作流程，而是隨時(shí)提供清晰的指引和盡可能自由的頁面跳轉(zhuǎn)入口。
2、用戶的高頻操作，應(yīng)盡量減少操作步驟，而低頻操作，則無需刻意關(guān)注步驟數(shù)，更應(yīng)該關(guān)注的是每一步的操作難度和界面信息是否易于理解。應(yīng)盡量降低選擇難度，別讓用戶花時(shí)間去理解。
3、一個(gè)頁面只突出一個(gè)重點(diǎn)，用大小，顏色，形狀來做分類，讓用戶一眼可分辨到重要信息。
4、扁平化和漸進(jìn)披露相結(jié)合，視場(chǎng)景而定，而不是機(jī)械化執(zhí)行扁平化。流程扁平化的好處是，可以讓用戶提前感知流程，頁面跳轉(zhuǎn)的成本也比較低，但是比較考驗(yàn)對(duì)頁面信息的整合處理，漸進(jìn)披露是預(yù)先把次要信息隱藏，當(dāng)用戶觸發(fā)了對(duì)應(yīng)操作，進(jìn)入對(duì)應(yīng)流程，才給出相應(yīng)反饋或指引，好處是讓用戶更專注，減少理解成本。
5、頁面一致性也是這個(gè)道理，就我理解，一致性的是為了讓用戶形成習(xí)慣，進(jìn)而減少理解成本。比如，確定操作永遠(yuǎn)在右側(cè)，選中狀態(tài)永遠(yuǎn)高亮，紅色代表嚴(yán)重警告等等。當(dāng)用戶已經(jīng)形成統(tǒng)一認(rèn)知，則會(huì)大大降低每一次操作的理解成本。但有時(shí)候設(shè)計(jì)師會(huì)過于信仰一致性，導(dǎo)致失去個(gè)性，我建議在不影響習(xí)慣的前提下，可適時(shí)打破所謂一致性的束縛，讓設(shè)計(jì)更加出彩。
6、讓用戶有反悔機(jī)會(huì)。誤操作后，可恢復(fù)，且重要操作需二次確認(rèn)，并強(qiáng)化感知嚴(yán)重性。
7、避免依賴文字說明，多用圖形化的方式讓用戶直接感知，而不是通過理解文字來感知。且文案使用的格式、主語建議統(tǒng)一，這有助于營(yíng)造整體調(diào)性。另外一點(diǎn)，即按鈕文案的使用，建議明確告訴用戶該頁面的目的和功能，同時(shí)引導(dǎo)行為，而不是陳述性文案。用動(dòng)詞+賓語的格式來引導(dǎo)用戶操作，如：“去購買”比“商城”更清楚，“去玩牌”比“游戲”更清楚。
8、需同時(shí)考慮多平臺(tái)的用戶操作習(xí)慣，如ios系統(tǒng)上的應(yīng)用，頁面需提供返回按鈕，而安卓上的應(yīng)用，按鈕應(yīng)避免過于靠近手機(jī)底部操作欄，以防誤操作。
第 7 問：如何讓策劃文檔更清晰易讀？
1、在開始描述詳細(xì)功能點(diǎn)之前，先說明該功能的核心功能邏輯，讓讀者先了解整個(gè)文檔核心。可借助腦圖（xmind）、表格（excle）、邏輯圖來輔助描述；
2、交互流程圖（axure）：將每個(gè)關(guān)鍵流程統(tǒng)一展示在一張交互圖上，并注解重點(diǎn)交互細(xì)節(jié)及規(guī)則，這樣讀者可以直觀感知頁面跳轉(zhuǎn)邏輯以及判斷邏輯，可以極大提升評(píng)審效率；
3、描述功能時(shí)，分模塊來劃分文檔會(huì)是比較好的做法，可避免重復(fù)。
第 8 問：需求文檔中，除了功能流程外，還需要考慮哪些內(nèi)容？
需考慮極限情況和異常情況處理：
1、列表為空情況處理，網(wǎng)絡(luò)異常拉取失敗處理，進(jìn)行中強(qiáng)退考慮斷線重連、進(jìn)行中強(qiáng)退后如何處理玩家進(jìn)度；
2、數(shù)據(jù)超上限規(guī)則：保存數(shù)量上限、保存周期上限、分頁條數(shù)數(shù)量；
3、完整的編輯權(quán)限需具備：增、刪、改、查；
4、重連次數(shù)以及如何觸發(fā)重連：若進(jìn)行3次重連嘗試依然失敗后，顯示重連按鈕，讓玩家手動(dòng)觸發(fā)刷新；后臺(tái)推送失敗如獎(jiǎng)勵(lì)發(fā)放，推送失敗，需讓玩家可以手動(dòng)觸發(fā)領(lǐng)獎(jiǎng)的地方；
5、加載頻率考慮：是否需要預(yù)加載，或者進(jìn)入頁面時(shí)才加載，會(huì)影響到切換速度；
6、切后臺(tái)、斷網(wǎng)、玩家頻繁切到微信的場(chǎng)景，會(huì)造成APP短暫收不到正常數(shù)據(jù)推送。要考慮頁面數(shù)據(jù)是否會(huì)延遲，是否需真實(shí)刷新，或自動(dòng)觸發(fā)刷新。
7、發(fā)放獎(jiǎng)勵(lì)需考慮防刷機(jī)制，要做到即使出現(xiàn)功能BUG，系統(tǒng)也會(huì)在達(dá)到閾值時(shí)，自動(dòng)預(yù)警或直接熔斷。防刷規(guī)則可簡(jiǎn)單分為：
a.周期內(nèi)（每天、每小時(shí)、每分鐘、每秒）發(fā)放次數(shù)、額度上限閾值限制；
b.周期內(nèi)（每天、每小時(shí)、每分鐘、每秒）用戶行為（注冊(cè)、獲獎(jiǎng)）頻率上限閾值限制。
8、完整的需求文檔，需配備配置后臺(tái)以及數(shù)據(jù)埋點(diǎn)需求，在功能上線后，可持續(xù)監(jiān)控跟蹤數(shù)據(jù)表現(xiàn)，進(jìn)而分析效果以及迭代優(yōu)化方向。
總結(jié)
1、明確需求目的：拉新、活躍、留存、付費(fèi)、體驗(yàn)、逼格調(diào)性……開始需求輸出前，需提煉，過濾需求，避免機(jī)械照搬競(jìng)品功能；
2、明確核心邏輯并先與研發(fā)商定可行性、性價(jià)比，若性價(jià)比過低，需快速調(diào)整方案，同時(shí)，輸出完整方案時(shí)，需完善考慮異常處理、防錯(cuò)設(shè)計(jì)等細(xì)節(jié)，做到“帶腦子”做事；
3、確保研發(fā)人員對(duì)需求理解透徹，且能從全局角度設(shè)計(jì)技術(shù)方案，需求描述越清晰，越細(xì)致，研發(fā)效率越高；
4、大功能分迭代，分版本做，第一步先實(shí)現(xiàn)核心功能閉環(huán)，上線驗(yàn)證并收集反饋，再啟動(dòng)附加功能開發(fā)。
