今天分享的主題還是圍繞組件展開，即工作流組件。這是近年出現頻率越來越高，使用場景也越來越多的復雜組件類型。

一、什么是工作流

工作流是英文 Workflow 的翻譯，這是一個商務術語，指“業務過程的部分或整體在計算機應用環境下的自動化”。

簡單來說就是使用計算機編程制定一套固定的操作、計算流程，用于完成指定的工作任務。比如企業的 OA 系統記錄員工的打卡情況，并每月匯總數據生成報告，然后發送給人事郵箱，就是一套工作流。

除此之外，工作流還可以應用在非常多其它場景，大大提高了各行各業的生產效率。工作流是自動化概念中的一個不可獲取的角色，也是數字化服務、生產的基礎建設。

在過去，工作流主要由產品經理制定，再由工程師開發，以一個完整可用的形式交付。但固定的工作流局限性太大，隨著技術和 SaaS 行業的發展，有越來越多的產品將工作流的定義交給用戶自己完成。

這么做的好處有兩個，一個是滿足用戶多樣化的使用需要，只有客戶最了解自己的需求和邏輯，不用一一和他們對接。另一個是實時響應高速迭代和優化的業務，不用等待漫長的開發周期。

最常見的工作流應用場景就是在低代碼 Lowcode 開發平臺，因為本身就要使用可視化的界面完成程序的開發，那么定義工作流的過程就是必不可少的。

以及這兩年就開始大火的 AIGC 領域，對工作流的使用也越來越多。比如著名的繪圖軟件 StableDiffusion 除了基礎的 WebUI 界面以外，專業用戶都轉向使用工作流模式的 Comfy UI。

或者類似字節開發的 AI 產品 COZE，讓用戶自己結合 AI 模型定義工作流，制作專屬的 AI 工具。

雖然 B 端的工作流定義在這幾年才開始普及起來，但這類組件在設計行業并不少見，有很多工具中都有他們的身影，比如 Blender 的渲染流程，UE4 的藍圖，Orgami 的動效設置等等。

工作流組件的主要特點，就是 —— 靈活，自由度更高，而且做出來的圖形結果看起來更直觀。

工作流圖例看起來很像 UML 圖，我們確實也可以把它當成 UML 圖的某種變體，因為傳統工作流開發中產品經理要通過類圖、活動圖、時序圖的繪制來解釋需求，而工作流組件就是模擬這個過程，并直接給出結果。

在一個常規的工作流模塊內，包含兩個核心要素 —— 節點和關系。

節點指的是在流程中每次進行的獨立處理、判斷、計算步驟，可以簡單劃分成開始和結束節點，以及中間的操作節點。

開始節點即觸發工作流的條件，結束節點則是工作流完成工作后關閉流程。操作節點根據業務、產品類型的不同各不相同。

舉個例子，我們以生成員工當月工資的任務做一個任務流，那么它的流程如下所示：

上面案例的節點都是簡化后的結果，而每個節點內還會有一系列的處理步驟，比如扣除缺勤要先去獲取出勤數據，沒有就略過，有了就要根據一定的規則來計算缺勤所產生的處罰，比如事假和病假處罰比例不同，或是是年假不予處罰等。

這些復雜的操作可以以不同的形式在節點內呈現，比如表單、選項、代碼、腳本、公式等等。

而之所以工作流叫流，就是因為工作流代表的是完整的流程，流程中的節點是有關聯性的，是能前后通過一定順序組織起來的，而我們會用連線來進行關系的表示。

連線一般在其中一側會有箭頭，代表了流程的方向。在復雜的工作流中，節點之間的關系并不一定只是一對 1 而已，可能還有 1 對多、多對 1 的關系。

比如上面的工資計算中，在得到本月實際工資時，還要計算五險一金，可以把它們拆分中同步進行的不同節點，再合并到下一個節點得到最終要發的實際工資。

工作流組件就是以這種模式搭建起來的，想要設計這類組件，首先要從業務和產品層面理解這套組件可以完成哪些工作，中間包含的節點類型，以及節點之間的聯系。

然后，我們才可以展開后續的工作。

二、工作流組件的設計

工作流組件本質是一個圖形工具，有很多操作步驟和適應邏輯，開發起來困難，設計起來也很困難，因為我們要確保設計的組件能落地。

所以，工作流組件的設計主要難點是交互層面的，而不是樣式上的，所以它的設計核心要點是定義一套符合當前場景的圖形交互規范。

這個定義過程包含下面幾個要點：

1. 畫布規則

工作流圖形通常都放在一個畫布內，和我們用的設計軟件模式一樣，所以我們首先要確定這個畫布的區域，以及畫布的操作規則。

確定畫布區域很容易無需多做介紹，但畫布不是一個靜態的區域，而是一個可以用來交互的對象。畫布本質上是一個視圖窗口，下級包含的可視區域是大于這個窗口的。

所以，畫布內要支持視圖平移，即上下左右移動。最簡單的交互模式就是使用滾動條，但這個模式太敷衍了，而且操作體驗很差。

