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