在電商業務中，需求的復雜性常常讓人望而生畏。為了讓用戶在實際使用時能有更好的體驗，設計師需要先理解需求，再將其轉化為清晰易懂的內容。而在面向多個角色/場景進行設計時，是否會遇到細節的遺漏？或者遇到角色間有錯綜復雜的關系難以應對？

電商設計干貨：

復雜系統便是需求的難點所在，我將分享嘗試使用 C4 模型對復雜需求進行拆解，幫助設計師理清角色關系與細節，避免遺漏。

本期提綱：

1. 什么是復雜系統？
2. 如何拆解復雜系統？
3. 寫在最后

一、什么是復雜系統？

維基百科：“復雜系統（complex system），又稱復合系統，是指由許多可能相互作用的組成成分所組成的系統。”

這種非線性的系統在日常生活中很常見，比如全球氣候、交通、通訊系統等基礎設施網絡、城市社會和經濟組織。

地球碳循環

這些系統的集合不是簡單的每個部分行為的總和，理解復雜系統就是理解系統的部分以及部分間的關系。

而電商系統是個復雜系統，除了消費者接觸到商品店鋪、物流系統和售后管理以外，還包括賣家如何入駐平臺的進件系統，商品的管理系統，運營分析的數據系統等等。

二、如何拆解復雜系統？

“以特定的順序引導我的思維，從最簡單和最容易理解的對象開始，一步一步逐漸上升，直至最復雜的知識。”——笛卡爾

在設計方案前可使用 C4 模型進行拆解。C4 模型是一種用于描述和傳達軟件系統結構的模型，由“Context（上下文）、Container（容器）、Component（組件）、Code（代碼）”四個抽象層次組成。

通過 C4 模型，我們可以從宏觀到微觀，逐步深入地理解系統的各個部分以及它們之間的關系。

C4 架構圖

就像地圖，隨著放大可以逐漸看清國家之間的界限，省和市的包含關系，道路的布局。

Googlemap

該模型最大的好處是可以幫助我們將問題與關注點分級，不是一個層面的問題，不要在同個層面解決。

原模型是通過架構的視角進行表述的，而作為設計師，我將 C4 模型轉換成設計視角下的“系統上下文、功能、流程、頁面”這四個層級幫助我拆解復雜。接下來將通過單個模塊的展開對模型的實際應用進行分享，僅用于拋磚引玉。

1. 系統上下文

這一重點關注事件在系統中的運行情況。即需求核心系統與其他系統、角色的關系，這是需求分析至關重要的一步。我們可以通過“Who（誰）/What（什么）/When（何時）/Where（何地）/Why（為何）/How（如何）”等問題來解析。

例如，我們需要設計一個直播間「抽獎實物商品」的功能，以滿足直播商家的運營需求，為商家提供快速設置獎品并發貨給中獎觀眾的能力，讓觀眾在中獎后可以及時收到中獎商品。

who 觀眾和商家

what 抽獎

when 在直播過程中

where 直播間

why 商家通過抽獎行為轉化觀眾，提高用戶粘性；用戶通過抽獎獲利。

how 觀眾參與抽獎后中獎，商家發貨給中獎觀眾。

我們可以用圖示意，為后續復雜的展開確定了基礎框架。

2. 功能

通過上下文整理出框架后，下一步我們需要站在各視角下枚舉與之相關的所有功能流程。該步驟可根據實際需求選擇合適的維度作為枚舉依據。在直播間抽獎這個需求里，我選擇了事件發展的時間序推演功能任務。

例如，商家在抽獎活動事前、事中、事后都有各階段的重點功能：

事前- 小店商家和帶貨達人，分別準備好用于抽獎的商品「商品管理功能」

事中- 設置抽獎規則「直播間抽獎」

事后- 發貨給中獎觀眾「訂單/配送功能」

而觀眾在抽獎活動事前、事中、事后也有各階段的重點功能：

事前- 觀看直播參與抽獎「參與抽獎功能」

事中- 中獎提交發貨信息「下單功能」

事后- 訂單中心管理中獎訂單物流狀態「訂單/售后功能」

