一、前言
從事IT好幾年工作，經歷C端的設計也深入做了B端的設計，在不斷學習、實踐中逐漸形成自己的設計方法與工作習慣，藉此分享出來以便吸收更多高手的意見與想法。
二、設計的業務流程
2.1涉及理論
整個文章或者分析方法都是基於“使用者體驗的五要素”的框架來分析的，所以有興趣可以直接看那書會更直接的。
但是這裡要說一點，產品經理應該“重點分析戰略層”，而不是結構層以下的細節設計。產品核心，產品設計出發點不一樣，產品細節的設計也會跟著不一樣，而產品經理的最大作用是帶領這個產品往一個方向前進，而不是陷入在細節設計裡面。
2.2我的設計業務流程
三、一個案例的分析
3.1背景描述
是關於OKR系統的設計，公司有一套線下執行的OKR考核制度，但是沒有線上化。整個專案持續接近3個季度（OKR是一個季度一次，所以校驗有點麻煩。）
從一開始的設計，到V2.0的簡化，到V3.0的產品化設計（小版本就不寫了，這裡寫的是產品形態發生比較重大改變的版本）。前兩個版本由於是公司內部系統，也適合展現在這裡，所以這裡只展現V3.0我個人對OKR這個系統的設計想法，並從這個案例裡面講解下怎麼分析設計。
備註：3.0的設計，其實很多是借鑑worktile的設計（這裡不是廣告，而是競品沒多少，它的設計，相對好點），有興趣可以直接使用那系統。
3.2初步分析
1、分析內容截圖
2、使用文件：腦圖、excel
3、分析內容
A、OKR相關知識與競品：這個是設計這個產品的理論基礎，如果連基本的理論都不知道，就很難設計出準確的產品。
B、干係人：主要明確誰可以提供什麼幫助，有問題可以找誰。不過這個是專案管理的範圍，簡單看看就好。
C、產品分析：
C1、產品原始核心：核心解決什麼問題？一開始不用在乎太多，越純粹越有價值。後面再根據公司實際情況調整“目標產品能做什麼，不能做什麼，主要解決什麼問題”。
C2、理想的業務流程：最理想情況下設計的業務流程，因為每家公司的業務流程絕對是有差異，這些差異必然有好有不好，但是通用、客觀的流程都是通用的，總不可能ERP系統不是解決貨物流轉業務？
C3、競品分析：偏重產品設計核心理念、優勢、缺點這些即可。
D、設計疑問：如果已經有收集好的原始線下資料，就可以根據理論與現實或者原始調研資料，分析該流程合理與不合理，並整理出設計疑問以便業務調研或者以後追查記錄用。
4、注意點：
A、只做收集資料與積累原始知識就好，不要做判斷。
B、這階段主要是判斷做不做，投入產出。雖然大部分內部系統，這個決定權都不在自己身上，但是可以通過資料收集，產品初步建模，判斷能做什麼，不能做什麼！
3.2業務調研-明確角色
1、分析內容截圖：
A、設計的業務流程
B、抽象後的業務流程
C、抽象後的角色用例
2、使用文件：流程圖、角色用例（VISIO）
3、分析內容：
A、原始業務流程：原始的業務流程必須要忠實記錄原始記錄，很多人習慣在記錄原始記錄的時候，增加自己的優化、想法，結果扭曲了現實。以後別人看那些文件的時候，沒法知道當時的實際情況，需要重新調研。
B、抽象後的業務流程：根據UML建模方法抽象出通用的業務流程。
C、抽象後的角色用例：其實這階段，更加關鍵是明確最主要的角色用例，細節可以不用那麼仔細分析，在頁面設計的時候再去詳細分析頁面的角色用例，會好點。
3.3架構/框架設計
1、分析內容截圖：
A、功能框架
B、頁面框架
2、使用文件：功能框架（VISIO）、頁面框架（AXURE）
3、分析內容：
A、功能框架：這個沒什麼好寫的，跟網上這個的作用一樣，主要是比較巨集觀點看清楚整個架構而已。
B、頁面框架：這裡有個個人習慣，我會將頁面框架跟功能框架比較統一的建立起來，這樣後人或者自己看到這個原型，就可以根據實際頁面找到對應的原型、細節，省事很多。（其實原型頁面還有一個命名規範，不過很久沒弄，就算了。）
3.4頁面細節-需求文件
1、介面截圖
A、原型設計
B、需求文件
2、使用文件：AXURE、word
3、細節點：
A、每個頁面都建立專屬的“頁面目的”、“參與角色”，然後用VISIO畫出這個頁面的專屬角色用例。因為這樣，可以讓你的設計更加專注，頁面的目的清晰，核心業務流程清晰，同時也可以分析角色在這個頁面裡面的所有需求是什麼。
B、需求說明書其實就是將之前的整合在一起，這裡網上找個模板就好，關鍵是要寫清楚邏輯細節。
C、原型設計：建議遵守一定的互動設計原則，我是為了方便隨便畫了下而已。
3.5開發實施
1、版本及功能明細
可以用來讓開發評估工作量，然後整體去看。不過後來這種表很少用了，原因是維護不方便，而且從0到1的時候，挺好用。但是1到N的時候就不方便了，改用專案管理工具，按 “需求”或者“任務”來評估就好。
2、里程碑計劃
這個可以明確這個功能、這個範圍該由哪位負責，如果團隊比較大的時候，這個非常有用，團隊協同起來會比較方便，想知道這個誰負責，看文件找對應人就好了。
專案過程的管理，現在基本都用工具，所以如果系統工具玩得好的時候，後面我也少用這些文件了。
3.6試執行
1、需求收集表
這個表非常重要，建立這個產品的需求池，有了需求池以後的迭代開發才方便。如果用工具去記錄不是說不行，但是有一些分析很難在上面記錄。
而且我的表是優化過的，適用我自己。因為我關注“原始需求描述”、我的“簡要分析”、滿足情況這三點，其他的對於我來說沒什麼作用，我都刪除了。
2、問題收集表
這個表如果沒有系統的話，還是有一定價值，用專案管理系統會更簡單。不過關鍵是，從這些問題裡面，發現新的需求，或者對這些的分析，這些就只能在自己的文件裡面記錄了。
四、設計中涉及的檔案模板
最後說一個個人的小習慣：每次開新的專案、產品線，我都會複製一套這樣的模板。這樣可以方便自己快速分析，不用每次重新建文件，改名字，配置好文件裡面的格式，這個也是這篇文章出來的根源。
五、結尾與反思
寫完這文章之後發現，其實這方法更加偏重企業內部或者B端的產品，針對C端或者市場類產品，需要對市場的分析或者初始階段的分析比較重要。不過一般很少人有機會做那些C端市場分析，大多是接受到一個需求，然後設計一個需求。
同樣，雖然看上去是整個大功能的需求設計，但是其實細節需求也一樣，每一個明確需求如“放寬輸入限制”這種明確需求，也是需要分析提這個需求的人所處的角色、他的場景、他的目的，最終才是決定方案，其實分析的流程也是從戰略到細節，只是中間省略了部分環節而已。
5.1這套方法的優點
A、比較系統、框架去設計一個產品，相對會專業、完整一些。
B、關注產品的核心並且進行深入分析、記錄，這點比較少人會去做，初級的產品大多是直接畫圖，很少會去分析產品核心並記錄下來。
5.2這套方法的不足
A、偏重產品設計，相對運營、冷啟動等方面的產品工作比較少涉及。
B、缺少整個產品的進度判斷，roadmap，產品資料，運營情況的記錄與分析。
C、缺少整個產品模式，生態，或者巨集觀、整體的設計，偏重個體功能塊。
以上是我個人對產品設計的一些見解，純屬個人看法，如有更好的歡迎下面評論一起討論，研究下。
最後想做個測試檢查自己寫的文章“淨推薦值”（NPS）有多少，想期望看完此文章的讀者麻煩私聊（記得帶上文章標題）或者評論回覆：
問題是：願意推薦程度從0（最低）-10（最高）分之間打分，這篇文章你是否願意將這篇文章推薦給你的朋友或同事？
需要回復：願意推薦程度多少分？