后臺產品設計:流程設計(三)
一份高效的流程,可以清晰地傳達產品在某個層面上的信息。該篇文章簡單介紹了產品的流程,并用實例來演示產品流程的從無到有。
上篇,針對簡單系統和復雜系統,筆者介紹了兩種不同的需求設計方法(傳送門:后臺產品設計系列:產品設計方式(二)),此篇,將在需求及產品架構確定的基礎上,介紹產品的流程設計。
流程設計,是決定產品是否可用、易用的重要因素,同時也是一個產品經理邏輯分析能力強弱的重要體現。好的流程設計,不僅讓產品功能形成閉環,也讓用戶感受到產品的簡單高效,帶來良好用戶體驗。以下將以外賣訂餐為例,詳細圖解流程設計。
一、流程介紹
1.1 定義
流程:特定主體為了滿足特定需求而進行的有順序的一系列操作過程。
例如:外賣訂餐流程,特定主體是用戶、特定需求是訂外賣。
1.2 分類
從功用角度,流程分為業務流程、功能流程、操作流程、頁面流程、數據流程五類;
從主次角度,流程可以分為核心流程、次要流程、異常流程、子流程。
這兩種劃分角度各自獨立,又相互融合,進行流程設計時都需要考慮。
業務流程:根據產品解決用戶核心問題的順序所梳理的完整的閉環流程,包括線上和線下兩部分。例如,下圖是解決用戶訂餐問題的整體流程:
梳理完整的業務流程是建立全面產品認識的必要條件,很多產品經理始終把自己定位為一個狹義的互聯網產品經理,對線下環節不夠重視。在梳理業務流程時,沒有把線下流程考慮的足夠清晰,一筆帶過,導致很多時候線上體驗做好了,線下體驗砸了口碑。
功能流程:功能流程也可看做任務流程,是產品實現某一功能的流程,或者是用戶完成某一任務的流程。如下單流程:
頁面流程:在功能流程基礎上,用戶完成某一任務所需經過的頁面,就組成了頁面流程。
操作流程:在頁面流程基礎上,用戶完成某一任務所需進行的操作順序,就是操作流程。
數據流程:用來說明業務處理過程中,信息流和數據從輸入移動到輸出的過程中所經受的變換,更多體現在數據庫層次和前后端的數據交互,一般不需要產品來做梳理。
對于另一維度的劃分,從字面意思即可理解,就不再說明。
1.3 表現形式
基礎流程圖:以圖形形式,顯示流程中前后活動(動作)順序;
跨職能流程圖:又稱泳道圖,顯示進程中各步驟之間的關系以及執行它們的職能單位、系統或功能模塊。其實就是在基礎流程圖上,將角色獨立成為一個個泳道,便于更直觀的查看流程中各環節與角色的關系和流轉情況;
1.4 六要素
- 參與者:上篇說到,后臺產品所有的需求都是有一個明確角色的,流程中的操作也是如此。參與者就是誰在這個流程中做的操作?可以是系統,可以是某個設備,更多的指一個角色。比如用戶、商家、外賣小哥;
- 活動(動作):一個處理動作,具體做了什么事。比如下單、接單;
- 次序:這些事情發生的前后順序如何,哪個任務是其他任務的前置條件。比如用戶不提交訂單,就無法生成訂單;
- 輸入:每項活動開始取決于什么樣的輸入物或數據,比如做飯的師傅開始做菜時,需要拿到具體的點菜單。;
- 輸出:每項活動結束后,會輸入什么樣的文檔或數據傳遞給下一方,比如師傅做好菜后,如何讓負責傳菜的人知道菜已經做好;
- 標準化:采用一套標準化的符號表達并傳遞你的流程。
在繪制流程圖時,表示每個環節都應該能夠清楚的說明“誰在哪個階段做了什么(who、where、what)”。
1.5 流程圖基本結構
順序結構:順序結構是簡單的線性結構,各框按箭頭順序執行。
分支(選擇)結構:這種結構是對某個給定條件進行判斷,條件為真或假時分別執行不同的節點內容。
循環結構:當流程中需要反復執行某個動作時,就需要設置循環結構。它由循環體中的條件,判斷繼續執行某個動作還是退出循環。
二、流程設計
認識了流程及流程圖,下面將用實例來分步介紹流程設計。
2.1 調研現有流程
對于很多產品,用戶痛點是明確的,很早之前就有了各種解決方案。只不過互聯網的興起,提供了一種更快速、更便捷高效的方式。O2O產品就是這樣一類借助互聯網特性,解決用戶已有痛點的產品。
肚子餓了要吃飯,又懶得不想出去,這就是外賣APP所解決的痛點,當我們從最初開始設計外賣產品流程時,就應該從已有的、成熟的、經過市場檢驗的解決方案入手,進行調研。
當外賣APP沒有興起時,要想能吃到飯又不用出門,人們最有效的方式就是打call。經過調研,電話訂餐的流程如下圖:
2.2 分析環節痛點,線下流程線上化
線下流程梳理完成,會發現每個環節都存在或大或小的痛點有待解決。這個時候,就應該考慮如何利用互聯網打破信息壁壘、便捷快速的特點和技術手段來解決這些痛點,進而在線上解決方案的基礎上,設計一條全新的業務流程。例如,初步分析即可發現現有訂餐流程存在諸多問題:
結合現有流程和線上解決方案,我們就可設計一個新的業務流程,得到下面這個基本流程圖:
2.3 劃分階段和角色并拆分子流程
從上面這個基本流程圖可以看到,雖然每個環節都展現出來了,但有以下幾點問題:
- 為了說明“誰在哪個階段做了什么”,導致每個環節描述過長;
- 角色冗雜,無法清晰查看每個角色需要完成的工作,導致后面做用戶權限設計時容易出現混亂;
- 部分環節深入后發現有更為詳細的流程,而這些更為詳細的流程難以體現。
所以為了讓流程圖更清晰的指導后續產品設計,需將基本流程圖按角色拆分,輸出泳道圖:
在主業務泳道圖中,我們將用戶下單流程、騎手搶單流程作為子流程進行梳理,在Visio中新增幾個sheet頁,單獨繪制子流程的泳道圖,這樣做的好處有以下幾點:
- 避免了主業務過長,導致可讀性很差;
- 重要的分支流程單獨梳理,方便多個產品經理協作、維護;
- 結合上篇所說的微服務思想(劃分系統),這些子流程就可以作為某個獨立系統的主流程,指導這個獨立系統的產品設計。
以上三步完成的就是業務流程的梳理。當我們完成足夠細致的業務流程梳理時,就會發現:產品的主要功能流程都包含在了這些業務子流程中,然后再根據這些功能流程,設計出相應的頁面及操作流程即可。
#專欄作家#
Z. Fly,人人都是產品經理專欄作家。關注B端產品;擅長需求分析及對內對外溝通。
本文原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
文中的業務流程和功能流程貌似區別不大哈
有的業務線上化程度高,就會顯得差別不大,但大多數業務流程與功能流程差別很大
畢業萌新一臉懵逼地接手新系統的規劃,現在項目已近尾聲。項目快結束,寫操作指引的時候花大功夫畫了流程圖(emmm,其實應該一早就梳理清楚再畫原型,不然也不會踩那么多坑…坑到開發同事…)不過現在看到這篇文章,深有感觸,很多地方讓我歪打正著,有種考完試對答案發現考了90分的感覺哈哈
作者寫得太好了,期待出書??!
寫的特別好,我之前就是沒有梳理流程,直接畫原型,越畫越亂,沒有條理。還被開發懟。。。。。。 ?? 謝謝分享 ??
說了這么多,是明白了,但是具體做的時候還是很難的,需要做什么,有哪些東西,怎么做,怎么個數據流轉,這都是我現在蒙圈的!哈哈
老師你好,我覺得你的文章寫得很清晰,對我很有幫助,很感謝你。
我想請教下,有沒有更為細微的書籍或者課程啊,謝謝,
目前我也沒找到,不過會盡快出一本介紹相關信息的書
后臺產品設計系列:認識后臺(一)http://www.aharts.cn/pd/1053728.html
后臺產品設計系列:流程設計(二)http://www.aharts.cn/pd/1202556.html
后臺產品設計系列:原型設計五大要點(四)http://www.aharts.cn/pd/1547652.html
前往主頁,查看更多
不好意思,第二個是 后臺產品設計系列:產品設計方式(二)http://www.aharts.cn/pd/1202556.html ?? ??
看了好幾篇這篇最清楚
能幫到你就好 ??
想了想,還是不占用首行了,最后一句畫龍點睛!贊一個 ??
寫的很透徹,點贊
精彩,感謝分享!
寫的真好,謝謝了大師!
學習
受益匪淺
總體借鑒了,不過建議流程不要從下往上做。遵從從上到下,從左往右
寫的很好 調理清晰 了解了流程設計相關的知識