關于B端狀態流轉的思考

8 評論 13756 瀏覽 156 收藏 15 分鐘

編輯導讀:本文作者從狀態的定義出發,結合案例對狀態的作用進行了解讀,并詳細梳理了狀態流轉設計的方法和設計過程中需要注意的問題,與大家分享,希望通過此文能夠加深你對狀態流轉這一步驟的認識。

最近接到了這樣的需求:我們的業務后臺是供業務方創建和維護業務內容的。業務方在創建、變更、完成和中止業務時,需要對不同的業務進展進行變更,由部門主管和其他部門人員協同進行審批。業務方希望在業務后臺可以直接看到這項業務發起審批動作后的審批結果是否通過,并在業務后臺顯示這項業務當前進行到了哪個階段。

比如張三創建了一個業務,點擊了發起了審批的按鈕后,這項業務會進入到審批系統,等待審批人員對這項業務的查看和審批。

當在審批人還沒有進行審批時,他希望在業務后臺中可以感知到這項業務當前處于“審批中”;當張審批人員點擊了“審批通過”后,張三再進入到業務后臺中,可以感知到這項業務“審批通過”了。

由于我們的業務規則是,只有審批通過后的業務才是正式的業務,才會開展這項業務的后續進度。所以張三還希望知道這項業務是否開始了。

從上面的需求中我們可以發現,無論是審批結果還是業務進展,用戶想感知到的是一個環節當前所處的“結果”,感知到了結果才能有下一步的動作。就像我們在淘寶上購買了商品一樣,我們希望感知到的是商家是否發貨,商品是否在運輸中,商品是否已經送到站點;商家希望感知到的是買家是否付款,商品是否簽收。

向用戶傳達某種流程環節的“結果”,在產品設計中通常使用“狀態”字段來提供“向用戶反饋結果”的能力。

01 狀態的定義

“狀態”傳達的是一種信息,這種信息反饋的是用戶可以感知到的某種結果。狀態是由于滿足了某種條件而觸發產生的,被觸發的條件可能是由于用戶操作了某種動作或是滿足了某種規則。

打顆栗子:

我們都在淘寶上面買過東西,買完東西后最常進入的就是我的訂單,查看我們購買的東西當前所處的狀態。

在訂單頁我們可以看到不同的狀態,我們的訂單會置于這些狀態下,對應不同狀態的訂單向用戶傳遞著不同的信息,如下圖所示,我將訂單狀態用紅框框了出來:

“待付款”狀態下的訂單向用戶傳遞的信息是:我提交了訂單,但是我還沒有付款;“待發貨”是我付款后的訂單;“待收貨”是我的貨物,快遞公司已經攬收。

在訂單頁同一筆訂單會伴隨著不同條件的觸發而流轉到不同的狀態下。其中訂單從“待收貨”流轉到“待評價”狀態下的觸發條件有2種方式:一種是用戶通過操作觸發狀態切換:用戶主動點擊了“確認收貨”的按鈕后狀態會發生變更。另一種是通過滿足了淘寶的規則觸發狀態切換:淘寶規則為自狀態變更為“商家已發貨”狀態起,10天后,系統會自動確認收貨。當滿足該規則時,自動觸發切換狀態。

狀態作為給用戶反饋結果的字段,設計“狀態”部分時,產品經理要對狀態所對應的業務流程進行充分的調研,對“狀態”的劃分內容和不同狀態的產生條件規則,做到準確的界定。因為狀態對于用戶來說是非常重要的感知字段,設計的狀態與需求方達成共識,顯示的狀態才能便于用戶理解和感知,不會造成理解上的歧義和偏差,用戶理解起來不會感到困難。

02 狀態的作用

1. 狀態在產品中的主要作用是為了提升用戶體驗

產品中的進度狀態,本質是體現業務中不同的進度情況,狀態變更是按照業務進度變化的順序分別進行切換的。用戶通過狀態的變更感知到進度的進展情況,對完成目標之間的距離有一個心理預期,能夠及時掌握進度動態變化的信息,降低了用戶因等待和無法及時把控進度而產生的焦慮,進而提升了用戶體驗。

產品的結果狀態,本質是反饋一項業務流程最后的成功結果或失敗結果。成功結果代表著一件事已經做完了,反饋結果目的是讓用戶感知到,事情已經完成可以做下一件事了。失敗結果代表這件事情沒有做完,做的不對,需要繼續處理,目的是讓用戶解決問題。用戶根據狀態及時知曉結果反饋,幫助用戶做出有效決策,提升用戶體驗。

2. 狀態在產品中也有觸發用戶產生行為的作用

狀態的本質是傳遞信息,在某些場景下也是觸發用戶產生行為的條件。

拼多多助力免費送商品的活動、12306助力搶票的場景中,我們能看到,免費送的商品和未到手的火車票,狀態都是還差多少值(百分比、多少人)助力,就可以到手了。通過狀態信息,引導用戶產生在朋友圈分享的行為,以及讓用戶的朋友們產生助力的點擊行為。

用戶能夠通過狀態反饋出來的信息產生感受,觸發用戶產生行為。在設計狀態的過程中我們需要推演設計的狀態是否真正達到預期希望用戶產生的感受和行為。

03 狀態流轉設計方法

關于狀態的流轉部分的設計,可以按照下圖表格形式的方法進行3個方面的思考,將表格補充填寫完畢后,狀態流轉也就基本搞定了。這張表一共有四個字段,分別是“任務狀態”、“可用操作”、“遷移條件”和“狀態說明”。

我們將狀態名稱按照流轉的邏輯順序寫到“任務狀態”里,狀態下可以使用的用戶操作寫到“可用操作”中,狀態流轉的觸發條件規則寫到“遷移條件”里,狀態的定義寫到“狀態說明”中。

