編輯導(dǎo)讀：B端產(chǎn)品設(shè)計(jì)千頭萬(wàn)緒，一個(gè)小功能往往業(yè)需要進(jìn)行很復(fù)雜的思考，本文作者從B端零售業(yè)中訂單軌跡這一小功能的設(shè)計(jì)出發(fā)，來(lái)分享一下自己對(duì)B端產(chǎn)品功能設(shè)計(jì)的思考，希望對(duì)你有幫助。

筆者目前在負(fù)責(zé)一個(gè)O2O訂單中臺(tái)產(chǎn)品，產(chǎn)品的主要功能為：聚合分發(fā)訂單以實(shí)現(xiàn)訂單的履約，所謂聚合，是獲取了美團(tuán)外賣(mài)，餓百，有贊等公域和私域的O2O訂單，進(jìn)行了訂單數(shù)據(jù)的一致化標(biāo)準(zhǔn)化。所謂分發(fā)，是將數(shù)據(jù)一致化后的訂單分發(fā)至門(mén)店作業(yè)系統(tǒng)，聚合物流系統(tǒng)，ERP系統(tǒng)，統(tǒng)一進(jìn)行標(biāo)準(zhǔn)化揀貨作業(yè)，標(biāo)準(zhǔn)化配送，標(biāo)準(zhǔn)化記賬與庫(kù)存管理。

接下來(lái)我們了解一下訂單軌跡日志是什么：

對(duì)于B端產(chǎn)品來(lái)說(shuō)，可用性是產(chǎn)品的基礎(chǔ)，可用性一般指兩個(gè)方面：

1. 解決方案能夠解決企業(yè)問(wèn)題；
2. 系統(tǒng)可持續(xù)穩(wěn)定的運(yùn)行；在產(chǎn)品運(yùn)營(yíng)過(guò)程中，客戶(hù)反饋產(chǎn)品不可用，可能并不是業(yè)務(wù)解決方案有問(wèn)題。

而監(jiān)控是降低運(yùn)維成本，保證系統(tǒng)穩(wěn)定運(yùn)行的有效手段，在B端產(chǎn)品中，監(jiān)控一般分為兩個(gè)方面:

1. 業(yè)務(wù)監(jiān)控：如訂單軌跡日志，憑證生成監(jiān)控等，這些功能本質(zhì)是對(duì)服務(wù)層的關(guān)鍵節(jié)點(diǎn)的轉(zhuǎn)義描述-問(wèn)題定義與預(yù)警
2. 系統(tǒng)監(jiān)控：如數(shù)據(jù)庫(kù)資源監(jiān)控，redis監(jiān)控等，這些功能本質(zhì)是對(duì)存儲(chǔ)層的運(yùn)行情況的描述與預(yù)警；

那么我們可以看出，訂單日志軌跡是B端產(chǎn)品中的一個(gè)業(yè)務(wù)監(jiān)控功能。那么訂單軌跡日志作為一個(gè)監(jiān)控功能是怎么幫助我們降低運(yùn)維成本，保證系統(tǒng)穩(wěn)定運(yùn)行的呢，就像我們剛剛在業(yè)務(wù)監(jiān)控功能本質(zhì)上描述的一樣，主要體現(xiàn)在兩個(gè)方面：

1. 關(guān)鍵節(jié)點(diǎn)的轉(zhuǎn)義描述：以發(fā)生時(shí)間正序可視化展示訂單狀態(tài)的變更，節(jié)省運(yùn)維過(guò)程中查詢(xún)數(shù)據(jù)庫(kù)的時(shí)間，降低理解數(shù)據(jù)庫(kù)中編碼的含義的難度。同時(shí)在運(yùn)維過(guò)程中可以清晰的判斷訂單的業(yè)務(wù)進(jìn)行是否正常；
2. 問(wèn)題定義與預(yù)警：如訂單未正常同步狀態(tài)，或者退單長(zhǎng)時(shí)間沒(méi)有被審核，可能會(huì)造成財(cái)務(wù)憑證的生成的延遲，造成對(duì)賬與扣減庫(kù)存等一系列問(wèn)題。故需要定義出什么情況下需要識(shí)別為問(wèn)題，并自動(dòng)進(jìn)行提醒相關(guān)人員，減少運(yùn)維過(guò)程中面對(duì)大量訂單無(wú)法進(jìn)行便捷的識(shí)別問(wèn)題的現(xiàn)象。