常規的設計軟件平移會使用空格加鼠標，但要記住這是平面設計類軟件的操作邏輯，而一般用戶并沒有這種操作習慣，所以非設計工具的畫布移動往往會采用別的模式，比如提供一個抓手按鈕，激活按鈕進入拖拽平移模式。

所以空格移動的交互可以加，但不能作為唯一的操作模式，盡量給出其它直觀的交互邏輯，如拖拽空白區域平移或增加抓手控件。

除了平移外第二個要點，就是縮放。雖然這個功能在設計軟件里必備，但要不代表自己項目里一定要有，因為縮放是一個非常難做好的功能，對程序員要求很高。

所以我們要評估這個工作流有沒有縮放的必要，尤其是就算能縮小看全所有節點，但是字基本都看不清了還有什么意義？如果想不出說服自己的理由，那么縮放就不做。

要做的話同理，要給縮放添加按鈕。而滾輪的操作，要確定把它分配給縮放，還是只給話不的上下平移。

2. 節點排版

第二個問題就是節點的排版問題了，有非常多選擇，也是最麻煩得部分，我舉例其中幾個最常用的類型。

第一個是完全自由的排版，用戶添加節點后，可以任意拖動節點卡片，沒有限制。這種做法看似自由做起來也最簡單，但會引發的小問題最多。

比如節點之間的層級關系，不可能給它做個圖層列表，那么一個小的節點被放進一個大節點后面直接在畫布內“消失”的話怎么辦？或者兩個節點幾乎貼在一起，那么連線怎么表現，箭頭的指向是否能正常顯示？

第二個做法，則是使用網格布局，即元素全部放置到網格內進行排版，元素尺寸要以網格遞增或遞減，元素之間的間距也以網格數為準。

比如部分白板工具會在背景上顯示網點，就是讓用戶感知到元素尺寸和排版是根據這套網格來定義的。

第三個做法則是固定布局模式，即定義一套固定的節點排版邏輯，比如 Coding 的流程配置，從左到右表示節點的順序，上到下表示同一節點的不同操作。并且統一左右、上下的間距，實現穩定和諧但不可控的布局模式。

這三種模式各有優缺點，要根據場景進行選擇，也要和程序員溝通是否能夠實現。

3. 節點適應

節點適應即節點的大小是否要根據內容進行調整，如果節點的內可操作，且包含的內容五花八門，那么節點卡片大小就應該自適應。

只是自適應不是上下左右無差別調整，通常都是寬度固定，高度適應。吐過不了解組件的適應規則可以看之前的分享解釋：

節點適應的關注點，就是和排版之間的關系，除了完全自由的布局模式外，包含固定間距的排版模式就會受到影響，一個已經編輯好的流程前面做修改，后面的一系列節點就全部要做出對應的移動和重排？

這就是一個邏輯上很簡單但是技術上很難實現的問題，所以以 Coding 為主的產品，為了追求穩定就會放棄對內容的適配，每個節點卡片寬度固定，多出來的文本省略，且具體節點信息要點擊后才能查看。

4. 連線模式

連線模式就是表現節點之間關系的模式。每個節點都應該有輸入和輸出的“點位”，常規的做法左側是輸入，右側是輸出，或者上方輸入下方輸出。

如果不統一這種模式，那么在一個線性的流程環節中就會迷失在線條的節奏里…

而在輸出點位上，還有個非常重要的細節，就是輸出是整個節點還是節點下的某個屬性。

比如 COZE 的可以在節點里面創建一個循環體屬性，這個屬性可以關聯一個獨立的循環節點給她返回數據。

輸出和返回都是圍繞這個屬性的，但是這個節點和上方的整個卡片輸出節點處于同一層級。并且兩個卡片上的節點都有輸入輸出屬性，但這個輸出順序卻讓人看得一頭霧水。

確定了點位，下一步就是確定連線的模式，用過思維導圖工具應該都有注意到連線可以設置成曲線或折線的模式。

同理，在工作流中我們也需要制定連線使用曲線還是折線。曲線的實現最容易，但只適合應用在節點數少的場景，否則就會非常的混亂，比如大家在設計軟件中做交互連線的結果。折線效果更好，但實現起來很復雜，只適合應用在固定布局模式里。

最后，連線還要確定層級，連線的層級要像交互連線一樣高于內容層遮擋節點，還是低于節點被遮擋。如果節點之間聯系的權重足夠高的話，那么建議覆蓋到節點上方，用戶覺得遮擋了自己調整節點位置。如果權重很低僅僅是做個意思，就可以放到下方。這個靠設計師自己判斷。

實際項目的交互細節遠遠不止這些誒，但以上四點是做工作流組件中最重要的交互框架，先確定完它們再根據需求補充后續的內容，最后再完成視覺的設計即可（也沒什么好設計的）。

每一個項目的工作流組件都是獨一無二的，你很難找到一個一模一樣的案例進行復刻。所以多思考，多畫原型，多做溝通，才能輸出理想的結果。

結尾

復雜的組件解釋起來還是很蛋疼，因為它不存在標準的設計結果，每種做法都有優缺點，得設計師自己取舍。有自己項目的案例也歡迎分享過來~

我們下篇再賤~

歡迎關注作者的微信公眾號：「超人的電話亭」