編輯導讀：B端產品設計千頭萬緒，在對業務場景非常熟悉的基礎上，還要求對技術實現、資源管理有一定的認知。本文作者從B端零售業中訂單軌跡這一小功能的設計出發，來分享一下自己對B端設計的思考，希望對你有幫助。
筆者目前在負責一個O2O訂單中臺產品，產品的主要功能為：聚合分發訂單以實現訂單的履約，所謂聚合，是獲取了美團外賣，餓百，有贊等公域和私域的O2O訂單，進行了訂單資料的一致化標準化。所謂分發，是將資料一致化後的訂單分發至門店作業系統，聚合物流系統，ERP系統，統一進行標準化揀貨作業，標準化配送，標準化記賬與庫存管理。
接下來我們瞭解一下訂單軌跡日誌是什麼：
對於B端產品來說，可用性是產品的基礎，可用性一般指兩個方面：
- 解決方案能夠解決企業問題；
- 系統可持續穩定的執行；在產品運營過程中，客戶反饋產品不可用，可能並不是業務解決方案有問題。
而監控是降低運維成本，保證系統穩定執行的有效手段，在B端產品中，監控一般分為兩個方面:
- 業務監控：如訂單軌跡日誌，憑證生成監控等，這些功能本質是對服務層的關鍵節點的轉義描述-問題定義與預警
- 系統監控：如資料庫資源監控，redis監控等，這些功能本質是對儲存層的執行情況的描述與預警；
那麼我們可以看出，訂單日誌軌跡是B端產品中的一個業務監控功能。那麼訂單軌跡日誌作為一個監控功能是怎麼幫助我們降低運維成本，保證系統穩定執行的呢，就像我們剛剛在業務監控功能本質上描述的一樣，主要體現在兩個方面：
- 關鍵節點的轉義描述：以發生時間正序視覺化展示訂單狀態的變更，節省運維過程中查詢資料庫的時間，降低理解資料庫中編碼的含義的難度。同時在運維過程中可以清晰的判斷訂單的業務進行是否正常；
- 問題定義與預警：如訂單未正常同步狀態，或者退單長時間沒有被稽核，可能會造成財務憑證的生成的延遲，造成對賬與扣減庫存等一系列問題。故需要定義出什麼情況下需要識別為問題，並自動進行提醒相關人員，減少運維過程中面對大量訂單無法進行便捷的識別問題的現象。
總結以下，訂單軌跡日誌就是以發生時間正序展示訂單狀態變更及其變更原因，並提供異常預警的功能。
但是在設計過程中，也遇到了兩個問題。
一、系統的複雜性1.1 複雜系統中，目標使用者的定義該需求的來源方是組內的系統支援工程師，那目標使用者就是他嗎？透過使用者訪談並查閱了工單系統中類似問題的反映數量及在各個專案的分佈，我們發現，對於使用者側的運營人員，訂單軌跡日誌功能也是他們普遍的訴求。由此可見，需求的來源方可能並不是唯一的目標使用者。這就要求我們在B端設計過程中，對現實世界進行抽象。
使用者一般具有過多與當前業務無關的屬性，如認知水平，個人喜好（B端產品主要依靠最佳化業務流程的各個節點來最終實現提高效率的訴求，實際作業系統的使用者作為系統的一個節點，往往由於產品策略選擇，必須被要求具備相適應的認知水平和操作方式等，如財務系統操作人員必須具備基礎的財務知識，故在抽象B端產品的目標使用者時，一般不對具體物件認知水平，個人操作喜好等做重點的考量），需要進行剝離，抽象出普遍的使用者畫像，我們稱之為角色。抽離出角色後，我們接下來就可以很方便的針對運維支援的角色進行設計。
在訂單中臺系統中，由於涉及到很多系統的資料，實際我們在做關鍵節點的轉義描述過程，就是對資料進行一致化標準化的過程，一般可以按照以下思路進行：
資料收集→資料整理→資料展示
1.2.1 資料的收集
我們可以從具體業務場景和抽象的系統設計兩個層面進行了分析：
從業務場景分析：訂單軌跡日誌作為業務監控的一項功能，在實際使用場景中，需要提供兩個方面的資訊：
- 訂單的狀態變更：運維支援人員可以透過訂單狀態的描述，判斷業務流轉是否正常，狀態是 對某一物件一個時間段內業務進展的概括性描述；
- 造成訂單狀態變更的動作：當運維支援人員發現訂單狀態變更異常時，可以透過判斷造成訂單狀態變更的動作來判斷問題原因；
從系統設計層面分析：面向物件方法將時間看錯一個個相互獨立的個體，相互之間沒有因果關係，他們之間平時保持獨立，在某個外力的驅動下，物件之間才會依據某種規律相互傳遞資訊，這些互動構成一個業務場景。在訂單這個業務場景中，我們可以將外賣平臺，訂單中臺，ERP系統都視為一個物件。此時，當我們針對外賣平臺這個物件設計功能時，我們需要考慮以下三個方面：
- 物件描述：描述物件本身的屬性
- 輸入資訊：其他物件傳遞給訂單中臺的資訊，即造成訂單中臺本身屬性發生變化的外力
- 輸出資訊：訂單中臺傳遞給其他物件的資訊，即造成其他物件屬性發生變化的外力
得到以下初步的結果：
在B端行業，現有業務的技術實現方式會深刻影響到功能的設計，故通常在功能設計階段就需要和開發進行充分的互動，以確認我們單純從業務場景和系統設計兩個層面梳理的展示資料是否正確能夠描述訂單的軌跡，一方面是資源有限，要充分理解現有功能實現邏輯，避免對系統改造較大的設計，以控制開發成本；另一個方面，訂單軌跡日誌功能作為業務監控的一環，本身就是對服務層關鍵節點的描述，服務層的邏輯當然是開發同學更為熟悉。
透過和開發確認，我們發現了需要增刪的地方：
- 門店前臺系統中的資料是其自行呼叫訂單中臺介面進行的查詢，且不對訂單狀態造成影響，不應展示；
- ERP系統不會給訂單中臺系統主動推送資料，需要訂單中臺系統主動查詢，且不對訂單狀態造成影響，不應展示；
- 訂單系統會根據配置，自動實現狀態的變更，需要進行展示；
經過整理細化，展示的資料為（資料已脫敏）：
1.2.2 資料整理
當我們確認好要展示的資料後，我們需要按照一定的規則對資料進行整理，形成一致的標準化的文案，方便使用者閱讀。我們一般將【時間+描述+操作人】定義為一個元件，元件按照發生時間正序排列，形成完整的訂單軌跡日誌，如：
2020-11-11 13:46 推送【新訂單】訊息至訂單中臺 美團外賣
2020-11-11 13:47 自動同步訂單到 訂單中臺 訂單中臺
2020-11-11 13:47 訂單總狀態變為【門店作業中】 訂單中臺
2020-11-11 13:46 門店操作【揀貨完成】 門店前臺作業系統
2020-11-11 13:47 呼叫【美團配送】成功，運單號：100111 訂單中臺系統
2020-11-11 13:48 推送【騎手取貨】訊息至鼎力雲系統,騎手姓名：張 聚合物流系統
資料整理的原則是：
- 顆粒度適中：透過合併同類動作，去除重複動作，使得訂單軌跡日誌不至於過於囉嗦，如同步訂單狀態時，訂單中臺既會接收外賣平臺的訊息推送，也會在接收到訊息推送後主動呼叫外賣平臺介面查詢訂單狀態確認狀態是否為最新狀態，以保證在訂單狀態高頻變動的階段獲取正確的資料，這時就不需要展示如此的詳細，既展示訊息推送，也展示拉取的動作，只展示訊息推送的資料即可。
- 明確視角：應明確說明資訊的傳送者，接收者或者狀態變更的操作人是誰，以明確視角，不至於混亂
- 統一規則：同一類操作的文案需要保持一致，如【時間+推送【XXX】訊息至訂單中臺+操作人】描述其他系統向訂單中臺推送的資料
- 通俗易懂：不要使用技術語言，如回撥，JOB等，而是使用通俗易懂的語言進行描述；
1.2.3 資料展示
- 確定資訊優先順序：從資料整理的結果來看，一筆訂單的訂單軌跡日誌資料過多，需要判斷資訊的優先順序，優先展示重要的資訊。從使用場景來看，正常情況下只需要關注訂單狀態，異常的情況下才需要檢視造成訂單狀態變更的原因。故優先展示狀態資訊；
- 區分視角，貼切場景：由於存在訂單中臺接收的資料和推送給其他系統的資料,故決定採用將輸入和輸出的資料分開展示；
最終經過方案細化，展示效果示意圖如下：
如圖所示，訂單的建立是一個非同步的動作，會出現接收到新訂單訊息，鼎力雲中卻沒有建立訂單的問題，同樣的，也會出現狀態不同步的問題，針對此類情況，就必須先將問題定義出來，然後設定預警功能，從而保證業務的正常進行。此塊內容較多，下篇文章再詳細介紹。
產品功能隨著邊界的蔓延，邊際收益也在遞減，所以產品的功能是有邊界的。在【中臺產品經理寶典】一書中，作者提出：ROI(投資回報率)是衡量B端產品功能的標杆，產品經理必須考考慮一個功能的投入和收益
由上圖可知，為提高ROI，則必須在產品設計時減少投入，因為對於B端來說，收益不是特別好量化，那麼可行的方向就是：重點降低功能推廣成本，後期運維成本的同時壓縮開發成本，這就要求我們在產品設計時必須做以下工作：
確認哪些功能特性必須滿足，必須做的功能特性中，哪些優先做，以壓縮開發成本。
我們可以使用簡化版的KANO模型來進行分析：
- 可用性的功能特性必須實現，且優先實現，放在一期版本。如：展示基本的狀態和輸入輸出資料，以及預警功能；
- 易用性的功能特性必須實現，但優先度不高，放在二期版本。如：使用時間軸的方式進行資料的展示
- 超預期的功能特性選擇實現，優先度最低，放在需求池中。
訂單軌跡日誌功能借助尼爾森可用性原則最佳化互動體驗，以減少後期的運維成本和功能推廣使用的成本：
- 一致性和標準化：即在資料整理階段進行的展示形式的標準化和一致化，為使用者提供一致性的閱讀體驗，減少認知成本；
- 人性化幫助原則：在介面上提供了功能的使用說明；
充分理解現有功能實現邏輯，少做對系統改造較大的設計，以控制開發成本。
舉個例子，在整理門店前臺作業系統時，我們希望記錄某一個操作具體是門店的哪個人做的。但是由於之前的介面中併為定義具體的操作人欄位，門店前臺作業系統自然也無法將此值同步至訂單中臺系統。那麼我們就將這個功能特性先放棄了，計劃在後期針對這個場景做專門的需求，以防止需求的蔓延。
三、總結在B端產品設計過程中，由於B端產品本身的複雜性和資源有限性，導致我們在設計即使是一個小功能時，也必須進入深度的思考以回答做什麼以及怎麼做的問題，在這個過程中，還要兼顧業務，技術和商務，我們常常戲稱自己是在王八殼裡蓋立交橋，但是這也是B端產品設計的魅力吧。
本文由 @kathic 原創釋出於人人都是產品經理，未經許可，禁止轉載
題圖來自 Pexels，基於 CC0 協議