總結(jié)以下，訂單軌跡日志就是以發(fā)生時(shí)間正序展示訂單狀態(tài)變更及其變更原因，并提供異常預(yù)警的功能。該功能的業(yè)務(wù)背景和解決方案是清晰的，在中臺(tái)系統(tǒng)中，相較于其他功能，訂單軌跡日志是一個(gè)很小的功能，但是小功能在設(shè)計(jì)過(guò)程中，也經(jīng)歷了很復(fù)雜的思考。

原因在于：

1、B端零售業(yè)訂單中臺(tái)系統(tǒng)的復(fù)雜性；

2、B端系統(tǒng)功能設(shè)計(jì)過(guò)程中的資源有限性；

接下來(lái)，我從這兩個(gè)方面給大家介紹，這兩個(gè)屬性帶來(lái)的一些我們不得不去進(jìn)行思考的點(diǎn)；

一、系統(tǒng)的復(fù)雜性

1.1? 復(fù)雜系統(tǒng)中，目標(biāo)用戶(hù)的定義

該需求的來(lái)源方是組內(nèi)的系統(tǒng)支持工程師，那目標(biāo)用戶(hù)就是他嗎？通過(guò)用戶(hù)訪談并查閱了工單系統(tǒng)中類(lèi)似問(wèn)題的反映數(shù)量及在各個(gè)項(xiàng)目的分布，我們發(fā)現(xiàn)，對(duì)于用戶(hù)側(cè)的運(yùn)營(yíng)人員，訂單軌跡日志功能也是他們普遍的訴求。由此可見(jiàn)，需求的來(lái)源方可能并不是唯一的目標(biāo)用戶(hù)。這就要求我們?cè)贐端設(shè)計(jì)過(guò)程中，對(duì)現(xiàn)實(shí)世界進(jìn)行抽象。

用戶(hù)一般具有過(guò)多與當(dāng)前業(yè)務(wù)無(wú)關(guān)的屬性，如認(rèn)知水平，個(gè)人喜好（B端產(chǎn)品主要依靠?jī)?yōu)化業(yè)務(wù)流程的各個(gè)節(jié)點(diǎn)來(lái)最終實(shí)現(xiàn)提高效率的訴求，實(shí)際操作系統(tǒng)的用戶(hù)作為系統(tǒng)的一個(gè)節(jié)點(diǎn)，往往由于產(chǎn)品策略選擇，必須被要求具備相適應(yīng)的認(rèn)知水平和操作方式等，如財(cái)務(wù)系統(tǒng)操作人員必須具備基礎(chǔ)的財(cái)務(wù)知識(shí)，故在抽象B端產(chǎn)品的目標(biāo)用戶(hù)時(shí)，一般不對(duì)具體對(duì)象認(rèn)知水平，個(gè)人操作喜好等做重點(diǎn)的考量），需要進(jìn)行剝離，抽象出普遍的用戶(hù)畫(huà)像，我們稱(chēng)之為角色。抽離出角色后，我們接下來(lái)就可以很方便的針對(duì)運(yùn)維支持的角色進(jìn)行設(shè)計(jì)。

1.2? 復(fù)雜系統(tǒng)中，關(guān)鍵節(jié)點(diǎn)如何轉(zhuǎn)義描述

在訂單中臺(tái)系統(tǒng)中，由于涉及到很多系統(tǒng)的數(shù)據(jù)，實(shí)際我們?cè)谧鲫P(guān)鍵節(jié)點(diǎn)的轉(zhuǎn)義描述過(guò)程，就是對(duì)數(shù)據(jù)進(jìn)行一致化標(biāo)準(zhǔn)化的過(guò)程，一般可以按照以下思路進(jìn)行：

數(shù)據(jù)收集→數(shù)據(jù)整理→數(shù)據(jù)展示

1.2.1 數(shù)據(jù)的收集

我們可以從具體業(yè)務(wù)場(chǎng)景和抽象的系統(tǒng)設(shè)計(jì)兩個(gè)層面進(jìn)行了分析：

從業(yè)務(wù)場(chǎng)景分析：訂單軌跡日志作為業(yè)務(wù)監(jiān)控的一項(xiàng)功能，在實(shí)際使用場(chǎng)景中，需要提供兩個(gè)方面的信息：

