需求調研和用戶場景分析

產品經理在獲取到需求/產生需求后，首先且一定要做需求調研，了解需求背景，以明確需求的目的。目的不同，解決方案完全不同。需求調研是確定目的的方式。
調研方法有定性調研和定量調研，主要方式有：用戶訪談、無領導小組、問卷調查等。具體采用哪種方法，根據需求來源、公司資源等具體決定。需求調研的宗旨是：從用戶中來，到用戶中去。
調研完成后，用戶場景分析也是必不可少的。假設自己是真實用戶進行“拍電影”，“拍電影”時我們很容易會本能地跳過一些細節(jié)或需要思考的環(huán)節(jié)，跳過的環(huán)節(jié)有可能會影響產品方案的可行性，所以務必不要跳過任何一個環(huán)節(jié)。王興（人人網創(chuàng)始人、飯否網總裁、美團網創(chuàng)始人兼總裁）說：大多數(shù)人為了逃避真正的思考，愿意做任何事。與君共勉。

競品分析

競品分析是為了了解市場上同類產品，取長補短，找到自己的亮點和切入點。
首先要明確“這份報告為什么做？這份報告給誰看？”，才能知道該輸入什么內容。
競品分析的常用方法有：SWOT、用戶五要素（戰(zhàn)略層、范圍層、結構層、框架層、視覺層）分析法、評分法、yes/no法、四象限分析法、base+solution分析法、kanno模型分析法。關于這些分析方法已經很很多文章去闡述了。

分析和篩選需求

用四象限的方法去篩選需求
1、匹配產品定位（目標用戶，價值主張）
2、考慮實現(xiàn)成本和收益
3、最小化的可用性測試

產品方案

產品方案推薦的展現(xiàn)方式是思維導圖。
將背景和目的列入導圖中，防止自己忘記了“初衷”。導圖要做到MECE原則“相互獨立，完全窮盡”，維度單一且統(tǒng)一。方案確定后，再去check目的是否達成。
最后，你需要找兩類人去驗證自己的方案：產品人；（類）用戶。

需求原型

每個元素都要考慮：為什么放？有沒有意義？使用場景是什么？（拍電影通過場景進行驗證）不確定的不放（MVP）。
產品設計要從熟悉用戶、場景開始
產品在做原型設計前，要先熟悉用戶、熟悉用戶使用場景。
熟悉用戶，就是產品上定義的用戶畫像，要把焦點關注在目標用戶的動機和行為上進行設計，要拋開個人喜好。例如我在做成績管理的產品設計時，就忽略了用戶畫像，我設計的操作流程是自己熟悉的流程，而用戶在使用時多處出現(xiàn)了迷茫感，不知該如何操作。
熟悉用戶使用場景，不僅要熟悉正常的使用場景，還包括很多異常場景。產品設計過于理想化，就會忽略異常情況，這樣就導致用戶在遇到異常時得不到很好的引導。例如在成績報告單的需求中，導入素質數(shù)據時應該校驗科目成績的錄入情況并給出提示的，考慮到不同年級的科目不同、是定制需求、且可以線下對用戶做要求，最后就去掉此校驗了。實際結果是用戶并不會記住線下的要求，很多班主任早早就把素質數(shù)據導進去，發(fā)現(xiàn)報告中很多科目成績沒有數(shù)據，因此都拋出了疑問。
除了傻子都會用的操作，請不要吝嗇地給引導
在沒有外部施壓、或沒有明確知道能給自己帶來什么好處的情況下，用戶是不愿意花費自己的學習成本去研究、了解具體操作流程的。所以不要高估用戶，在用戶可能會產生困惑的地方，給到足夠的引導。
引導的方式不能僅局限于線下，例如我這次將操作指南給了周主任，然而他并沒有完全傳達給老師，或者在群里上傳了文件，很多老師沒有看，想看的時候又找不到。線下提供的操作指南，無法保證指南的普及度，所以最好是有固定查看/下載的址，形式不限于文檔、視頻等。

詳細需求

詳細需求很多異常流沒考慮，認為是極端場景，實際在用戶使用率比較高的時候，異常流出現(xiàn)的概率很高。所以詳細需求要盡所能的周詳。
個人總結的詳細需求中容易遺漏的點，用以check，具體如下：

列表是否有分頁、每頁多少行
列表排列方式，多字段排列的情況
內容顯示不全，是否提供title
表單的重名校驗
表單中輸入的字符長度限制
表單中輸入的字符空格如何處理
提交表單時，校驗表單狀態(tài)（是不是在其它瀏覽器已經提交過）
操作沒有數(shù)據的對象時，要給提示，引導用戶怎么辦
下載模板的文件命名
描述數(shù)據元素時，取自服務器的數(shù)據，一定描述清楚是取有業(yè)務數(shù)據的還是不判斷是否有業(yè)務數(shù)據
明確錯誤提示的方式（浮層提示還是彈框提示），以及錯誤提示所在頁面
是否允許重復操作，若允許，重復操作是替換還是補充？
一條數(shù)據，在兩個瀏覽器打開，在其中一個瀏覽器刪除，在另一個瀏覽器進行操作，是否有提示？怎么處理？
如果可以，提供給開發(fā)/測試真實的用戶數(shù)據作為開發(fā)、測試的參考