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