1. 訂單的狀態(tài)變更：運(yùn)維支持人員可以通過(guò)訂單狀態(tài)的描述，判斷業(yè)務(wù)流轉(zhuǎn)是否正常，狀態(tài)是 對(duì)某一對(duì)象一個(gè)時(shí)間段內(nèi)業(yè)務(wù)進(jìn)展的概括性描述；
2. 造成訂單狀態(tài)變更的動(dòng)作：當(dāng)運(yùn)維支持人員發(fā)現(xiàn)訂單狀態(tài)變更異常時(shí)，可以通過(guò)判斷造成訂單狀態(tài)變更的動(dòng)作來(lái)判斷問(wèn)題原因；

從系統(tǒng)設(shè)計(jì)層面分析：面向?qū)ο蠓椒▽r(shí)間看錯(cuò)一個(gè)個(gè)相互獨(dú)立的個(gè)體，相互之間沒(méi)有因果關(guān)系，他們之間平時(shí)保持獨(dú)立，在某個(gè)外力的驅(qū)動(dòng)下，對(duì)象之間才會(huì)依據(jù)某種規(guī)律相互傳遞信息，這些交互構(gòu)成一個(gè)業(yè)務(wù)場(chǎng)景。在訂單這個(gè)業(yè)務(wù)場(chǎng)景中，我們可以將外賣(mài)平臺(tái)，訂單中臺(tái)，ERP系統(tǒng)都視為一個(gè)對(duì)象。此時(shí)，當(dāng)我們針對(duì)外賣(mài)平臺(tái)這個(gè)對(duì)象設(shè)計(jì)功能時(shí)，我們需要考慮以下三個(gè)方面：

1. 對(duì)象描述：描述對(duì)象本身的屬性
2. 輸入信息：其他對(duì)象傳遞給訂單中臺(tái)的信息，即造成訂單中臺(tái)本身屬性發(fā)生變化的外力
3. 輸出信息：訂單中臺(tái)傳遞給其他對(duì)象的信息，即造成其他對(duì)象屬性發(fā)生變化的外力

得到以下初步的結(jié)果：

在B端行業(yè)，現(xiàn)有業(yè)務(wù)的技術(shù)實(shí)現(xiàn)方式會(huì)深刻影響到功能的設(shè)計(jì)，故通常在功能設(shè)計(jì)階段就需要和開(kāi)發(fā)進(jìn)行充分的互動(dòng)，以確認(rèn)我們單純從業(yè)務(wù)場(chǎng)景和系統(tǒng)設(shè)計(jì)兩個(gè)層面梳理的展示數(shù)據(jù)是否正確能夠描述訂單的軌跡，一方面是資源有限，要充分理解現(xiàn)有功能實(shí)現(xiàn)邏輯，避免對(duì)系統(tǒng)改造較大的設(shè)計(jì)，以控制開(kāi)發(fā)成本；另一個(gè)方面，訂單軌跡日志功能作為業(yè)務(wù)監(jiān)控的一環(huán)，本身就是對(duì)服務(wù)層關(guān)鍵節(jié)點(diǎn)的描述，服務(wù)層的邏輯當(dāng)然是開(kāi)發(fā)同學(xué)更為熟悉。

通過(guò)和開(kāi)發(fā)確認(rèn)，我們發(fā)現(xiàn)了需要增刪的地方：

1. 門(mén)店前臺(tái)系統(tǒng)中的數(shù)據(jù)是其自行調(diào)用訂單中臺(tái)接口進(jìn)行的查詢(xún)，且不對(duì)訂單狀態(tài)造成影響，不應(yīng)展示；
2. ERP系統(tǒng)不會(huì)給訂單中臺(tái)系統(tǒng)主動(dòng)推送數(shù)據(jù)，需要訂單中臺(tái)系統(tǒng)主動(dòng)查詢(xún)，且不對(duì)訂單狀態(tài)造成影響，不應(yīng)展示；
3. 訂單系統(tǒng)會(huì)根據(jù)配置，自動(dòng)實(shí)現(xiàn)狀態(tài)的變更，需要進(jìn)行展示；

經(jīng)過(guò)整理細(xì)化，展示的數(shù)據(jù)為（數(shù)據(jù)已脫敏）：

