到了產品設計階段，大部分產品經理（尤其是技術轉型的產品經理）終於可以大大的喘一口氣了，這個階段的工作應該是產品人最最熟悉的環節了。網上關於產品設計（我總覺得這個叫需求分析）的方法論還真是多的很，場景分析法、用户心理學法等等，所以關於產品設計階段的方法，那我來介紹一下場景分析法……等等，不是説非學院派嗎？説好的野路子呢？
既然大家這麼想知道野路子，那我來介紹介紹哥哥的野路子產品設計方法。（我的行文風格是儘量撈乾的説，畢竟程序員出身的我不喜歡寫文檔的。）
我做產品設計的時候是先擴大、後縮減的一個過程，我估計跟大多數產品經理的方法比較相似。還是老規矩，我的野路子不一定適合你，不過給你一個方法上的參考，讓你有一個不同的視角瞭解產品設計過程。
實體分析是的，你沒有看錯，我做產品的第一步是做實體分析（我管這個叫實體分析，別的童鞋可能也做這個工作，但是不這麼叫）。各位童鞋可能要問了，啥叫實體分析，且聽我娓娓道來。
這個實體分析的邏輯是這樣的，我把一個系統中需要管理的對象統一稱之為實體，比如用户就是一個實體，實體分析其實就是你要通過競品分析、客户需求分析、用户需求分析的環節（不知道的話去看看我之前的需求分析階段的文章）搞清楚你的產品要管理啥。這是個很核心的內容，如果你弄不清楚你要管理的對象，產品的根基就沒打穩。
還是老規矩，上例子，我做的實體分析如下：
其實最開始不是這樣的，最開始比較亂，就是我們產品團隊的成員都會去分析要管理的實體，分析完了就把所有人分析的結果整合在一起，然後開始合併同類項，就這樣一步一步的把系統要管理的實體抽象成了這個樣子（研發轉產品的童鞋熟悉不？就是父類、子類的概念，這個第一層就相當於父類了），當然，是不是合理那就仁者見仁智者見智了，只要團隊達成一致就算告一段落了。
有了實體基礎，接下來就要開始往下細分，那就是每一個類型的實體還有哪些，分完了這個信息就包含了所有的實體，還有這些實體都有啥信息，大概是這樣的：
我就不完全展開了，圖片太大，大家看着也一頭霧水。總的來説，這個實體分析的結果是大體形成了三級級樹狀結構（當然也包括更多的層級，三層概括一下吧），包括：實體類（第一層）、實體（第二層）、實體數據項（第三層），這樣，你的產品準備要管些什麼信息你心裏就有譜了是吧。
之後，如果有條件的話，拿着這個要管理的實體去跟你們的客户、用户去聊聊，看看有沒有什麼補充。沒條件就算了，反正我們是沒這個條件。
功能設計實體分析結束後，就該功能設計了。好多產品設計的教程裏面告訴大家上來就直接列功能，我是從來沒成功過，於是我選擇了另外一種方法（野路子來嘍）。
前面不是做過實體分析了嗎？你已經知道你要管啥了，功能設計就是幫助你來捋捋應該怎麼管。
所以我是在實體設計的基礎上來考慮功能設計的，功能設計結果如下：
大家應該看出來了吧？前邊的那幾層跟實體分析的結果一毛一樣，後面把實體的數據項變更成可能的操作就OK了，基本的原則就是增、刪、改、查。如果有比較特殊的業務，也要單獨描述，比如説改這個功能就很微妙了，改用户的可用狀態叫激活/禁用，那你就要單獨列出來激活/禁用的功能項。
這樣，你就能列出來一個大大的思維導圖，在列思維導圖的時候你要儘可能的發散你的思維，功能規劃上能做多牛逼就做多牛逼，想想還是可以的，萬一人家研發説沒問題呢。
做完了這個功能分析後，我就可以進入常規的功能定義了，這時候我就需要把功能按照業務邏輯、操作邏輯等角度做歸類、合併，最終形成一個功能定義文檔，這個功能定義文檔就是大家在常規產品設計教程裏面看到的功能設計了，做好了大概是這樣子的：
之後，還需要對這個功能列表做個改造，按照系統的權限（我們做的都是固定角色權限，沒有複雜的權限體系，所以比較簡單）給各個功能劃分以下權限，就可以了。
做完了的成品是這樣子的：
這樣產品的功能定義也就OK了，這個功能定義可以作為後續跟研發做估算的依據，也可以根據研發的估算確定產品研發的取捨和排期，另外，這個功能列表要和之前用户需求調研、產品解決方案設計的產品相關內容對一下，看看是不是覆蓋全面了。
最後，我們這一整套功能定義做下來是這樣的：
備註前面的那一列就是加上去的第一期產品排期，如果沒畫勾，那這個功能在第一版就不做了。至此，功能設計的內容就算告一段落了。
信息架構設計信息架構其實就是把功能定義在做一次整合，這次就比較有指向性了，主要是為了後面做界面原型服務的，你可以把信息架構設計理解為菜單的設計，如果前面的工作都做得紮實了，你把前面得內容做一個整合就OK了（注意：設計信息架構得時候就可以“參考”一下競品得信息架構，在加點自己得微創新就好了），大概是這樣子得：
這個圖我也不展開了，太大不容易觀看。不過，這個信息架構設計是個中間成果物，主要是給產品做參考的，後面做產品原型的時候，還是可以酌情修改的。這裏面把一部分的功能也加入到裏面其實就是想提醒一下原型設計者，這個界面可能有多少按鈕、鏈接等等操作元素。
業務流程設計信息架構設計完了，為啥要做業務流程設計呢？
其實這個業務流程設計準確的描述應該是基於產品的業務流程，就是説用户用你的產品以後，他的功能操作流程是什麼，做這個的目標一方面是將來可以基於這個形成用户體驗地圖，另外一方面也是驗證前面的功能設計跟客户的業務流程是不是能匹配的上，這個業務流程設計不用搞得太複雜，就是以業務為主線，串聯一下功能就OK了，一般畫個流程圖。
參與角色比較多就畫個泳道圖，我們做好的業務流程設計大概是這樣子的：
這是其中一個業務分支的管理流程總綱，後面帶了很多分支流程，就不一一列舉了。做了這個業務流程設計後，你基本上可以判斷出來你設計的功能是不是能夠滿足業務要求。
如果有條件的話，拿着這個業務流程去跟你們的客户、用户去聊聊，看看有沒有什麼補充。沒條件就算了，反正我們是沒這個條件（這句話我好像在前面説了）。
產品原型（PRD）前面的全完成了，就該進入產品設計的重頭戲了，產品原型設計。產品原型設計其實就是考慮交互的基礎上畫原型，這個階段很多產品都已經輕車熟路了，我覺得怎麼畫原型這件事兒我也不需要更多的描述了，要不就編程Axure教程了。我就説説原型和PRD的關係吧。（還是一如既往的野路子）
之前我曾經使用Axure畫原型，用Word做PRD，這方面的模板也挺多的。後來我發現這個方法我做的挺累，研發還不領情，為啥呢？你看啊，研發做功能開發的時候，需要打開兩個文件，一個是原型稿，一個是PRD，原型稿用來看頁面，PRD用來看功能，切換來切換去，搞得很煩，於是他們就老跟我吐槽。
後來，我就想，為啥不能放在一起呢？（能把事兒説明白的PRD就是好的原型稿），所以我就用Axure直接做PRD了。
我做的PRD是這個樣子的：
- 修改記錄不説了
- 共通説明其實就是描述一些共通組件的説明，比如頁面規格什麼的
- 公用功能就是每個頁面都有的，比如用户頁面、Banner之類的
- 平台功能就是按照信息架構來製作的原型稿了。
界面原型設計的時候，我用了AntDesign的Axure組件，相當好用，相當高效，推薦各位童鞋使用。
頁面設計的內容是這樣的：
我們並沒有做非常複雜的交互原型，而是採用這種方式描述。左側是原型，右側會把原型圖裏面的組件拿出來，分別標註各個組件的操作過程。這樣研發爸爸們就可以一邊看原型稿，一邊看功能。這個模式的PRD研發爸爸們還挺喜歡。
PRD製作完成後，產品設計的前期工作就告一段落了。後面就是推動研發、回答研發過程中遇到的問題等等階段了，其實到這個時候產品就該準備下一個迭代的工作了。
不過為了能讓產品流程保持一致性，我會把研發的過程也順便講一講，感興趣的童鞋可以看看。
本文由 @Jimmy.jing 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議