起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品設計的從0到1全流程：以優惠券為例
文章以優惠券功能為例，分享了一個產品功能設計的完整流程，希望能夠給你帶來啟發。
如何將產品從需求調研到落地的全流程拆解？
我們剛開始做產品時，可能都會有這樣的困惑：老板說要做某個新功能或模塊，但是不知道從何下手，怎么做？做成什么樣子？怎么樣才能做完業績蹭蹭漲呢？而老板說的做xx，可以詳細拆解成數步。產品經理每天要做的，就是把需求做好、落地。本文以優惠券功能為例，主要談下我自己在做產品設計時的總體思路，期望用這個文章讓大家把每一塊散點的技能串聯起來。
注：優惠券品類比較多，本篇僅討論商家優惠券。
產品設計的從0到1總體全流程圖（重要）
一、需求分析
1、回答一個填空題：什么用戶，在什么場景下，遇到了什么問題。
（注意：這個用戶可能是多方的，不僅僅是一方）
- 消費者：購物時發現無優惠活動，平臺一直無優惠活動，不能減少成本。
- 商家：在平臺銷售，無法進行相應運營活動，為消費者讓利，促銷
- 平臺：無優惠券這類營銷方式，不利于運營推廣，吸引消費者
2、一句話描述清楚產品需求（即對上方填空題的回答）：給產品增加優惠券的需求，可以讓平臺上的商家定向或者公開的向用戶發放優惠券，用戶在下單時候可以使用優惠券，抵相應金額的功能。
- 注意：誰提出的功能，和誰在使用這個功能可能是兩個人，一定要考慮清楚，比如某個功能可能是老板提出的，老板想要。但是真正使用功能的用戶是基層員工。所以在設計產品時一定要考慮實際使用的用戶是誰，要最大化減小產品的學習成本。否則有可能功能上線，無人使用，白費功夫。
- 同時也可以整理一份原始需求記錄，將產品的根本目的、注意點記貼在墻上，時時提醒自己，為后面設計不跑偏做準備。一般我會在PRD最后貼上客戶原話或者聊天記錄，因為你翻譯后的定位可能會有偏差。
- 可參考的競品：京東、淘寶等主流電商網站
二、流程梳理
1、先分析功能的關鍵邏輯
先分析一個優惠券最主要的邏輯，不考慮任何異常情況，其實就是：
2、補充關鍵邏輯中細節功能，每個里面細節就是核心的功能點
可以看出沿著主流程這個圖已經豐富了比較多的內容
3、泳道圖（復雜多角色流程）
上面講的是簡單流程圖的設計，若涉及到多角色，可以將其繪制成泳道圖，泳道圖繪制可以看下方步驟：
1）分析關鍵邏輯：確認角色、事項、信息流向
- 角色：都有什么角色參與到功能里
- 事項：每個角色要做什么事情
- 信息流程：要完成任務，順序（流程）是如何的
以優惠券為例，我們可以畫出各個角色及事項：
2）明確開始于結束路徑
每個功能模塊從哪里開始，哪里結束。一般開始和結束只有一個
3）確認核心路徑和功能模塊
確認都有哪些模塊會參與到流程中，主流程就是功能目標一定要清楚
4）不斷調整并優化，補充異常流程
泳道圖中，主泳道圖可能不會那么細致的將全部都畫完，可以將其功能模塊其中部分拿出來細化到PRD中
成型的泳道圖：擁有角色、事項、各流程
注：對于產品設計來說，很多時候都是一種邏輯分析的能力，流程圖在產品設計中，會占據很大的作用，只有流程圖清楚，才能整體設計保持清晰。千萬不可一上來，找兩個競品，開始抄界面，即使是競品分析，先分析競品的整體流程，才能猜透整體邏輯。要學會拆——合，抽繭剝絲。
三、信息結構及功能結構圖
經過需求分析和流程圖設計后，我們已經確認了整體大致方向、流程，接下來進行功能結構圖或者信息結構圖的發散、收攏。 就可以將優惠券功能填充完整。
對于功能結構圖與信息結構圖的區別：功能結構圖，是為了梳理需求，防止出現缺頁面，缺模塊的現象，以鳥瞰的方式對整個產品的頁面結構形成一個直觀的認識；而信息結構圖，是要羅列信息，作為開發建立數據庫的參考依據。
1、功能結構圖（xmind）
比如針對優惠券功能，我們把主流程設計好了后，可以以下幾步:
- 在思維導圖中，先寫出主流程，作為子主題，比如仍然是創建——領取——使用——查看
- 再進行每個模塊詳細的發散。比如創建優惠券，可能要設置相應條件、發放渠道。創建后需要進行數據查看等等，可以先廣泛發散
- 進行連接：每個連接都是頁面與頁面的連接關系。為等會原型設計做準備。其實在功能結構圖這步，下一步就可以按照功能結構圖去繪制各個頁面及頁面間的關系了
2、信息結構（xmind或者Excel）
關于創建優惠券的部分信息結構。信息結構關注的是單個頁面的元素，信息來源，字段限制等，而非結構化的信息，有時用表格來展示，或許會更加清晰。這個清楚的部分，就可以將其到時候放置到你的PRD中了
3、優先級及版本計劃
優先級確認：可以根據重要、緊急程度確認優先級。具體不在此闡述，在此主要提出這個是為了說明，作為一個產品版本計劃的重要性。需要用最小可行化產品，確認每一期功能、目標，層層迭代。同時在最開始的時候和團隊成員達成一致，讓開發、視覺清楚后面的計劃，可以讓他們在開發拓展新或者設計拓展性提前準備。這樣他們會覺得你這個產品經理比較靠譜，更加有利于后面的合作
四、原型設計
1、手繪（鉛筆）
可以在剛剛的思維導圖基礎上進行原型繪制，比如四條路徑，每個路徑具體細節和連接交互?；舅季S導圖邊繪制時候，腦中原型基礎可能也就出來的。
2、axure
使用鉛筆繪制后再進行axure繪制，同樣 搭左側菜單框架（將頁面關系先在原型中建立好）——粗的繪制板塊——細節填充——異常流考慮
五、完成PRD書寫
搭建框架——梳理主線——填充細節
1、搭建框架
需要將產品所有功能進行合理分解，確認PRD各級標題。把最粗的結構梳理出來，想清楚按照怎樣的樹狀結構會更加清晰。最好是形成自己的文檔結構和習慣，這樣以后書寫均比較高效。
1）基本原則：
- 按頁面元素分解：上→下，左→右
- 按用戶操作步驟分解：提交→展示→展示后編輯
- 按在系統中所在位置分解：前臺頁面→商家管理后臺→官方管理后臺
- 按功能主次分解：主要功能→次要附屬功能
2）基本內容：
- 背景及規劃部分：遠景目標、目標市場和客戶、競品分析、產品價值
這部分需要在一開始，和你的項目組成員達成一致，雖然看起來很虛，但實際非常有用，體現了你對于產品的思考程度。
- 核心部分：對功能主要優先級、初步擬定實現進度安排、產品和項目風險點、功能及頁面描述
這部分是整體中最核心的主體部分，功能列表可以先行羅列，下方展示具體頁面及說明
- 補充部分：產品軟硬件要求、產品性能要求、運營方案、項目上下線要求
產品的上線需要配合許多的內容，最好在開發前，將運營計劃等等確認清楚。
3）目錄示例：
以優惠券為例，就是按照在系統中所在位置分解，分為不同操作平臺，再按照功能主次，進行整體框架構建?？梢韵劝堰@樣的框架搭建后，在填充內容，就比較快了
2、梳理主線
對已確認的PRD章節順序，用關鍵示例圖+簡要文字描述，注意以下幾點
- 只需要關注功能主線，對應細節和特殊狀態此時暫不關注
- 產品主要功能。在PRD要有完整體現
- 在主要功能點整理過程中，及時調整結構
- 與開發初步溝通
其實整個文章分析下來，將其流程及簡要原型，這個分析的過程，就是你的PRD。
3、填充細節
細節通常占據整個文章70%以上。需要包括所有產品文案，功能說明，操作流程，判斷邏輯，權限區別，頁面效果，錯誤提示等內容。
Tips：對于PRD書寫，可以按照產品類型，有不同表達形式。
如針對信息內容較多的產品，比如后臺的工具式產品，信息內容和細節都比較多，可以使用Excel方式將信息內容表示出來?？梢詤⒖忌戏教岬降男畔⒔Y構表。
如針對邏輯性產品，可以使用流程圖的方式說明信息流轉、數據流轉等等。
小結：PRD、AXURE都僅只是工具，重要的是整個過程思考的路徑及方式。之前看過一個文章，說產品經理最核心的應該是思考力，這些工具無非只是溝通的方式罷了，和團隊成員多溝通，找到最適合自己團隊的，同時培養自己扎實的產品設計基礎能力，提升效率，把更多時間可以用在業務思考方面。
作者：周玥，微信公眾號：粥dayday的腦細胞
本文由 @周玥? 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自PEXELS，基于CC0協議
佩服作者干練的文風，沒有廢話，贊！
公眾號更名為：B端周玥
感恩，寫的非常得全面
很全面，點贊
請問在領取優惠券的時候，不用進行用戶身份的判斷嗎？是否是注冊登錄用戶？
樓主，厲害了，謝謝分享
原來產品要做的事情那么多，我們公司的產品感覺不用寫那么復雜啊
東西考慮的越細，后面遇到的BUG和·返工越少，比如按照阿里的用戶體量，如果出現一點問題，影響面都會很大，。像優惠券這種涉及到錢的，更要慎之又慎
關注了
寫的很詳細，值得學習，我的prd就很low ??
運營計劃牛逼了
那個一般會放在那，然后逼著運營寫，哈哈。否則產品沒有運營活動配合，是很難在開始推起來的
感謝
感謝，對目前的我來說，很受用 ??
有幾點想說一下：
1.本身產品制作，原型不是重要的，PRD 首重是設計、模型，原型就是個前端的皮，這個本身的制作流程就是不對的，一個1-2年的產品剛開始的時候理不清思路還可以這么干，但是后面越這么干，你會感覺在寫PRD的時候自己思維會越來越跟不上，建議先從用例開始；
2.優惠券的類別有很多，所以過程不是創建、領取、使用，比如口令類，活動類，本質上 她雖然歸屬優惠中心，但和典型的優惠券不屬于一個類，在技術上不能合并處理；
3.流程圖，emmm……想說 用戶、商家可以作為同一級的泳道……把系統放進來……算啥…… 你要是寫業務流程，就分用戶、運營、市場、銷售，要是畫系統流程圖，就是OMS，優惠中心，商品中心，WMS。TMS這樣，放在一起畫本身就是不對的；
4.從你的流程上，缺少了逆向，賣出去了，怎么退換，涉及到的金錢逆向計算，對于發票的支持，接口支持都沒寫。
最后，emmm 你還是從用例開始重新描述過程吧。
當然，在牛點，直接領域建模，開始建模就好。
嗯，在一開始就說了優惠券的種類有許多，本文只討論一種情況的優惠券，重點不是在于優惠券的描述，還在在于整個流程的串聯。對于你想流程的確在本文沒有寫到，也是因為篇幅的原因，討論逆向情況太多了。
泳道圖里面將系統涉及進來主要是考慮涉及到優惠券抵用處理情況，這個也是和團隊使用習慣相關。主要在于所有參與的角色和全流程。
最后感謝你的建議~
業務建模，描述結構關系，構建業務流程，抽取用例，寫規約，組件關系描述，這套我很久沒看見人用了，現在的交付基本就是一套原型讓開發自己去想
是的 信息結構 業務架構 系統架構，這些完全都丟給技術了……感覺現在描述的都是產品設想……Orz
開發現在想看的就是3秒懂的，覺得最好就是所有的全整合到原型里，就算你提交了文檔，寫的很細致，我們的開發還是會問，這咋弄。。。 文檔有啊 大哥– – ??
寫的越詳細 技術越容易看明白 產品文檔是產品經理所有思考的提現，文檔承載的就是產品的想法，你想清楚了100%，寫在文檔上的只有20% ，那輸出的就是20%，如果你想清楚了80%，寫了80%出來，就是64%，當然不是說不想清楚，寫的詳細就是好，那更容易坑，產品經理最重要的還是想清楚
其實，你犯了嚴重的教條主義錯誤。你對業務流程和系統流程，沒弄透徹。誰說業務流程里不能存在非組織、非人的系統的？你畫業務流程是反映業務現狀的，現在信息化程度已經很高了，很多業務都是非人的系統干了。
贊同+1
贊同+2
業務流、信息流、資金流、物流，可以耦合在一張圖里展示 是沒有問題的，但是必須要解析透徹，那些是業務操作流程，那些是系統信息流 怎么觸發資金流、物流，關聯關系是什么，如果硬要花在一張大圖李，是一定要畫的非常清楚的
拆開的建議是，這幾個流程的閱讀方是不同的，業務、技術、財務等等，各方的關注點不同，硬要一張圖，建議只是大綱，闡明扼要，而各方只關注自己的重點關注即可。
你說的那種系統來處理的 把人和系統畫在一張圖里的，時序圖更合適，而不是流程圖
我也覺得沒有場景分析，和用戶分析。沒有判斷是否是注冊登錄用戶。1,2,3,4的觀點贊同。
寫的很好
歡迎各位加我公眾號：粥dayday的腦細胞~~~~~
感謝，很受用！