1.2.2 數(shù)據(jù)整理

當(dāng)我們確認(rèn)好要展示的數(shù)據(jù)后，我們需要按照一定的規(guī)則對(duì)數(shù)據(jù)進(jìn)行整理，形成一致的標(biāo)準(zhǔn)化的文案，方便用戶(hù)閱讀。我們一般將【時(shí)間+描述+操作人】定義為一個(gè)元件，元件按照發(fā)生時(shí)間正序排列，形成完整的訂單軌跡日志，如：

2020-11-11 13:46 推送【新訂單】消息至訂單中臺(tái)? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?美團(tuán)外賣(mài)

2020-11-11 13:47 自動(dòng)同步訂單到 訂單中臺(tái)? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?訂單中臺(tái)

2020-11-11 13:47 訂單總狀態(tài)變?yōu)椤鹃T(mén)店作業(yè)中】? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 訂單中臺(tái)

2020-11-11 13:46 門(mén)店操作【揀貨完成】? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 門(mén)店前臺(tái)作業(yè)系統(tǒng)

2020-11-11 13:47 呼叫【美團(tuán)配送】成功，運(yùn)單號(hào)：100111? ? ? ? ? ? ? ? ? 訂單中臺(tái)系統(tǒng)

2020-11-11 13:48 推送【騎手取貨】消息至鼎力云系統(tǒng),騎手姓名：張? ? ?聚合物流系統(tǒng)

數(shù)據(jù)整理的原則是：

• 顆粒度適中：通過(guò)合并同類(lèi)動(dòng)作，去除重復(fù)動(dòng)作，使得訂單軌跡日志不至于過(guò)于啰嗦，如同步訂單狀態(tài)時(shí)，訂單中臺(tái)既會(huì)接收外賣(mài)平臺(tái)的消息推送，也會(huì)在接收到消息推送后主動(dòng)調(diào)用外賣(mài)平臺(tái)接口查詢(xún)訂單狀態(tài)確認(rèn)狀態(tài)是否為最新?tīng)顟B(tài)，以保證在訂單狀態(tài)高頻變動(dòng)的階段獲取正確的數(shù)據(jù)，這時(shí)就不需要展示如此的詳細(xì)，既展示消息推送，也展示拉取的動(dòng)作，只展示消息推送的數(shù)據(jù)即可。
• 明確視角：應(yīng)明確說(shuō)明信息的發(fā)送者，接收者或者狀態(tài)變更的操作人是誰(shuí)，以明確視角，不至于混亂
• 統(tǒng)一規(guī)則：同一類(lèi)操作的文案需要保持一致，如【時(shí)間+推送【XXX】消息至訂單中臺(tái)+操作人】描述其他系統(tǒng)向訂單中臺(tái)推送的數(shù)據(jù)
• 通俗易懂：不要使用技術(shù)語(yǔ)言，如回調(diào)，JOB等，而是使用通俗易懂的語(yǔ)言進(jìn)行描述；

1.2.3 數(shù)據(jù)展示

• 確定信息優(yōu)先級(jí)：從數(shù)據(jù)整理的結(jié)果來(lái)看，一筆訂單的訂單軌跡日志數(shù)據(jù)過(guò)多，需要判斷信息的優(yōu)先級(jí)，優(yōu)先展示重要的信息。從使用場(chǎng)景來(lái)看，正常情況下只需要關(guān)注訂單狀態(tài)，異常的情況下才需要查看造成訂單狀態(tài)變更的原因。故優(yōu)先展示狀態(tài)信息；
• 區(qū)分視角，貼切場(chǎng)景：由于存在訂單中臺(tái)接收的數(shù)據(jù)和推送給其他系統(tǒng)的數(shù)據(jù),故決定采用將輸入和輸出的數(shù)據(jù)分開(kāi)展示；

最終經(jīng)過(guò)方案細(xì)化，展示效果示意圖如下：

1.3 復(fù)雜系統(tǒng)中，如何進(jìn)行問(wèn)題的定義與預(yù)警功能的設(shè)計(jì)