1. 定義狀態和不同狀態下的可用操作枚舉

上圖任務狀態部分是我們通過調研一項業務流程后,梳理出來的狀態內容。

第一步:我們對一個業務的某個環節不同狀態進行一個界定,列出互斥的狀態有哪些。我們要列舉的狀態是根據不同的觸發進行流轉的、且互斥的,在列舉中我們會去判斷這些狀態之間是否有上下游關聯,是否互斥。

第二步:我們對不同狀態的狀態結合我們的義務進行定義,對這些狀態進行定義的原因是它可以幫助我們二次校驗這些狀態的關聯關系,也可以讓我們與開發同學之間對狀態的定義達成共識。

第三步:將所有底層的用戶動作進行梳理,比如點擊XXX按鈕,先將全部的按鈕都梳理出來,然后將不同狀態可以做哪些動作,用藍色展示,因為藍色與B端后臺的按鈕更像,符合用戶習慣,將無法操作的動作,用灰色展示,因為無法操作按鈕顯示出來一般置灰。都梳理出來是為了避免遺漏。

第四步:將這些動作梳理出來后,我們就可以去做遷移條件的界定了。遷移條件可能是觸發了某個按鈕,可能是根據某種狀態觸發的,也可能會更復雜一些,更具某個按鈕,且某種狀態發生了變化后才會觸發遷移。但是當我們將動作和狀態都梳理好后,再界定遷移條件,就不會有遺漏條件。

當遇到復雜邏輯的狀態遷移時,比如狀態1是初始狀態,當在狀態1時,這條數據被點擊按鈕1后, 狀態1發生變化,同時觸發了狀態2的變化,但是狀態1是根據按鈕和狀態2的變化來影響狀態1的變化的。

2. 定義狀態流轉的順序

一般我們會將狀態的流轉以狀態轉移圖表形式進行繪制,避免邏輯缺失。狀態機就是狀態轉移圖。

狀態機四要素

狀態機可歸納為4個要素,即現態、條件、動作、次態。這樣的歸納,主要是出于對狀態機 的內在因果關系的考慮?!艾F態”和“條件”是因,“動作”和“次態”是果。

  1. 現態:是指當前所處的狀態。
  2. 條件:又稱為“事件”,當一個條件被滿足,將會觸發一個動作,或者執行一次狀態的遷移。
  3. 動作:條件滿足后執行的動作。動作執行完畢后,可以遷移到新的狀態,也可以仍舊保持原狀態。動作不是必需的,當條件滿足后,也可以不執行任何動作,直接遷移到新狀態。
  4. 次態:條件滿足后要遷往的新狀態?!按螒B”是相對于“現態”而言的,“次態”一旦被激活, 就轉變成新的“現態”了。

狀態機分為有限狀態機和無限狀態機。

  • 有限狀態機是指輸出取決于過去輸入部分和當前輸入部分的時序邏輯電路,有限狀態機可以確定狀態的個數,比如人的某種狀態。
  • 無限狀態機不知道是否正規的說法,從狀態機上理解就是輸出取決于輸入與當前狀態,但是當前狀態是無限的,不能確定其個數,比如人所在的位置。一般不使用。

一般狀態的始態是“待開始”,遷移狀態變更為“進行中”,最終的狀態為“完成/中止”。

當業務中有狀態存在時,我們可以優先將業務狀態做成有限狀態機來描述,邏輯會很順暢完整,避免因為狀態復雜而丟失邏輯的情況,也會方便研發同學理解。

打顆栗子:

假如張大胖去飯店吃飯,進飯店“待用餐”是狀態1,點餐是動作1,點餐動作觸發后,觸發了狀態2:待烹飪-烹飪中-烹飪完成,當烹飪完成之后,狀態1才會發生變化,“待用餐”變成“用餐中”,最后變為“用餐完成”。為了避免遺漏邏輯,可以再做一個多狀態變化的遷移表。如下圖:

總結

狀態流轉是一項業務某一個環節/任務的生命周期,狀態流轉邏輯是這個業務環節的底層邏輯,我們在輸出原型前,將狀態遷移表搭建好會避免狀態和條件的遺漏。

狀態遷移表建立后可以與業務方多去探討和改善,在生命周期中達成更深的理解和共識。

當根據狀態遷移表做完原型和交互后,自己需要進行校驗,看看是否有遺漏的邏輯。

校驗的標準就是將自己當成小白,使用實際的資料在自己的原型上跑一遍,自己過的沒有問題后, 如果有條件,讓業務方根據實際業務也幫助跑一遍看看是否有問題。

參考鏈接:

《深入淺出理解有限狀態機》鏈接為https://zhuanlan.zhihu.com/p/46347732

#專欄作家#

暮暮,公眾號:財務產品人,人人都是產品經理專欄作家。擁有好奇心且極度認真的產品同學。擁有財務理論知識和財務產品經驗,目前在醫療健康領域,擅長中臺產品設計。

本文原創發布于人人都是產品經理,未經作者許可,禁止轉載

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 很受用,感謝!

    來自北京 回復
  2. 狀態和標簽,有什么區別嗎?

    來自廣東 回復
  3. 如果有統一流程中不同角色對應同一狀態的不同顯示的梳理方式就更完美了

    來自上海 回復
  4. 好東西,說的最清楚的方法。

    來自上海 回復
  5. 公眾號改名啦:禾暮暮

    回復
    1. 之前叫什么?

      來自浙江 回復
  6. 這個比較實用

    來自北京 回復
    1. 謝謝熊熊

      回復