眾云行第二彈:從BRD到頁面流程圖

距離上次發(fā)發(fā)帖已經(jīng)有一個多月了,本來想早點(diǎn)發(fā)新帖的但是各種瑣碎的事干擾,一直沒能寫帖子。對“眾云行”不了解朋友的附帶產(chǎn)品BRD連接(原文:http://zhangjingwei.cn/pd/321497.html)。
說起產(chǎn)品經(jīng)理的日常工作有一個很重要的點(diǎn)就是梳理產(chǎn)品流程。最開始接觸流程設(shè)計的時候一直搞不清楚什么是業(yè)務(wù)流程,操作流程,頁面流程以及這三者的關(guān)系。經(jīng)過系統(tǒng)研究后得出些心得,和小伙伴們分享下,如有哪里錯誤還請指出,感謝糾正?。?!
第一部分:名詞解釋
業(yè)務(wù)流程:
也有人叫“功能流程”,作為梳理產(chǎn)品功能框架的依據(jù):其實就是你要做一件事的時候一共分為幾步走,這幾步的先后順序就是業(yè)務(wù)流程。簡單舉個例子:說把大象放進(jìn)冰箱里分幾步,第一步打開冰箱門,第二步把大象放進(jìn)去,第三步關(guān)上冰箱門。轉(zhuǎn)換成流程圖如下:
操作流程:
就是你完成過每一步需要做的事情和具體怎么做,以大象放進(jìn)冰箱里的例子中的第一步打開冰箱門,為例:
動作包括:手握住冰箱門——拉動/推動冰箱門
判定條件:
- 確認(rèn)冰箱門是否打開,如打開直接放入大象,未打開則手握住冰箱門
- 確認(rèn)冰箱門是橫開或平開,橫開則橫向拉動,平開則水平拉動。
限制條件:
橫開門必須橫向拉動,平開必須水平拉動。
(關(guān)于限制條件,有的人覺得在流程圖階段不用考慮,但是我覺得在整個梳理流程的過程中最好能將考慮的細(xì)節(jié)條件都進(jìn)行標(biāo)注,這樣能夠幫助梳理頁面流程圖和整理產(chǎn)品的信息架構(gòu),深化交互設(shè)計。)
結(jié)果條件:將門打開至足以放入大象的開口大小,未達(dá)到條件則無法進(jìn)入下一步。
轉(zhuǎn)為操作流程圖如下:
頁面流程:
就是用戶完成前兩道流程需要處于的頁面環(huán)境,在環(huán)境1中觸及到哪一個點(diǎn)換滿足哪些條件后,到達(dá)下一環(huán)境。還是以大象放進(jìn)冰箱的任務(wù)舉例說明:冰箱關(guān)閉,大象在冰箱外的環(huán)境:出現(xiàn)一個冰箱,單擊冰箱門打開按鈕,打開冰箱門——進(jìn)入冰箱門打開,大象在冰箱外的環(huán)境,冰箱內(nèi)部分格場景進(jìn)入眼簾,選擇合適的分格空間,把大象放進(jìn)去,——進(jìn)入冰箱門打開,大象在冰箱里的環(huán)境場景:然后單擊關(guān)閉冰箱門的按鈕,進(jìn)入大象放入冰箱后,冰箱門關(guān)閉的場景,即完成任務(wù)的場景。轉(zhuǎn)為頁面流程圖如下:
這個時候就會發(fā)現(xiàn)先前有一些流程是我們沒有考慮進(jìn)來的,例如當(dāng)冰箱內(nèi)部空間不足的時候,是需要調(diào)整冰箱內(nèi)的物品以騰出足夠的空間,還是需要調(diào)換冰箱。以及一些交互過程中需要出示的小提示頁面等(例如,冰箱空間不足提示)
繪制頁面流程圖,也是對前面操作流程和業(yè)務(wù)流程的檢驗,細(xì)化和豐富。
總結(jié):
綜上所訴,業(yè)務(wù)流程,操作流程,是一種前后推導(dǎo)關(guān)系,業(yè)務(wù)流程作為推到操作流程的前提,操作流程作為深入細(xì)化和檢驗業(yè)務(wù)流程的工具。
頁面流程是業(yè)務(wù)流程和操作流程具體的場景體現(xiàn),頁面流程體現(xiàn)了滿足業(yè)務(wù)流程所體現(xiàn)的功能點(diǎn)和信息點(diǎn),以及通過操作流程所體現(xiàn)的各功能之間的關(guān)系和具體的操作方法。同時頁面流程也在不斷檢驗前兩個流程,幫助優(yōu)化流程。
在這里有一點(diǎn)需要提到的是,無論是業(yè)務(wù)流程圖,操作流程圖,頁面流程圖,在繪制的過程中都盡可能的表示出到達(dá)某一流程的輸入輸出條件,這樣既可以幫助后期的交互設(shè)計,也可以幫助梳理和豐富該環(huán)節(jié)的流程內(nèi)容,以及產(chǎn)品的功能架構(gòu)和信息架構(gòu)。
第二部分:眾云行案例推解,從BRD到頁面流程圖
這里以眾云行的流程為例,解釋三個流程具體的推倒思路。
第一步,細(xì)化BRD
通常情況下我們在編寫B(tài)RD的時候,會設(shè)計出產(chǎn)品大致的業(yè)務(wù)模式(初級業(yè)務(wù)流程)和涉及到的大的功能點(diǎn)(初級功能框架)。如圖:
(眾云行BRD中的業(yè)務(wù)模式部分)
(眾云行BRD中的功能規(guī)劃部分,現(xiàn)在看來寫的有點(diǎn)過了)
進(jìn)入流程設(shè)計階段(也可以說是輸出MRD文檔前的準(zhǔn)備階段)我們最先要做的是兩件事。
1. 梳理用戶,產(chǎn)品,后臺三個端口的主要功能大框和功能關(guān)系,如圖:
我將功能分為用戶端,產(chǎn)品端,后臺端三部分。用戶端:用戶在使用產(chǎn)品時需要主動獲取或操作的功能。產(chǎn)品端:產(chǎn)品自身需要為用戶呈現(xiàn)的功能。用戶端:組織支援前兩大端口功能,滿足后端運(yùn)營和監(jiān)管的輔助功能。
2.?細(xì)化業(yè)務(wù)流程。這部分沒什么說的,這里需要注意的是側(cè)重點(diǎn)應(yīng)放在用戶完成任務(wù)需要經(jīng)過的環(huán)節(jié),注意環(huán)節(jié)之間的邏輯和連續(xù)關(guān)系,切勿把中心放在某個具體的操作動作上。如圖:
第二步,繪制操作流程
首先是拆分業(yè)務(wù)流程,按環(huán)節(jié)特點(diǎn)或順序階段先后等條件,將業(yè)務(wù)流程拆分成若干個小環(huán)節(jié)。然后針對每一個小環(huán)節(jié)進(jìn)行操作流程的梳理。
個人認(rèn)為這里需要注意的是兩點(diǎn):
- 細(xì)化各操作流程中特殊情況發(fā)生的可能性,即操作的多種方式或是發(fā)生錯誤操作時的流程關(guān)系。
- 是/否的判定,盡可能的去考慮一個操作開始/完成時的輸入/輸出條件。這里可以加以備注,以方便后期繪制頁面流程圖。
如圖:(以用戶發(fā)布調(diào)研任務(wù)環(huán)節(jié)為例)
第三步:流程、功能、信息三者的場景化
上文提到每一個頁面就是一個小的用戶場景,我們要設(shè)想用戶完成任務(wù)的過程中需要經(jīng)過哪些頁面,使用哪些功能,獲得哪些信息內(nèi)容。體現(xiàn)到頁面流程圖上 就是每一個頁面需要呈現(xiàn)哪些信息,哪些功能點(diǎn),在打擊哪些按鍵時進(jìn)入的下一個頁面是什么。
這里需要注意的就是:
- 簡練頁面與頁面之間的邏輯關(guān)系,精簡頁面數(shù)量,頁面數(shù)量的多少直接影響到用戶在完成任務(wù)時經(jīng)歷的操作步數(shù)的多少。
- 細(xì)化同一頁面內(nèi)可能存在的交互可能性,并將其表述出來。
以上兩點(diǎn)一方面可以幫助梳理前面的業(yè)務(wù)流程,操作流程,也可以為原型設(shè)計打好交互基礎(chǔ)。所以本人覺得在交互設(shè)計環(huán)節(jié)時考慮的交互問題,可以盡量在這一環(huán)節(jié)考慮,具體的好處有哪些有,過設(shè)計經(jīng)驗或項目管理經(jīng)驗的人應(yīng)該都會有體會。廢話不多說直接上圖:(眾云行主框架的頁面流程關(guān)系)
點(diǎn)擊圖片放大,按“F”鍵可以查看原圖
總結(jié):
個人覺得流程圖部分鍛煉著產(chǎn)品經(jīng)理的邏輯思維和大腦的活躍度,想提高這部分能力可以多整理些經(jīng)典產(chǎn)品的流程部分。整理的越細(xì)致越能幫助產(chǎn)品經(jīng)理更好的完成這部分工作。
本文由 @于海洋 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
用戶地圖
作者好,我剛看到你給我回復(fù)的評論:(回復(fù)你第一篇入門的評論,然后回復(fù)不了了,帖子刪除了):其實我想說別刪除啊,我覺得挺好的,我看了你一系列的文章,感觸良多,受益良多,我想問下作者,我是商業(yè)PM,作者現(xiàn)在也做商業(yè)PM嗎
我現(xiàn)在是用戶增長產(chǎn)品經(jīng)理。 那篇西瓜視頻的帖子是對內(nèi)容產(chǎn)品變現(xiàn)模式感興趣才寫的。 這些帖子算是記錄了我入行這幾年的成長過程吧。
作者在頭條嗎
不在 我已經(jīng)不大想做內(nèi)容產(chǎn)品了
?? 我看你文章都是做策略相關(guān)的
咱倆同歲~
學(xué)習(xí)了很好
樓主不知道你現(xiàn)在咋看,其實頁面流程圖是沒有意義的,你的原型里面會體現(xiàn),第二業(yè)務(wù)流程圖和操作流程圖(也就是所謂的任務(wù)流程圖其實沒啥區(qū)別,而且基本上需要不到任務(wù)流程圖這個級別,原因很顯然),我來定義下流程圖共有三種:業(yè)務(wù)流程圖、狀態(tài)流程圖、底層流程圖;一般產(chǎn)品能畫出前兩種就算合格的。
這是我一年前寫的帖子了,我現(xiàn)在也不這么看流程圖了。 我先回答你第一個問題,我覺得頁面流程圖是有用的,但是什么時候用要看需求的大小。第二個問題,我現(xiàn)在把流程圖分為,業(yè)務(wù)邏輯圖,業(yè)務(wù)流程圖(我一般用泳道圖畫),交互流程圖,頁面流程圖(小需求不用與開發(fā)溝通的,我就直接用原型解決了)。我的理解里,你說的狀態(tài)流程圖應(yīng)該就是交互流程圖。我不清楚你說的業(yè)務(wù)流程圖 和底層流程圖有什么差別。
自己寫的文章一定要對廣大的讀者負(fù)責(zé)
所以你想說什么?
這是我剛做PM時寫的心得貼 ,現(xiàn)在開來是有內(nèi)容需要迭代了
這里的頁面流程圖感覺是列出該頁面包含的元素,然后標(biāo)注各頁面元素之間的轉(zhuǎn)跳關(guān)系,那么這個和交互里的原型圖(同樣有轉(zhuǎn)跳關(guān)系)有什么區(qū)別。還是說這個只是PD的產(chǎn)出,具體的是由交互細(xì)化,是分工不同的結(jié)果,如果PD同時兼UE,是不是這個就可以是直接的原型圖輸出?
這個是在原型產(chǎn)出之前 PM進(jìn)行結(jié)構(gòu)梳理用的 不過這種方法有些老了 費(fèi)事費(fèi)時
不過案例很不錯,學(xué)習(xí)的榜樣~!
業(yè)務(wù)流程圖不是要涉及的各個利益相關(guān)者,多個業(yè)務(wù)方嗎?所以業(yè)務(wù)流程圖一般用泳道圖表示吧?感覺功能架構(gòu)圖和業(yè)務(wù)流程圖在文章里有點(diǎn)點(diǎn)亂。。
說的是呢 , 讓你見笑了 我現(xiàn)在已經(jīng)不這么畫了
寫的很好,這樣的文章很受用。 ?
還是分不太清頁面流程和操作流程質(zhì)的區(qū)別
頁面流程的重點(diǎn)在于 各頁面之間的跳轉(zhuǎn)關(guān)系
操作流程的重點(diǎn)在于 用戶為了實現(xiàn)某個目的時,完成的一系列操作流程
告訴你個秘密~其實好多圖我沒看,只看最后的總結(jié)
然后呢,有什么想分享的嗎?
樓主輸出這么多流程圖,需要多久時間?fulltime應(yīng)該需要至少3天吧?
操作流程圖+8個,頁面流程+4個 一共花了3天