如圖所示，訂單的創(chuàng)建是一個(gè)異步的動(dòng)作，會(huì)出現(xiàn)接收到新訂單消息，鼎力云中卻沒(méi)有創(chuàng)建訂單的問(wèn)題，同樣的，也會(huì)出現(xiàn)狀態(tài)不同步的問(wèn)題，針對(duì)此類(lèi)情況，就必須先將問(wèn)題定義出來(lái)，然后設(shè)置預(yù)警功能，從而保證業(yè)務(wù)的正常進(jìn)行。此塊內(nèi)容較多，下篇文章再詳細(xì)介紹。

二、資源的有限性

產(chǎn)品功能隨著邊界的蔓延，邊際收益也在遞減，所以產(chǎn)品的功能是有邊界的。在【中臺(tái)產(chǎn)品經(jīng)理寶典】一書(shū)中，作者提出：ROI(投資回報(bào)率)是衡量B端產(chǎn)品功能的標(biāo)桿，產(chǎn)品經(jīng)理必須考考慮一個(gè)功能的投入和收益

由上圖可知，為提高ROI，則必須在產(chǎn)品設(shè)計(jì)時(shí)減少投入，因?yàn)閷?duì)于B端來(lái)說(shuō)，收益不是特別好量化，那么可行的方向就是：重點(diǎn)降低功能推廣成本，后期運(yùn)維成本的同時(shí)壓縮開(kāi)發(fā)成本，這就要求我們?cè)诋a(chǎn)品設(shè)計(jì)時(shí)必須做以下工作：

確認(rèn)哪些功能特性必須滿(mǎn)足，必須做的功能特性中，哪些優(yōu)先做，以壓縮開(kāi)發(fā)成本。

我們可以使用簡(jiǎn)化版的KANO模型來(lái)進(jìn)行分析：

• 可用性的功能特性必須實(shí)現(xiàn)，且優(yōu)先實(shí)現(xiàn)，放在一期版本。如：展示基本的狀態(tài)和輸入輸出數(shù)據(jù)，以及預(yù)警功能；
• 易用性的功能特性必須實(shí)現(xiàn)，但優(yōu)先度不高，放在二期版本。如：使用時(shí)間軸的方式進(jìn)行數(shù)據(jù)的展示
• 超預(yù)期的功能特性選擇實(shí)現(xiàn)，優(yōu)先度最低，放在需求池中。

訂單軌跡日志功能借助尼爾森可用性原則優(yōu)化交互體驗(yàn)，以減少后期的運(yùn)維成本和功能推廣使用的成本：

• 一致性和標(biāo)準(zhǔn)化：即在數(shù)據(jù)整理階段進(jìn)行的展示形式的標(biāo)準(zhǔn)化和一致化，為用戶(hù)提供一致性的閱讀體驗(yàn)，減少認(rèn)知成本；
• 人性化幫助原則：在界面上提供了功能的使用說(shuō)明；

充分理解現(xiàn)有功能實(shí)現(xiàn)邏輯，少做對(duì)系統(tǒng)改造較大的設(shè)計(jì)，以控制開(kāi)發(fā)成本。

舉個(gè)例子，在整理門(mén)店前臺(tái)作業(yè)系統(tǒng)時(shí)，我們希望記錄某一個(gè)操作具體是門(mén)店的哪個(gè)人做的。但是由于之前的接口中并為定義具體的操作人字段，門(mén)店前臺(tái)作業(yè)系統(tǒng)自然也無(wú)法將此值同步至訂單中臺(tái)系統(tǒng)。那么我們就將這個(gè)功能特性先放棄了，計(jì)劃在后期針對(duì)這個(gè)場(chǎng)景做專(zhuān)門(mén)的需求，以防止需求的蔓延。

三、總結(jié)

在B端產(chǎn)品設(shè)計(jì)過(guò)程中，由于B端產(chǎn)品本身的復(fù)雜性和資源有限性，導(dǎo)致我們?cè)谠O(shè)計(jì)即使是一個(gè)小功能時(shí)，也必須進(jìn)入深度的思考以回答做什么以及怎么做的問(wèn)題，在這個(gè)過(guò)程中，還要兼顧業(yè)務(wù)，技術(shù)和商務(wù)，我們常常戲稱(chēng)自己是在王八殼里蓋立交橋，但是這也是B端產(chǎn)品設(shè)計(jì)的魅力吧。

本文由 @kathic 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來(lái)自 Pexels，基于 CC0 協(xié)議