這一步無需關注具體的判斷、細節，用具有統領性質的功能去串聯主線。

通過整理可以發現，區別于擁有自己店鋪的商家，帶貨達人是沒有自己的商品和發貨系統的。因此為了抽獎實體商品，需要為達人單獨設計抽獎商品管理、訂單配送功能。

商品管理和訂單配送便是在「商家」端的重點功能，為提高商家體驗，我們需要在兩個功能的主流程里更關注提效。觀眾在下單之后，區別于普通購買的商品訂單，中獎訂單是需要能被一眼識別的。

3. 流程

我們對功能梳理完畢后，便可以著手流程的梳理，這一步驟的拆解對最后的設計至關重要。在這個步驟里，我們關注的是單個功能中的主流程，以及功能間的交叉聯系。完成這一步后，復雜系統的脈絡便能清晰呈現。

我的方法是：當我們聚焦在單個功能時，可以嘗試將流程視作坐標軸。x 軸代表流程中的關系和順序，y 軸代表流程中單個節點的層次結構。

以訂單為例展開，商家視角下的中獎訂單按照流程順序來看：如果需要生成中獎訂單，會需要先有訂單信息、商品詳情、物流服務、個保隱私、售后服務等。按照單個節點的縱向結構，也可以通過訂單是否已發貨/已完成得出訂單狀態以及對應操作。

而商家的訂單狀態和行為將影響觀眾側的中獎訂單狀態，因此在觀眾視角下的中獎訂單也需要和商家側一一對應。

當拆解到這一步時，如果邏輯嚴謹，條理清晰，系統中的分支邏輯基本也能被囊括。

此時我們不妨回到上下文關系（context）里對角色/端的梳理，檢查信息對于其他角色/端是否有影響，影響是否和上下文中的聯系是一一對應的，重新審視結構是否具備完整性。

4. 頁面

理解設計目標才能最終產出滿足需求的具體頁面。需求目標經過以上結構拆解，分化出了不同的設計目標，不同的設計目標將指引設計師產出對應的頁面。

比如商家的目的是運營獲客。除了獎品具有吸引力可以讓觀眾抽獎以外，平臺需要為商家的發起、管理流程提供便捷操作，幫助商家快速發起抽獎。由此拆解的設計目標為「為商家提供提效工具」。

在抽獎流程中，為了幫助商家快速選中所需商品并發起抽獎，提供檢索和優化排序；在訂單管理流程提高發貨效率，根據待發貨狀態提供快捷操作。

而觀眾的目的是通過中獎獲利，免費體驗商品。因此需要在抽獎的過程給予正向反饋，中獎后及時引導下單。平臺需要為中獎的訂單設計差異化，幫助中獎觀眾在自己的訂單列表中錨定中獎訂單。

因此設計目標便是「為觀眾提供差異化的訂單」。

每個模塊的重點有所不同，但需求目的不會變化。除了具體頁面具體設計以外，在前置的需求分析時可提前與開發進行技術方案的討論，多考慮既能滿足設計需求，又為代碼減負的實現方案。

5. 小結

讓我們再回顧一下 C4 模型的結構重點：

定義系統上下文：包括系目標、用戶需求、業務領域等。

定義系統功能：描述了系統的整體結構和組織方式。將系統劃分為不同的功能模塊，例如子系統、二級模塊、組件等，并明確它們之間的關系。

定義系統流程：按照功能模塊對功能內的流程線做橫向關系和順序，縱向單個節點的層次結構的梳理。

設計具體頁面：確定設計目標，轉化為具體頁面。

C4 模型在電商需求分析中最大的優勢在于逐級分層理解系統，系統中的角色關聯性可以被體現，且各角色下的重點與結構判斷不被遺漏。同時，我們可以提前與開發進行技術方案的討論，多考慮既能滿足設計需求，又能為代碼減負的實現方案。

寫在最后

整理并輸出一份完善的設計方案，能有效幫助項目參與更快的進行合規、實現的評估；清晰的框架結構能對問題進行分層，最終達到對項目提效的目的。

歡迎關注作者微信公眾號：「We-Design」